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

Chuck Short zulcss at gmail.com
Sun Jun 3 01:56:19 UTC 2018


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.


> 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
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20180602/27bf2405/attachment.html>


More information about the OpenStack-dev mailing list