Hi On Sat, Jun 2, 2018 at 9:50 PM, Akihiro Motoki <amot...@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 <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 > >
__________________________________________________________________________ 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
