openstack team mailing list archive

[Monty Taylor <mordred@xxxxxxxxxxxx>]

Hi Mark!

On 08/25/2011 12:31 AM, Mark McLoughlin wrote:
> Hi Soren,
> 
> On Wed, 2011-08-24 at 22:11 +0200, Soren Hansen wrote:
>> 2011/8/24 Monty Taylor <mordred@xxxxxxxxxxxx>:
>>> - Lack of RPM support. Turns out RPM distros are still kind of popular,
>>> and at least one of our major contributors (hi, NTT) rolls out on
>>> RHEL/CentOS, and one of our partners who is going to be contributing
>>> testing hardware (MSFT/Novell) is associated with a distro (SuSE) that
>>> is RPM based. We're a few steps away from this, but it warrants mentioning.
>>
>> This probably warrants a separate discussion. As pointed out further
>> up, Ubuntu was chosen in part because it's very up-to-date. With a
>> release every 6 months, we're never far behind in terms of access to
>> dependencies in the most recent release, and since our release cycles
>> line up, we can *ensure* availability of the dependencies we require
>> in the upcoming release.  If
>> RHEL/CentOS/ScientificLinux/WhatEverOtherFlavourOfRedHatYouPrefer
>> becomes a supported target, will this block stuff from landing in Nova
>> until RHEL catches up with the rest of the world in terms of libraries
>> upon which we depend?
> 
> Absolutely not. Upstream needs to continue adopting the latest version
> of dependencies. It's up to the distributions to deal with the fallout.

I pretty much totally agree with you here.

> I expect the latest Fedora release would be a similar enough target (in
> terms of dependency versions) for upstream development as the latest
> Ubuntu release.
> 
> Indeed, while packaging Diablo for Fedora 16[1] some of the problems
> I've hit so far are due to OpenStack upstream using older versions of
> dependencies than Fedora 16 ships with e.g.
> 
>   * A couple of migrations fail with SQLAlchemy 0.7.x - I've proposed a 
>     merge with fixes for that
> 
>   * M2Crypto 0.20.2 doesn't build against latest openssl headers (e.g. 
>     STACK macro changed to STACK_OF) but OpenStack seems to work just 
>     fine with 0.21.1 - this just means that install_venv.sh doesn't 
>     work on Fedora 16
> 
> 
> I don't know the background to this whole thread, but IMHO:
> 
>   * Upstream core devs shouldn't need to worry much about packaging, for
>     any distro. Given the upstream use of virtualenv, the policy for 
>     dependencies should be just to use the latest and greatest. For 
>     non-python dependencies (e.g. iptables, libvirt, KVM, Xen) there 
>     should probably only be versions from a limited set of fast moving
>     distros supported.

This is where I disagree with you - although I also sort of agree with
you. Let me splain:

I disagree that we shouldn't worry much about packaging. As I've stated
before, I think that we HAVE to worry about packaging, because our model
is different than distros. It is NOT important to me what version of
OpenStack was when Fedora 16 came out. Or RHEL6. I mean, if we _DIDN'T_
deal with packaging, no one who wanted to run on RHEL6 servers (a lot of
people) would be able to install OpenStack.

As an upstream, my concern is that users have the latest OpenStack on
whatever OS Distro version they have. As a distro, you care that the
distro release itself is consistent and works well. (and thank you for
caring about that, actually, it's really important)

Where I agree with you is that I do not think we should be caring about
packaging for distro inclusion. I think we should care about packaging
as a distribution mechanism for _our_ software.

>   * Packaging for multiple distros is tough - RHEL6 was based on F13, 
>     but, with e.g. the switch to systemd, I'd hate to be the guy trying 
>     to maintain packaging for both. Nevermind adding packaging for 
>     OpenSuse into the mix.

Eh. It's not _that_ bad. I seem to do it all the time. :)

>   * There seems to be demand from various folks deploying OpenStack 
>     (e.g. Rackspace, Grid Dynamics, Mirantis) for regular builds of the
>     development branch for different distros. Is there also demand for 
>     the bits to be packaged differently - e.g. with different defaults?
> 
>     I guess there'll always be some demand for builds like these, but
>     perhaps it will lessen as the project matures and distros own
>     packaging of OpenStack improves?
> 
>   * The project doesn't necessarily need to release official packages as
>     part of the project release. If it does, it should limit them to 
>     the limited set of fast moving distros.

As I mentioned before, not really possible. I kind of need to release
packages for Ubuntu Lucid, or else we might as well not bother releasing
at all.

The thing is, people running 1000 node infrastructures in data centers
are not installing Ubuntu Oneiric or Fedora 16 on them. The would
literally laugh at us if we suggested it. (actually, that has actually
happened)

>   * The project should be cautious about what expectations it sets for
>     the longer term and how it commits its resources. For example, if I
>     set up a Jenkins job to build Fedora 16 packages of trunk, the 
>     project shouldn't be quick to bless those as official and set the 
>     expectation that such packages will always be available.

Well no, it shouldn't be quick to bless them. HOWEVER, if _I_ set up a
Jenkins job, that is the expectation, since they're going to go
somewhere with an openstack.org name associated with it. This is why I'm
such an ass about making sure we have process for things, because if I
take on releasing RPMs as well, I need to make sure that we have a
documented process for how they are produced and how the packaging is
maintained - and preferrably at this point the packaging branch should
be going through the same code review process as the rest of the project.

>   * Open upstream co-operation between anyone doing packaging is great. 
>     The Packaging wiki page is an awesome idea. Maybe an 
>     openstack-packagers list would be the next step. Maybe bring all 
>     (mirrors of?) the packaging SCMs together in an openstack-packaging
>     github organization. But this is about sharing knowledge, not so 
>     much about sharing work on a common upstream.
> 
> Meh, sorry if this was tl;dr :)

I think, on this thread, that's not possible! Thanks for chipping in!

Monty