2018年6月3日(日) 10:56 Chuck Short <[email protected]>: > Hi > > On Sat, Jun 2, 2018 at 9:50 PM, Akihiro Motoki <[email protected]> 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 <[email protected]>: >> >>> 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 <[email protected]> >>> wrote: >>> >>>> >>>> >>>> 2018年5月14日(月) 21:42 Doug Hellmann <[email protected]>: >>>> >>>>> Excerpts from Akihiro Motoki's message of 2018-05-14 18:52:55 +0900: >>>>> > 2018年5月12日(土) 3:04 Doug Hellmann <[email protected]>: >>>>> > >>>>> > > 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 <[email protected]>: >>>>> > > > >>>>> > > > > 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: >>>>> > > [email protected]?subject:unsubscribe >>>>> > > > > >>>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >>>>> > > > > >>>>> > > >>>>> > > >>>>> __________________________________________________________________________ >>>>> > > OpenStack Development Mailing List (not for usage questions) >>>>> > > Unsubscribe: >>>>> [email protected]?subject:unsubscribe >>>>> > > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >>>>> > > >>>>> >>>>> >>>>> __________________________________________________________________________ >>>>> OpenStack Development Mailing List (not for usage questions) >>>>> Unsubscribe: >>>>> [email protected]?subject:unsubscribe >>>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >>>>> >>>> >>>> >>>> __________________________________________________________________________ >>>> OpenStack Development Mailing List (not for usage questions) >>>> Unsubscribe: >>>> [email protected]?subject:unsubscribe >>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >>>> >>>> >>> >>> __________________________________________________________________________ >>> OpenStack Development Mailing List (not for usage questions) >>> Unsubscribe: >>> [email protected]?subject:unsubscribe >>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >>> >> >> __________________________________________________________________________ >> OpenStack Development Mailing List (not for usage questions) >> Unsubscribe: >> [email protected]?subject:unsubscribe >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >> >> > __________________________________________________________________________ > OpenStack Development Mailing List (not for usage questions) > Unsubscribe: [email protected]?subject:unsubscribe > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >
__________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: [email protected]?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
