Open Stack

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.

[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
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20180514/4c961e26/attachment.html>