Re: Removing Python 2 support in OpenStack [was: Please do not drop Python 2 modules]
- Date: Thu, 26 Apr 2018 00:49:14 +0200
- From: Thomas Goirand <zigo@xxxxxxxxxx>
- Subject: Re: Removing Python 2 support in OpenStack [was: Please do not drop Python 2 modules]
On 04/25/2018 11:59 AM, Ondrej Novy wrote:
> 2018-04-25 11:11 GMT+02:00 Thomas Goirand <zigo@xxxxxxxxxx
> - faster build time (no need to test with Python 2, so less chances of
> build failure).
> build is done once, customer happiness is for years (buster lifetime).
More work ...
> - no chance to have any Python 2 packages installed, so we're sure we're
> on a full Python 3 stack (in my current setup, unfortunately some Python
> 2 packages are still pulled). This may go on for another 3 years if we
> don't remove Python 2 now, with the added issue that it will pull
> *older* version of clients if selecting Python 2 and if we still have
> them in Buster (ie: case of OpenStack backports on top of Stable).
> so let's fix packages to not pull Py2 if it's not needed.
> - packaging and decrufting will take a long time, so we'd better start
> early. Especially if we want to do it the proper way, without breaking
> any reverse (build-)dependency that are outside of OpenStack.
> more than one release cycle? I'm sure we can do it during Bullseye. And
> we will do it for non-OS Python packages too. Better is to do removing
> in earlier phase of development cycle.
And even more work...
If you're only points of argumentation are "well, it's easy, we just
need to do this or that", then it's not acceptable. There's no way you
can force anyone in Debian into doing one thing or another, if you don't
*significantly* contribute. Optimizing the way I can do OpenStack
packaging means I can do more with that limited time, and I really think
that's the best way to serve our users.
We've played that game last summer at Debconf, with lots of promises
from potential contributors. I accepted the rules, and lost the game
with more work for me, doing the way the team was supposed to do, but
finally being nearly the only one doing all. I wont do the same mistake
again unless I see things have changed *already* (ie: not just
promises). Here, I'm talking about at least 3 or 4 uploads per week (I
was tempted to write one per day...) of non-cosmetic changes.
There's btw a bunch of RC bugs in the BTS that I would love to get
fixed. Anyone up for contributing that?
> - at some point, even upstream will move to Python 3, and Python 2 will
> be the legacy old thing. Do we really want to be the only distribution
> that will hit these Python 2 bugs? In such case, we'll be alone writing
> these Python 2 bugfix patches. :/
> that point is after Rocky, so it's doesn't matter for Buster.
> - Other distros (RHEL and Ubuntu) will move to Python 3 only in the next
> OpenStack development cycle, meaning we'll be alone with Python 2
> support at some point.
> any links where Ubuntu said they will not support Py2 for Rocky? I'm
> sure we will not be alone.
This was part of a non-formal discussion with Ubuntu people, I'm not
sure it would be right to say with who, but I'm sure you can guess. We
can discuss with that person again and see what he says now, as maybe
things have changed since that last conversation. So no, I don't have
any formal announcement/links to support that it will happen in Ubuntu
> The other thing is, it's ready! I was able to do functional testing on
> top of the Python 3 release of OpenStack Debian packages. So why should
> we hold any longer?
> What is ready? Py3 support, or Py2 dropping? If foremost, let's do it.
> Let's have good Py3-only services, let's have default Py3 clients, but
> support Py2 clients. It cost us nothing, it's already done this way.
That's were I don't agree (with both you and Adrian Bunk). Supporting a
dual-python everything but services, and keeping the legacy in place
isn't costless. It is a significant overhead. The question is just if
it's worth the effort or not.
> The only benefit we get with keeping Python 2 support is for thirdparty
> software that is still using Python 2. We don't have this in Debian at
> the moment. What's the status in your company? Do you still need Python
> 2 for your internal use? What's the ETA for switching to Python 3?
> yep, that's important benefit. Because our priority is our users.
LOL ! Writing "our priority is our users" in a thread is nearly equal to
winning a godwin point, do you know? Just like it, it's supposed to end
the discussion with no argumentation possible.
Jokes aside (yes, the above is only a joke...), to serve our users the
best way possible, we need to set priorities the right way, and be
efficient. Because being efficient in the way we do the work is the best
way to get more time for things that matters. Add a bit of polish to
everything, so that users are happy. There's the need for polishing many
rough edges of OpenStack in Debian, I'm sure you know it.
Now, what needs to be accounted, is how many people use Py2 clients (and
of course, by that, I mean the Python modules, not the cli). To answer
that question, we have unfortunately no data except your own case.
> "My" company is not important, important is our users and my company is
> just one of them.
But is the whole set made of just one? Or more? Impossible to say...
Which is why I asked you how much time it would take for fixing the
situation in your own company, as it could be a good example. How many
months do you need? 6 months? A year? It'd be super nice if you could
explain your use case in more details, and tell what your code base is
about. Though maybe you can't do it publicly? Or even, maybe you can't
tell me? I would understand in both cases. But if you can explain, it
would help understanding at least your use case, which may be similar to
Thomas Goirand (zigo)