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 <e...@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 <amot...@gmail.com> wrote: > >> >> >> 2018年5月14日(月) 21:42 Doug Hellmann <d...@doughellmann.com>: >> >>> Excerpts from Akihiro Motoki's message of 2018-05-14 18:52:55 +0900: >>> > 2018年5月12日(土) 3:04 Doug Hellmann <d...@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 <z...@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-requ...@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-requ...@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-requ...@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-requ...@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-requ...@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-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev