Re: Creating a new named official debian repository for OpenStack backports (Uploading all of OpenStack to backports)
Hi Debian friends and OpenStack users! :)
For the (OpenStack novice) readers, and more readability, just let me
note this about OpenStack release names:
* Essex == version 2012.1 (the version currently in Wheezy)
* Folsom == version 2012.2
* Grizzly == version 2013.1
* Havana == version 2013.2 (the current OpenStack stable, released
last October)
* Icehouse == version 2014.1 (the "next" OpenStack stable, to be
released next April)
* Juno == version 2014.2 (to be released at the end of 2014)
On 03/10/2014 10:35 PM, Lucas Nussbaum wrote:
> However, I'm not sure I understand what problems would be solved by
> using wheezy-havana, wheezy-icehouse, etc. instead of just plainly
> wheezy-backports?
There are multiple problems with having "only" wheezy-backports.
First, it imposes that things goes through Sid, then testing. I don't
mind the delay, and appreciate what could be quality improvement.
Unfortunately, that's often the opposite effect that happens. When a
package works perfectly well in Wheezy (there's very few unit tests that
fail in the OpenStack packages when doing the tests in Wheezy), there
are often a lot more problems when trying in Sid/Testing. For example, I
had/have to deal with lots of issues related to SQLAlchemy 0.8, then now
0.9, while in Wheezy, SQLAlchemy stays with version 0.7 and everything
is fine. In some cases, I've had to just ignore the unit tests failures,
which was very frustrating. There's been recent improvements though, and
we're about to fix the next most important one (with Nova and the SQLA
0.8 "deleted" boolean bug that generates more than 150 failures... I
think we soon have a solution! :)).
Second, there's only a single "wheezy-backports". Therefore, I can't
have OpenStack Grizzly, Havana and Icehouse hosted at the same time by
Debian. Same issue in Sid/Testing by the way. This is a huge problems
for integrators/users, because they should be the one deciding when to
upgrade their cloud IaaS. If I decide to override Havana by Icehouse
(for example), then I can't provide security updates for Havana anymore
in Debian.
There's also a problem not only OpenStack itself, but also some of its
dependencies. For example, oslo-sphinx for Icehouse is incompatible with
oslo-sphinx for Havana (Python module renamed...), python-wsme same, etc.
Third, there's the problem that upstream, in many places, expect to have
specific repositories for specific versions of OpenStack. For example,
there's an open launchpad bug (upstream uses that as bug tracker) for
fixing the URLs of the Icehouse deb repositories. It saddens me that I
have no solution to this yet.
On 03/10/2014 11:32 PM, Gaudenz Steinlin wrote:
> The only "problem" that could be solved is to lift the requirement
> that packages have to enter testing before going into backports. But
> to me this is actually a feature lacking form the current unofficial
> repository.
See above. This has absolutely nothing to do with stability. IMO,
running the tempest functional test suite is a way more important than
staging 10 days in Testing, which by the way is often related to Debian
specific problems that have very little to do with OpenStack (for
example, transition of libraries blocking OpenStack related packages).
I personally wouldn't mind *too much* imposing that packages are staged
10 days in testing first (that's what we have currently anyway), if you
think that's better, though I hope this wouldn't prevent from uploading
Icehouse the day it is released. And that's exactly the effect it would
do: let's say the last packages in NEW get approved, then I can't upload
Icehouse in Sid now, because that would destroy Havana (so I've started
uploading to experimental).
Another thing: having things staged in Testing will not change anything
on the amount of work I will put into the packages (eg: I will continue
to work on them every day, and have a team in eNovance setting them up
and testing them). So I don't really see the point that you would try to
achieve.
On 03/11/2014 05:08 AM, Daniel Pocock wrote:
> Likewise, if somebody has a large network with OpenStack and they just
> want some Debian systems to play nicely inside that, they will want
> wheezy packages for their version of OpenStack, not just whatever
> version of the packages we happen to have in backports.
That's exactly my point. Also, integrators working on puppet modules
will need time to be able to move from one version to the next, and
support upgrades.
On 03/11/2014 07:49 AM, Thomas Goirand wrote:
> On Tue Mar 11 2014 05:24:42 AM HKT, Scott Kitterman
<debian@kitterman.com> wrote:
>> Which is why there is a PPAMAIN proposal. Instead of doing one off
>> solutions for openstack, ganglia, whatever, I think it'd be better
>> if the people who are motivated around this issue invested time in
>> helping with PPA implementation.
>>
>> Scott K
>
> but it is completely irrealistic to believe one
> could just help by reading Dak sources. There's also
> no document that explains how one could help.
>
> It is my view that only a very small amount of
> people in Debian have the knowledge of both the code
> and the infrastructure to actually implement it. And
> those people already expressed themselves saying
> they are too busy on the forthseable future.
>
> So, I like the motivation argument, but here it
> doesn't work (if it did, I know some company that
> would work on it).
>
> Thomas (from my phone)
To this, I would like to add that, if we have directions, we (eg: me and
eNovance) would like to offer our help to make the PPAMAIN stuff
happens. But having the directions and someone to help us to help is
here, mandatory (and I believe there is a consensus around this).
And whatever happens and who works on it, I don't think anyone expect
this to happen within the next months at least. Even Ganneff himself
wrote to me (Ganneff, I hope you don't mind I disclose that!) that it
would need about a full time month of a knowledgeable person to work on
it (and since Ganneff doesn't have the time to do it, it would be
someone with less know-how, so I'd expect it would take even more time).
On 03/11/2014 06:29 AM, Vincent Cheng wrote:
> I can't speak for the backports ftpmasters, but given that they
> refused to accept php5 into backports due to it (well, the latest
> upstream 5.4.x branch) not being in testing, I doubt they'll make an
> exception for openstack as well.
I haven't strongly asked for this. Again, if there's a consensus that
packages need to be staged for some times in testing, I'm fine with it
(though see above, about preventing from releasing packages at the same
time as upstream).
> I certainly can't fault them; if you
> make an exception for php/openstack/whatever, other maintainers will
> certainly start asking for exemptions as well.
It is my strong opinion that OpenStack is different from the other
average package. Here, I'm talking about maybe 200 packages that needs
to work together. This isn't exactly small and a usual use case, and I
do believe it would make sense.
If there's some other large suite of package that need the same kind of
repository, then why not? Unless you're making the case to block
progress and improvements... :)
Also, I do think it'd be nice to use what the FTP masters have been
working on. I don't think they did that work just "for fun", but had
this exact type of usage in mind when writing it (eg: probably not only
PPAMAIN). It would also be a nice way to test the new feature.
> Until PPAMAIN becomes reality, the best solution is probably the
> status quo, i.e. host your repository somewhere else on non-Debian
> infrastracture.
That's exactly what I have been told isn't good, and I agree with this
view. Debian packages should be hosted by Debian, and completely be part
of it. Anything hosted outside is unofficial, and a sad situation that
needs to be IMO fixed.
> You can still take advantage of the debian.net
> namespace though, e.g. openstack.debian.net.
That doesn't make the packages more official. And if we're to host the
backport packages on GPLHost own (10 countries) mirrors like now, which
costs us money, then sorry, but I prefer to advertize about my company
which provides the infrastructure. I think it's a normal return. Just
hiding it behind a debian.net name would be IMO unfair.
Now, finally, I'd like to add that, after all the above, I'm not really
sure anymore that uploading to Debian official backports is a so good
idea. So probably I should continue to think about it, and/or delay it
until there's either PPAMAIN or some OpenStack specific Debian
repositories created somehow. Thoughts and ideas from anyone welcome!
By the way, I think this decision of opening specific repositories
should be done by the FTP masters only, so let's let them reply! :)
Hoping I made valid points above,
Cheers,
Thomas Goirand (zigo)
P.S: I wrote it already, but think about it again: *ALL* other
distributions (RedHat, Ubuntu...) are doing what I'm asking for.
Shouldn't this be the sign that it makes sense?
Reply to: