Open Stack

2018年5月14日(月) 21:42 Doug Hellmann <doug at doughellmann.com>:

> Excerpts from Akihiro Motoki's message of 2018-05-14 18:52:55 +0900:
> > 2018年5月12日(土) 3:04 Doug Hellmann <doug at doughellmann.com>:
> >
> > > Excerpts from Akihiro Motoki's message of 2018-05-12 00:14:33 +0900:
> > > > Hi zigo and horizon plugin maintainers,
> > > >
> > > > Horizon itself already supports Django 2.0 and horizon unit test
> covers
> > > > Django 2.0 with Python 3.5.
> > > >
> > > > A question to all is whether we change the upper bound of Django from
> > > <2.0
> > > > to <2.1.
> > > > My proposal is to bump the upper bound of Django to <2.1 in Rocky-2.
> > > > (Note that Django 1.11 will continue to be used for python 2.7
> > > environment.)
> > >
> > > Do we need to cap it at all? We've been trying to express our
> > > dependencies without caps and rely on the constraints list to
> > > test using a common version because this offers the most flexibility as
> > > we move to newer versions over time.
> > >
> >
> > The main reason we cap django version so far is that django minor version
> > releases
> > contain some backward incompatible changes and also drop deprecated
> > features.
> > A new django minor version release like 1.11 usually breaks horizon and
> > plugins
> > as horizon developers are not always checking django deprecations.
>
> OK. Having the cap in place makes it more complicated to test
> upgrading, and then upgrade. Because we no longer synchronize
> requirements, changing openstack/requirements does not trigger the
> bot to propose the same change to all of the projects using the
> dependency. Someone will have to do that by hand in the future, as we
> are doing with eventlet right now
> (https://review.openstack.org/#/q/topic:uncap-eventlet).
>
> Without the cap, we can test the upgrade by proposing a constraint
> update and running the horizon (and/or plugin) unit tests. When those
> tests pass, we can then step forward all at once by approving the
> constraint change.
>

Thanks for the detail context.

Honestly I am not sure which is better to cap or uncap the django version.
We can try uncapping now and see what happens in the community.

cross-horizon-(py27|py35) jobs of openstack/requirements checks
if horizon works with a new version. it works for horizon, but perhaps it
potentially
break horizon plugins as it takes time to catch up with such changes.
On the other hand, a version bump in upper-constraints.txt would be
a good trigger for horizon plugin maintainers to sync all requirements.

In addition, requirements are not synchronized automatically,
so it seems not feasible to propose requirements changes per django version
change.


>
> >
> > I have a question on uncapping the django version.
> > How can users/operators know which versions are supported?
> > Do they need to check upper-constraints.txt?
>
> We do tell downstream consumers that the upper-constraints.txt file is
> the set of things we test with, and that any other combination of
> packages would need to be tested on their systems separately.
>
> >
> > > > There are several points we should consider:
> > > > - If we change it in global-requirements.txt, it means Django 2.0
> will be
> > > > used for python3.5 environment.
> > > > - Not a small number of horizon plugins still do not support Django
> 2.0,
> > > so
> > > > bumping the upper bound to <2.1 will break their py35 tests.
> > > > - From my experience of Django 2.0 support in some plugins, the
> required
> > > > changes are relatively simple like [1].
> > > >
> > > > I created an etherpad page to track Django 2.0 support in horizon
> > > plugins.
> > > > https://etherpad.openstack.org/p/django20-support
> > > >
> > > > I proposed Django 2.0 support patches to several projects which I
> think
> > > are
> > > > major.
> > > > # Do not blame me if I don't cover your project :)
> > > >
> > > > Thought?
> > >
> > > It seems like a good goal for the horizon-plugin author community
> > > to bring those projects up to date by supporting a current version
> > > of Django (and any other dependencies), especially as we discuss
> > > the impending switch over to python-3-first and then python-3-only.
> > >
> >
> > Yes, python 3 support is an important topic.
> > We also need to switch the default python version in mod_wsgi in DevStack
> > environment sooner or later.
>
> Is Python 3 ever used for mod_wsgi? Does the WSGI setup code honor
> the variable that tells devstack to use Python 3?
>

Ubuntu 16.04 provides py2 and py3 versions of mod_wsgi (libapache2-mod-wsgi
and libapache2-mod-wsgi-py3) and as a quick look the only difference is a
module
specified in LoadModule apache directive.
I haven't tested it yet, but it seems worth explored.

Akihiro


> >
> > > If this is an area where teams need help, updating that etherpad
> > > with notes and requests for assistance will help us split up the
> > > work.
> > >
> >
> > Each team can help testing in Django 2.0 and/or python 3 support.
> > We need to enable corresponding server projects in development
> environments,
> > but it is not easy to setup all projects by horizon team. Individual
> > projects must be
> > more familiar with their own projects.
> > I sent several patches,  but I actually tested them by unit tests.
> >
> > Thanks,
> > Akihiro
> >
> > >
> > > Doug
> > >
> > > >
> > > > Thanks,
> > > > Akihiro
> > > >
> > > > [1] https://review.openstack.org/#/c/566476/
> > > >
> > > > 2018年5月8日(火) 17:45 Thomas Goirand <zigo at debian.org>:
> > > >
> > > > > Hi,
> > > > >
> > > > > It has been decided that, in Debian, we'll switch to Django 2.0
> after
> > > > > Buster will be released. Buster is to be frozen next February. This
> > > > > means that we have roughly one more year before Django 1.x goes
> away.
> > > > >
> > > > > Hopefully, Horizon will be ready for it, right?
> > > > >
> > > > > Hoping this helps,
> > > > > Cheers,
> > > > >
> > > > > Thomas Goirand (zigo)
> > > > >
> > > > >
> > >
> __________________________________________________________________________
> > > > > OpenStack Development Mailing List (not for usage questions)
> > > > > Unsubscribe:
> > > OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
> > > > > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> > > > >
> > >
> > >
> __________________________________________________________________________
> > > OpenStack Development Mailing List (not for usage questions)
> > > Unsubscribe:
> OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
> > > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> > >
>
> __________________________________________________________________________
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20180514/4673fd6e/attachment.html>