Open Stack

On 11/26/2012 12:00 PM, Matt Joyce wrote:
> I think RedHat is heavily involved in supporting OpenStack and it
> behooves us to treat them well because of that.  I know they aren't
> always the easiest distribution to work with but that's also their
> strength.  But they are a bar worth raising ourselves up to.
>
> Of course, I am driven to say that if someone, such as say SuSE grew to
> be more involved I would of course suggest we extend them the same courtesy.
>
> The way I see it we'll never be able to avoid RHEL if openstack intends
> to operate in enterprise.  It's going to happen whether we want it to or
> not so we may as well embrace it.  But, we should let RedHat take care
> of the bits that really are their own concern.  And I say the same of SuSE.

++

> Beyond that, everything that isn't ubuntu / debian is edge cases at the
> moment.

++

(I think that related to the above, it's on RedHat and Canonical both to 
take care of things like backporting latest library deps to their platform)

> Windows and HyperV products for instance.  Or any potential port to a
> BSD or Solaris.  Those are big questions.  Especially since the HyperV
> team has contributed so much to OpenStack and has done incredible work.
> Also because groups such as CERN who have been high profile and heavy
> contributors/supporters are relying on that contribution.  But I feel
> like at this point any work done there without significant user interest
> or adoption should be done at the expense of interested parties.  And
> that means keeping an open mind, and an open ear but not jumping through
> hoops to keep them in the proverbial engineering loop.
>
> Opinions expressed are my own.
>
> And maybe that's part of the question.  We can discuss to what extent
> this is an engineering concern.  But this also seems to fall at least
> partially under the purview of the OpenStack foundation board.

I think the main engineering question boils down to "when (do we|can we) 
stop caring about python 2.6" ... I don't think the day is today, 
because I do think it would be unduly negative towards RedHat at the 
moment. Other than that, I don't think us "supporting" one distro over 
another has a ton of quantifiable engineering effect.

> On Mon, Nov 26, 2012 at 8:40 AM, Monty Taylor <mordred at inaugust.com
> <mailto:mordred at inaugust.com>> wrote:
>
>     Hey all!
>
>     I started a discussion during a TC meeting a little while ago that
>     needs more general input and feedback. The question at hand is "what
>     versions of python and what versions of what distros do we care
>     about as a project?"
>
>     First of all, this isn't a discussion about what CI will test or
>     what we'll use for gating.  It's more of a conversation about what
>     language and OS assumptions developers can make when they are
>     writing code, so that design and review choices can be made.
>
>     To put it more bluntly, if someone files a bug or a code review
>     comment that says:
>
>     "Blah doesn't work in python X"
>
>     When can we respond "not a bug/won't fix" with a clear conscience?
>
>     When we first started the project, we said out loud that development
>     was always focused on the current release of Ubuntu and that's it.
>     We picked that because doing _development_ targeting a bazillion
>     distro options at the same time gets hairy quickly, and I think the
>     clarity served has us well. But I'm pretty sure things have changed
>     since then - latest Ubuntu does not come with python 2.6, for
>     instance, but we still seem to care about it.
>
>     With that background, I'd like to start things off by proposing the
>     following:
>
>     a) We continue to focus development efforts of master on the latest
>     release of Ubuntu with python libraries coming from PyPI.
>     b) We don't introduce things into master that would be unworkable on
>     either latest Ubuntu LTS or latest RHEL.
>
>     Logistically, because of our development focus on pypi modules in
>     virtualenvs, this doesn't affect much for developers outside of base
>     python versions and a few things that can't go in a virtualenv like
>     libvirt or the kernel. Since RedHat and Canonical have both
>     committed to maintaining special backport repos for those things for
>     users of RHEL and Ubuntu LTS, I don't think in practice it's going
>     to have much of a noticeable impact..
>
>     Except where it comes to base python versions.
>
>     If we take the above to be correct, it has the following effect:
>
>     - We need to care about python 2.6 compatibility until such a time
>     as there is a RHEL that has 2.7 in it.
>     - 2.7 should be our current dev focus, so if possible we should code
>     to 2.7 libs and then use backport packages like unittest2 to make
>     2.6 happy.
>     - We can't REALLY start thinking about Python3 in earnest until a
>     RHEL release comes out with python 2.7, because 2.7/3.3 are needed
>     for source-code compatible code
>
>     Net result - pretty much exactly what we're doing today, it just
>     gets it down on paper a little better.
>
>     Thoughts? Disagreements?
>
>     Monty
>
>     _________________________________________________
>     OpenStack-dev mailing list
>     OpenStack-dev at lists.openstack.__org
>     <mailto:OpenStack-dev at lists.openstack.org>
>     http://lists.openstack.org/__cgi-bin/mailman/listinfo/__openstack-dev <http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev>
>
>
>
>
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>