Open Stack

Updates on Django 2.0 support.

* 18 of 29 affected repositories now support Django 2.0
* 4 repositories have pending patches.
* 3 repositories below need help from individual project teams as I don't
have actual running environments of them.
   * heat-dashboard https://review.openstack.org/#/c/567591/
   * murano-dashboard https://review.openstack.org/#/c/571950/
   * watcher-dashboard
* 4 repositories below needs more help as there seems no python3 support or
projects looks inactive.
   monasca-ui, cloudkitty-dashboard, karbor-dashboard, group-based-policy-ui

global-requirements and upper-constraints changes are also proposed.
Considering good progress in general, I believe we can land requirements
changes soon.
https://review.openstack.org/#/q/topic:django-version+(status:open+OR+status:merged)

Detail progress is found at
https://etherpad.openstack.org/p/django20-support

Thanks,
Akihiro

2018年5月15日(火) 4:21 Ivan Kolodyazhny <e0ne at e0ne.info>:

> 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
>>
>>
> __________________________________________________________________________
> 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/20180603/f2e1816f/attachment.html>