<div dir="ltr">Hi all,<div><br></div><div>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].</div><div>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</div><div>next Django 2.2 LTS release which will be released next April. </div><div><br></div><div>We have to be careful to not break existing plugins and deployments by introducing new Django version requirement.</div><div>We need to work more closely with plugins teams to getting everything ready for Django 2.0+ before we change our requirements.txt.</div><div>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</div><div>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</div><div>much as we can in Rocky timeframe. </div><div><br></div><div>[2] <a href="https://www.djangoproject.com/download/">https://www.djangoproject.com/download/</a></div></div><div class="gmail_extra"><br clear="all"><div><div class="gmail_signature" data-smartmail="gmail_signature"><div dir="ltr"><div>Regards,<br>Ivan Kolodyazhny,<br><a href="http://blog.e0ne.info/" target="_blank">http://blog.e0ne.info/</a></div></div></div></div>
<br><div class="gmail_quote">On Mon, May 14, 2018 at 4:30 PM, Akihiro Motoki <span dir="ltr"><<a href="mailto:amotoki@gmail.com" target="_blank">amotoki@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><br><br><div class="gmail_quote"><div dir="ltr">2018年5月14日(月) 21:42 Doug Hellmann <<a href="mailto:doug@doughellmann.com" target="_blank">doug@doughellmann.com</a>>:<br></div><div><div class="h5"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Excerpts from Akihiro Motoki's message of 2018-05-14 18:52:55 +0900:<br>
> 2018年5月12日(土) 3:04 Doug Hellmann <<a href="mailto:doug@doughellmann.com" target="_blank">doug@doughellmann.com</a>>:<br>
> <br>
> > Excerpts from Akihiro Motoki's message of 2018-05-12 00:14:33 +0900:<br>
> > > Hi zigo and horizon plugin maintainers,<br>
> > ><br>
> > > Horizon itself already supports Django 2.0 and horizon unit test covers<br>
> > > Django 2.0 with Python 3.5.<br>
> > ><br>
> > > A question to all is whether we change the upper bound of Django from<br>
> > <2.0<br>
> > > to <2.1.<br>
> > > My proposal is to bump the upper bound of Django to <2.1 in Rocky-2.<br>
> > > (Note that Django 1.11 will continue to be used for python 2.7<br>
> > environment.)<br>
> ><br>
> > Do we need to cap it at all? We've been trying to express our<br>
> > dependencies without caps and rely on the constraints list to<br>
> > test using a common version because this offers the most flexibility as<br>
> > we move to newer versions over time.<br>
> ><br>
> <br>
> The main reason we cap django version so far is that django minor version<br>
> releases<br>
> contain some backward incompatible changes and also drop deprecated<br>
> features.<br>
> A new django minor version release like 1.11 usually breaks horizon and<br>
> plugins<br>
> as horizon developers are not always checking django deprecations.<br>
<br>
OK. Having the cap in place makes it more complicated to test<br>
upgrading, and then upgrade. Because we no longer synchronize<br>
requirements, changing openstack/requirements does not trigger the<br>
bot to propose the same change to all of the projects using the<br>
dependency. Someone will have to do that by hand in the future, as we<br>
are doing with eventlet right now<br>
(<a href="https://review.openstack.org/#/q/topic:uncap-eventlet" rel="noreferrer" target="_blank">https://review.openstack.org/<wbr>#/q/topic:uncap-eventlet</a>).<br>
<br>
Without the cap, we can test the upgrade by proposing a constraint<br>
update and running the horizon (and/or plugin) unit tests. When those<br>
tests pass, we can then step forward all at once by approving the<br>
constraint change.<br></blockquote><div><br></div></div></div><div>Thanks for the detail context.</div><div><br></div><div>Honestly I am not sure which is better to cap or uncap the django version.</div><div><div style="color:rgb(34,34,34);font-family:sans-serif;font-size:14px;font-style:normal;font-variant-ligatures:normal;font-variant-caps:normal;font-weight:400;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;background-color:rgb(255,255,255);text-decoration-style:initial;text-decoration-color:initial">We can try uncapping now and see what happens in the community.<br></div><div style="color:rgb(34,34,34);font-family:sans-serif;font-size:14px;font-style:normal;font-variant-ligatures:normal;font-variant-caps:normal;font-weight:400;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;background-color:rgb(255,255,255);text-decoration-style:initial;text-decoration-color:initial"><br></div><div style="color:rgb(34,34,34);font-family:sans-serif;font-size:14px;font-style:normal;font-variant-ligatures:normal;font-variant-caps:normal;font-weight:400;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;background-color:rgb(255,255,255);text-decoration-style:initial;text-decoration-color:initial">cross-horizon-(py27|py35) jobs of openstack/requirements checks<br></div></div><div>if horizon works with a new version. it works for horizon, but perhaps it potentially</div><div>break horizon plugins as it takes time to catch up with such changes.</div><div>On the other hand, a version bump in upper-constraints.txt would be</div><div>a good trigger for horizon plugin maintainers to sync all requirements.</div><div><br></div><div>In addition, requirements are not synchronized automatically,</div><div>so it seems not feasible to propose requirements changes per django version change.</div><div><div class="h5"><div> <br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
> <br>
> I have a question on uncapping the django version.<br>
> How can users/operators know which versions are supported?<br>
> Do they need to check upper-constraints.txt?<br>
<br>
We do tell downstream consumers that the upper-constraints.txt file is<br>
the set of things we test with, and that any other combination of<br>
packages would need to be tested on their systems separately.<br>
<br>
> <br>
> > > There are several points we should consider:<br>
> > > - If we change it in global-requirements.txt, it means Django 2.0 will be<br>
> > > used for python3.5 environment.<br>
> > > - Not a small number of horizon plugins still do not support Django 2.0,<br>
> > so<br>
> > > bumping the upper bound to <2.1 will break their py35 tests.<br>
> > > - From my experience of Django 2.0 support in some plugins, the required<br>
> > > changes are relatively simple like [1].<br>
> > ><br>
> > > I created an etherpad page to track Django 2.0 support in horizon<br>
> > plugins.<br>
> > > <a href="https://etherpad.openstack.org/p/django20-support" rel="noreferrer" target="_blank">https://etherpad.openstack.<wbr>org/p/django20-support</a><br>
> > ><br>
> > > I proposed Django 2.0 support patches to several projects which I think<br>
> > are<br>
> > > major.<br>
> > > # Do not blame me if I don't cover your project :)<br>
> > ><br>
> > > Thought?<br>
> ><br>
> > It seems like a good goal for the horizon-plugin author community<br>
> > to bring those projects up to date by supporting a current version<br>
> > of Django (and any other dependencies), especially as we discuss<br>
> > the impending switch over to python-3-first and then python-3-only.<br>
> ><br>
> <br>
> Yes, python 3 support is an important topic.<br>
> We also need to switch the default python version in mod_wsgi in DevStack<br>
> environment sooner or later.<br>
<br>
Is Python 3 ever used for mod_wsgi? Does the WSGI setup code honor<br>
the variable that tells devstack to use Python 3?<br></blockquote><div><br></div></div></div><div>Ubuntu 16.04 provides py2 and py3 versions of mod_wsgi (libapache2-mod-wsgi</div><div>and libapache2-mod-wsgi-py3) and as a quick look the only difference is a module</div><div>specified in LoadModule apache directive.</div><div>I haven't tested it yet, but it seems worth explored.</div><span class="HOEnZb"><font color="#888888"><div><br></div><div>Akihiro<br></div></font></span><div><div class="h5"><div><br></div><div>
<span></span>
</div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><br>
> <br>
> > If this is an area where teams need help, updating that etherpad<br>
> > with notes and requests for assistance will help us split up the<br>
> > work.<br>
> ><br>
> <br>
> Each team can help testing in Django 2.0 and/or python 3 support.<br>
> We need to enable corresponding server projects in development environments,<br>
> but it is not easy to setup all projects by horizon team. Individual<br>
> projects must be<br>
> more familiar with their own projects.<br>
> I sent several patches, but I actually tested them by unit tests.<br>
> <br>
> Thanks,<br>
> Akihiro<br>
> <br>
> ><br>
> > Doug<br>
> ><br>
> > ><br>
> > > Thanks,<br>
> > > Akihiro<br>
> > ><br>
> > > [1] <a href="https://review.openstack.org/#/c/566476/" rel="noreferrer" target="_blank">https://review.openstack.org/#<wbr>/c/566476/</a><br>
> > ><br>
> > > 2018年5月8日(火) 17:45 Thomas Goirand <<a href="mailto:zigo@debian.org" target="_blank">zigo@debian.org</a>>:<br>
> > ><br>
> > > > Hi,<br>
> > > ><br>
> > > > It has been decided that, in Debian, we'll switch to Django 2.0 after<br>
> > > > Buster will be released. Buster is to be frozen next February. This<br>
> > > > means that we have roughly one more year before Django 1.x goes away.<br>
> > > ><br>
> > > > Hopefully, Horizon will be ready for it, right?<br>
> > > ><br>
> > > > Hoping this helps,<br>
> > > > Cheers,<br>
> > > ><br>
> > > > Thomas Goirand (zigo)<br>
> > > ><br>
> > > ><br>
> > ______________________________<wbr>______________________________<wbr>______________<br>
> > > > OpenStack Development Mailing List (not for usage questions)<br>
> > > > Unsubscribe:<br>
> > <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" rel="noreferrer" target="_blank">OpenStack-dev-request@lists.<wbr>openstack.org?subject:<wbr>unsubscribe</a><br>
> > > > <a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" rel="noreferrer" target="_blank">http://lists.openstack.org/<wbr>cgi-bin/mailman/listinfo/<wbr>openstack-dev</a><br>
> > > ><br>
> ><br>
> > ______________________________<wbr>______________________________<wbr>______________<br>
> > OpenStack Development Mailing List (not for usage questions)<br>
> > Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" rel="noreferrer" target="_blank">OpenStack-dev-request@lists.<wbr>openstack.org?subject:<wbr>unsubscribe</a><br>
> > <a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" rel="noreferrer" target="_blank">http://lists.openstack.org/<wbr>cgi-bin/mailman/listinfo/<wbr>openstack-dev</a><br>
> ><br>
<br>
______________________________<wbr>______________________________<wbr>______________<br>
OpenStack Development Mailing List (not for usage questions)<br>
Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" rel="noreferrer" target="_blank">OpenStack-dev-request@lists.<wbr>openstack.org?subject:<wbr>unsubscribe</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" rel="noreferrer" target="_blank">http://lists.openstack.org/<wbr>cgi-bin/mailman/listinfo/<wbr>openstack-dev</a><br>
</blockquote></div></div></div></div>
<br>______________________________<wbr>______________________________<wbr>______________<br>
OpenStack Development Mailing List (not for usage questions)<br>
Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" rel="noreferrer" target="_blank">OpenStack-dev-request@lists.<wbr>openstack.org?subject:<wbr>unsubscribe</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" rel="noreferrer" target="_blank">http://lists.openstack.org/<wbr>cgi-bin/mailman/listinfo/<wbr>openstack-dev</a><br>
<br></blockquote></div><br></div>