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

Akihiro Motoki amotoki at gmail.com
Sun Jun 3 02:45:51 UTC 2018


2018年6月3日(日) 10:56 Chuck Short <zulcss at gmail.com>:

> Hi
>
> On Sat, Jun 2, 2018 at 9:50 PM, Akihiro Motoki <amotoki at gmail.com> wrote:
>
>> 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
>>
>>
> Monasca-ui has python3 support however the CI hasn't been enabled.
>

Considering my bandwidth, it would be nice if monasca-ui team can work on
django2.0 support.


>
>
>> 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
>>>
>>
>> __________________________________________________________________________
>> 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/074c90be/attachment.html>


More information about the OpenStack-dev mailing list