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
