[openstack-dev] [horizon] Scheduling switch to django >= 2.0

[Thomas Goirand]

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.)

All this is nice, thanks for working on Django 2.x. But Debian Buster
will be released with Django 1.11 and Python 3.6. So what I need, as far
as Debian is concerned is:

- Python 3.6 & Django 1.11 for Rocky (that's for Debian Buster).
- Python 3.6, probably even 3.7 and Django 2.0 for Stein (that's for
after Buster is released).

Cheers,

Thomas Goirand (zigo)

__________________________________________________________________________
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: OpenStack-dev-***@lists.openstack.org?subject:unsubscribe
http://lists.

[Doug Hellmann]

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.

- 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.

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.

Doug

Thanks,
Akihiro
[1] https://review.openstack.org/#/c/566476/

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)
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

__________________________________________________________________________
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: OpenStack-dev-***@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cg

[Akihiro Motoki]

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.

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?

- 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.

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/

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)
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

__________________________________________________________________________
OpenStack Development Mailing List (not for usage questions)
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[Doug Hellmann]

Post by Akihiro Motoki

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.

Post by Akihiro Motoki
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.

Post by Akihiro Motoki

- 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?

Post by Akihiro Motoki

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/

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)
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

__________________________________________________________________________
OpenStack Development Mailing List (not for usage questions)
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

__________________________________________________________________________
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: OpenStack-dev-***@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mai

[Akihiro Motoki]

Post by Akihiro Motoki

Hi zigo and horizon plugin maintainers,
Horizon itself already supports Django 2.0 and horizon unit test

covers

Post by Akihiro Motoki

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.

Post by Akihiro Motoki
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.

Post by Akihiro Motoki

- If we change it in global-requirements.txt, it means Django 2.0

will be

Post by Akihiro Motoki

used for python3.5 environment.
- Not a small number of horizon plugins still do not support Django

2.0,

Post by Akihiro Motoki

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

Post by Akihiro Motoki

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

Post by Akihiro Motoki

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

Post by Akihiro Motoki

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,

Post by Akihiro Motoki
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/

Hi,
It has been decided that, in Debian, we'll switch to Django 2.0

after

Post by Akihiro Motoki

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.

Post by Akihiro Motoki

Hopefully, Horizon will be ready for it, right?
Hoping this helps,
Cheers,
Thomas Goirand (zigo)

__________________________________________________________________________

Post by Akihiro Motoki

OpenStack Development Mailing List (not for usage questions)
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

__________________________________________________________________________

Post by Akihiro Motoki

OpenStack Development Mailing List (not for usage questions)
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

__________________________________________________________________________
OpenStack Development Mailing List (not for usage questions)
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[Ivan Kolodyazhny]

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/

Post by Akihiro Motoki

Post by Akihiro Motoki

Hi zigo and horizon plugin maintainers,
Horizon itself already supports Django 2.0 and horizon unit test

covers

Post by Akihiro Motoki

Django 2.0 with Python 3.5.
A question to all is whether we change the upper bound of Django

from

Post by Akihiro Motoki

<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

Post by Akihiro Motoki

we move to newer versions over time.

The main reason we cap django version so far is that django minor

version

Post by Akihiro Motoki
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.

Post by Akihiro Motoki
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.

Post by Akihiro Motoki

- If we change it in global-requirements.txt, it means Django 2.0

will be

Post by Akihiro Motoki

used for python3.5 environment.
- Not a small number of horizon plugins still do not support Django

2.0,

Post by Akihiro Motoki

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

Post by Akihiro Motoki

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

Post by Akihiro Motoki

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

Post by Akihiro Motoki
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

Post by Akihiro Motoki

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,

Post by Akihiro Motoki
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/

Hi,
It has been decided that, in Debian, we'll switch to Django 2.0

after

Post by Akihiro Motoki

Buster will be released. Buster is to be frozen next February.

This

Post by Akihiro Motoki

means that we have roughly one more year before Django 1.x goes

away.

Post by Akihiro Motoki

Hopefully, Horizon will be ready for it, right?
Hoping this helps,
Cheers,
Thomas Goirand (zigo)

____________________________________________________________

______________

Post by Akihiro Motoki

OpenStack Development Mailing List (not for usage questions)
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

____________________________________________________________

______________

Post by Akihiro Motoki

OpenStack Development Mailing List (not for usage questions)

unsubscribe

Post by Akihiro Motoki

http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

____________________________________________________________
______________
OpenStack Development Mailing List (not for usage questions)
unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

__________________________________________________________________________
OpenStack Development Mailing List (not for usage questions)
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[Doug Hellmann]

Post by Ivan Kolodyazhny
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.

That sounds like a good plan, thanks Ivan.

Doug

Post by Ivan Kolodyazhny
[2] https://www.djangoproject.com/download/
Regards,
Ivan Kolodyazhny,
http://blog.e0ne.info/

Post by Akihiro Motoki

Post by Akihiro Motoki

Hi zigo and horizon plugin maintainers,
Horizon itself already supports Django 2.0 and horizon unit test

covers

Post by Akihiro Motoki

Django 2.0 with Python 3.5.
A question to all is whether we change the upper bound of Django

from

Post by Akihiro Motoki

<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

Post by Akihiro Motoki

we move to newer versions over time.

The main reason we cap django version so far is that django minor

version

Post by Akihiro Motoki
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.

Post by Akihiro Motoki
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.

Post by Akihiro Motoki

- If we change it in global-requirements.txt, it means Django 2.0

will be

Post by Akihiro Motoki

used for python3.5 environment.
- Not a small number of horizon plugins still do not support Django

2.0,

Post by Akihiro Motoki

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

Post by Akihiro Motoki

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

Post by Akihiro Motoki

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

Post by Akihiro Motoki
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

Post by Akihiro Motoki

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,

Post by Akihiro Motoki
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/

Hi,
It has been decided that, in Debian, we'll switch to Django 2.0

after

Post by Akihiro Motoki

Buster will be released. Buster is to be frozen next February.

This

Post by Akihiro Motoki

means that we have roughly one more year before Django 1.x goes

away.

Post by Akihiro Motoki

Hopefully, Horizon will be ready for it, right?
Hoping this helps,
Cheers,
Thomas Goirand (zigo)

____________________________________________________________

______________

Post by Akihiro Motoki

OpenStack Development Mailing List (not for usage questions)
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

____________________________________________________________

______________

Post by Akihiro Motoki

OpenStack Development Mailing List (not for usage questions)

unsubscribe

Post by Akihiro Motoki

http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

____________________________________________________________
______________
OpenStack Development Mailing List (not for usage questions)
unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

__________________________________________________________________________
OpenStack Development Mailing List (not for usage questions)
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

__________________________________________________________________________
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: OpenStack-dev-***@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/

[Thomas Goirand]

Post by Doug Hellmann
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

libapache2-mod-wsgi-py3 is what's in use in all Debian packages for
OpenStack, and it works well, including for Horizon.

Cheers,

Thomas Goirand (zigo)

__________________________________________________________________________
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: OpenStack-dev-***@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-b