Open Stack

Excerpts from Ivan Kolodyazhny's message of 2018-05-14 22:20:42 +0300:
> Hi all,
> 
> From the Horizon's perspective, it would be good to support Django 1.11 as
> long as we can since it's an LTS release [2].
> Django 2.0 support is also extremely important because of it's the first
> step in a python3-only environment and step forward on supporting
> next Django 2.2 LTS release which will be released next April.
> 
> We have to be careful to not break existing plugins and deployments by
> introducing new Django version requirement.
> We need to work more closely with plugins teams to getting everything ready
> for Django 2.0+ before we change our requirements.txt.
> I don't want to introduce any breaking changes for current plugins so we
> need to to be sure that each plugin supports Django 2.0. It means
> plugins have to have voting Django 2.0 jobs on their gates at least. I'll
> do my best on this effort and will work with plugins teams to do as
> much as we can in Rocky timeframe.

That sounds like a good plan, thanks Ivan.

Doug

> 
> [2] https://www.djangoproject.com/download/
> 
> Regards,
> Ivan Kolodyazhny,
> http://blog.e0ne.info/
> 
> On Mon, May 14, 2018 at 4:30 PM, Akihiro Motoki <amotoki at gmail.com> wrote:
> 
> >
> >
> > 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
> >>
> >
> > __________________________________________________________________________
> > 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
> >
> >