Open Stack

On 11/06/13 10:34 -0400, Doug Hellmann wrote:
>   On Tue, Jun 11, 2013 at 2:54 AM, Julien Danjou <[1]julien at danjou.info>
>   wrote:
>
>     On Tue, Jun 11 2013, Joe Gordon wrote:
>     [ Following up on -dev ]
>
>   > As many of you have probably seen, there has been a community effort
>   to
>   > begin the slow process to making OpenStack python 3 compatible. There
>   is
>   > even a weekly meeting discussion it (
>   > [2]http://eavesdrop.openstack.org/meetings/python3/2013/)
>   >
>   > As this is inherently a massive cross project effort, I was hoping
>   the TC
>   > would comment on the python 3 efforts.
>   >
>   > * What versions of python we want to compatible with
>   > * Do we *want* all projects to by python 3 compatible or should we
>   focus
>   > our efforts on oslo and client libraries etc?
>   > * Do we want to begin gating on some python 3 compatibility?
>   >
>   [3]https://github.com/openstack-dev/hacking/commit/e0ab03637da65bfc6035
>   091989b62fc70ae363a5
>   > * etc.
>
>     It kind of seems obvious to me that nobody in the TC is going to
>     object
>     to any effort bringing compatibility to Python 3. :-) I bless that
>     and
>     would love to help going into this direction actually.
>     All project should go to Python 3 at some point, but it seems
>     logical to
>     start by every dependency like Oslo, and as discussed during the
>     Python
>     3 session at the summit, starting with client libraries is going to
>     be
>     easier than porting whole projects. We're probably years from that
>     concerning projects like Nova for example.
>     Considering this timeframe, targetting latest Python 3 releases is
>     going
>     to be largely good enough.
>
>   The etherpad from that summit session that Eric led
>   is [4]https://etherpad.openstack.org/havana-python3
>   As Julien said, we agreed to start with clients and dependencies first.
>   The reliance on eventlet may make it difficult to port the existing
>   servers, and there is a lot of other code to work on, so we decided to
>   wait and see what happens with async libraries under Python 3 and start
>   with the "easy" stuff. It is also more likely that a client will want
>   Python 3 support than that a server will require it.


This sounds like a good plan. The port to anything away from eventlet
will take a long time and effort.

I'll take care of glanceclient if no one has signed up for it yet.
Lets take under consideration that most of the clients depend on
python-keystoneclient, we might want to port that one first.

>   We're targeting at least Python 3.3, with the idea that we'll be able
>   to use Tulip. That minimum version may change based on what's current
>   at the time the work makes enough progress for us to talk about
>   settling on a version. I can't imaging it going lower, though.

Python >= 3.3 makes total sense to me as well.

>   For testing we said we would set up a separate tox stanza for with the
>   test runner configured to run only the subset of tests for modules
>   expected to work with Python 3. That way in oslo-incubator, for
>   example, we don't have to port everything at once, we can just run a
>   subset of the tests and prevent regressions after we get a module
>   working with 3. That does imply that we want gating jobs for Python 3.3
>   for projects where the work has reached a point that it makes sense to
>   start enforcing compatibility.

+1

>   By the way, Chuck Short has been doing a lot of really good work on
>   Python 3 compatibility already, but I'm sure he would appreciate some
>   help.

Ditto. I can help with glanceclient and start doing the basic ports, I
still don't know how much of it can be ported right now, in terms of
libraries.


Cheers,
FF

-- 
@flaper87
Flavio Percoco