Open Stack

On Mon, Nov 26, 2012 at 08:40:15AM -0800, Monty Taylor wrote:
> 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?

Even ignoring the question of what versions distros we're targetting
support, I think we should be conservative in both the base python
version, and external dependancies in general. I observe that there is
a general tendancy to move to the latest release of external depedencies
very quickly. As an example, Fedora 17 (which is not exactly an old
release - in fact it is the current up2date Fedora release still) is
already unable to satisfy OpenStack's min version requirements for
something as simple as pep8.

The view seems to be that things like DevStack / virtualenvs make it
easy to switch to newer versions, and so there's little-to-no downside.
This is mostly prioritizing easier coding for developers, over ease of
deployment & maintenence for both end users and distributors. Perhaps
this was the right approach early in OpenStacks lifetime, but with
people increasingly viewing OpenStack as production ready /  maturing
I think the current balance is wrong. Indeed I believe the overly eager
switch to new versions is actively harmful to the community as a whole.

I would like to see our guiding principal be to avoid min version upgrades
unless there is a significant (ie show stopper) problem with existing min
versions to is not practical to live with. If a new particular new feature
is really desired, then structure things so that the new feature is only
used if the corresponding version is available, and fallback to turning
off that feature otherwise. This avoids the need to upgrade min version
requirements, without preventing use of new features.

To your specific point of Python base versions, my view is that we should
aim for the lowest possible Python version. Yes, new python 2.7 version
introduces shiny new features over 2.6, but in reality it is entirely
practical to write OpenStack without requiring these new features. As for
Python 3.0, it may remove many warts from Python 2.x, but I really don't
see much compelling reason to even consider supporting to that. Python
2.x is going to be around for a long time yet and I don't see any end
user relevant features of OpenStack that would be blocked by us sticking
with 2.x only and ignoring 3.x entirely. There is certainly plenty of
downside to increasing the min python above 2.6 for both os vendors and
end users.

Regards,
Daniel
-- 
|: http://berrange.com      -o-    http://www.flickr.com/photos/dberrange/ :|
|: http://libvirt.org              -o-             http://virt-manager.org :|
|: http://autobuild.org       -o-         http://search.cpan.org/~danberr/ :|
|: http://entangle-photo.org       -o-       http://live.gnome.org/gtk-vnc :|