[openstack-dev] [horizon] Scheduling switch to django >= 2.0

Doug Hellmann doug at doughellmann.com
Mon May 14 12:42:11 UTC 2018


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.

> 
> 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?

> 
> > 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
> >



More information about the OpenStack-dev mailing list