[requirements][horizon] Requirements freeze exception request
Hello, I would like to request a requirements freeze exception to bump the version of Django from 4.2.28 to 5.2.12. It is important for Horizon to ship with a version of Django that is security supported, and the security support for Django 4.2.8 ends next month. Django 5.2.12 is a long-term-support release, and will have security support for the next two years [1]. We have been working on making Horizon compatible with Django 5.2 in this release, but the disruption of the gates and the distractions caused by it in the last few weeks prevented us from getting the relevant patches merged on time for the freeze [2]. The patch for requirements is [3] [1] https://endoflife.date/django [2] https://review.opendev.org/c/openstack/horizon/+/973902 [3] https://review.opendev.org/c/openstack/requirements/+/979862 -- Radomir Dopieralski
On 11/03/2026 07:16, Radomir Dopieralski wrote:
Hello,
I would like to request a requirements freeze exception to bump the version of Django from 4.2.28 to 5.2.12. do all the plugins work with 5.2 its very late in the cycle to do this when we are a day form create rc1 and the sabel branch.
horizon-tox-python3-django52 <https://zuul.opendev.org/t/openstack/build/e7517df569db4b73bf96c9d555e07387> was passing on the watcher dashboard but its failing on your bump patch https://review.opendev.org/c/openstack/horizon/+/979858 i dont know how much testing there actully has been so this seam somewhat risky to do this late in the cycle. has there been any devstack/tempest/end to end testing done in ci with 5.2 this cycle?
It is important for Horizon to ship with a version of Django that is security supported, and the security support for Django 4.2.8 ends next month. Django 5.2.12 is a long-term-support release, and will have security support for the next two years [1].
We have been working on making Horizon compatible with Django 5.2 in this release, but the disruption of the gates and the distractions caused by it in the last few weeks prevented us from getting the relevant patches merged on time for the freeze [2].
The patch for requirements is [3]
[1] https://endoflife.date/django [2] https://review.opendev.org/c/openstack/horizon/+/973902 [3] https://review.opendev.org/c/openstack/requirements/+/979862
-- Radomir Dopieralski
Hello, I'm listing here all the patches we'd need for the Django 5.2 track: - 979941: Release Horizon 26.0.0 for 2026.1 Gazpacho | https://review.opendev.org/c/openstack/releases/+/979941 -- includes the most recent fixes for Django 5.2 - "update constraint for horizon to new release 26.0.0" should be submitted by OpenStack Proposal Bot after the release patch is merged - 979862: Update Django to 5.2.12 | https://review.opendev.org/c/openstack/requirements/+/979862 - RFE && discussion about this: https://lists.openstack.org/archives/list/openstack-discuss@lists.openstack.... - Tests are failing now since the older Horizon release is used, need to update it to 26.0.0 - 979858: Bump django version to 5.2 | https://review.opendev.org/c/openstack/horizon/+/979858 Regards, Tatiana On Wed, Mar 11, 2026 at 7:04 AM Sean Mooney <smooney@redhat.com> wrote:
On 11/03/2026 07:16, Radomir Dopieralski wrote:
Hello,
I would like to request a requirements freeze exception to bump the version of Django from 4.2.28 to 5.2.12. do all the plugins work with 5.2 its very late in the cycle to do this when we are a day form create rc1 and the sabel branch.
horizon-tox-python3-django52 < https://zuul.opendev.org/t/openstack/build/e7517df569db4b73bf96c9d555e07387>
was passing on the watcher dashboard but its failing on your bump patch
https://review.opendev.org/c/openstack/horizon/+/979858
i dont know how much testing there actully has been so this seam somewhat risky to do this late in the cycle. has there been any devstack/tempest/end to end testing done in ci with 5.2 this cycle?
It is important for Horizon to ship with a version of Django that is security supported, and the security support for Django 4.2.8 ends next month. Django 5.2.12 is a long-term-support release, and will have security support for the next two years [1].
We have been working on making Horizon compatible with Django 5.2 in this release, but the disruption of the gates and the distractions caused by it in the last few weeks prevented us from getting the relevant patches merged on time for the freeze [2].
The patch for requirements is [3]
[1] https://endoflife.date/django [2] https://review.opendev.org/c/openstack/horizon/+/973902 [3] https://review.opendev.org/c/openstack/requirements/+/979862
-- Radomir Dopieralski
On 2026-03-11 09:27:57 -0500 (-0500), Tatiana Ovchinnikova wrote: [...]
- Tests are failing now since the older Horizon release is used, need to update it to 26.0.0 [...]
I think this shows a fundamental disconnect between release process and requirements handling. We should not be constraining type:service deliverables in cross-project testing, only type:library and type:client-library. If the horizon deliverable is actually being used more as a library then the deadline for making the final release was a month ago to give time for requirements updates. If it's really being used as a service then we should be testing with the current branch state and not relying on trying to get requirements updates merged during release candidate week when that was frozen weeks ago. I don't know how this should be solved for the current cycle, but it desperately needs to be revisited early next cycle. If it can't be reconciled, then affected jobs need to be setting horizon as a required-project and relying on tooling that installs it from Git instead of PyPI (and making on-the-fly edits to the constraints file to omit it at runtime). This currently works for normal Tox and DevStack based jobs, but I don't know which jobs you're referring to failing due to stale constraints so it's possible the jobs are simply misconfigured? -- Jeremy Stanley
Looking at https://codesearch.opendev.org/?q=import%20horizon&i=nope&literal=nope&files=&excludeFiles=&repos= horizon is used more like a library in the respective UI plugin repositories Michal
On 11 Mar 2026, at 16:10, Jeremy Stanley <fungi@yuggoth.org> wrote:
On 2026-03-11 09:27:57 -0500 (-0500), Tatiana Ovchinnikova wrote: [...]
- Tests are failing now since the older Horizon release is used, need to update it to 26.0.0 [...]
I think this shows a fundamental disconnect between release process and requirements handling. We should not be constraining type:service deliverables in cross-project testing, only type:library and type:client-library. If the horizon deliverable is actually being used more as a library then the deadline for making the final release was a month ago to give time for requirements updates. If it's really being used as a service then we should be testing with the current branch state and not relying on trying to get requirements updates merged during release candidate week when that was frozen weeks ago.
I don't know how this should be solved for the current cycle, but it desperately needs to be revisited early next cycle. If it can't be reconciled, then affected jobs need to be setting horizon as a required-project and relying on tooling that installs it from Git instead of PyPI (and making on-the-fly edits to the constraints file to omit it at runtime). This currently works for normal Tox and DevStack based jobs, but I don't know which jobs you're referring to failing due to stale constraints so it's possible the jobs are simply misconfigured? -- Jeremy Stanley
On 2026-03-12 08:04:20 +0100 (+0100), Michał Nasiadka wrote:
Looking at https://codesearch.opendev.org/?q=import%20horizon&i=nope&literal=nope&files=&excludeFiles=&repos= horizon is used more like a library in the respective UI plugin repositories [...]
Neutron had a similar problem, and split out a neutron-lib deliverable to deal with it. The constraints list covers neutron-lib which gets its final release of the cycle at the same time as other libraries, and does not constrain neutron itself which is released with other services at the end of the development cycle. I worry that in this case the Horizon team probably lacks sufficient bandwidth to undertake such a split (doing it took the Neutron team years and they were a larger team to begin with), so we may need to look at alternative compromises like treating the horizon deliverable as a library in release management in order to be consistent with how it's handled in requirements, or changing the way horizon is installed when testing plugins. -- Jeremy Stanley
Looking at https://codesearch.opendev.org/?q=import%20horizon&i=nope&literal=nope&files=&excludeFiles=&repos= <https://codesearch.opendev.org/?q=import%20horizon&i=nope&literal=nope&files=&excludeFiles=&repos=> horizon is used more like a library in the respective UI plugin repositories it is yes and unlike neutron it does not have a seprate horizon-lib package.
On 12/03/2026 07:04, Michał Nasiadka wrote: plugins inherit or consume templates, JavaScript components and python calsses/methods. the depencies are on boht the core horizion lib parts https://github.com/openstack/horizon/tree/master/horizon and the horzion dashbaord apllciation https://github.com/openstack/horizon/tree/master/openstack_dashboard https://codesearch.opendev.org/?q=openstack_dashboard&i=nope&literal=nope&files=&excludeFiles=&repos= there is also the https://github.com/openstack/horizon/tree/master/openstack_auth django extnsion which some plugins also need to consume https://codesearch.opendev.org/?q=from%20openstack_auth&i=nope&literal=nope&files=&excludeFiles=&repos= so its a mix of library component and a service with no clean split today.
Michal
On 11 Mar 2026, at 16:10, Jeremy Stanley <fungi@yuggoth.org> wrote:
On 2026-03-11 09:27:57 -0500 (-0500), Tatiana Ovchinnikova wrote: [...]
- Tests are failing now since the older Horizon release is used, need to update it to 26.0.0 [...]
I think this shows a fundamental disconnect between release process and requirements handling. We should not be constraining type:service deliverables in cross-project testing, only type:library and type:client-library. If the horizon deliverable is actually being used more as a library then the deadline for making the final release was a month ago to give time for requirements updates. If it's really being used as a service then we should be testing with the current branch state and not relying on trying to get requirements updates merged during release candidate week when that was frozen weeks ago.
I don't know how this should be solved for the current cycle, but it desperately needs to be revisited early next cycle. If it can't be reconciled, then affected jobs need to be setting horizon as a required-project and relying on tooling that installs it from Git instead of PyPI (and making on-the-fly edits to the constraints file to omit it at runtime). This currently works for normal Tox and DevStack based jobs, but I don't know which jobs you're referring to failing due to stale constraints so it's possible the jobs are simply misconfigured? -- Jeremy Stanley
Looking at https://codesearch.opendev.org/?q=import%20horizon&i=nope&literal=nope&files=&excludeFiles=&repos= <https://codesearch.opendev.org/?q=import%20horizon&i=nope&literal=nope&files=&excludeFiles=&repos=> horizon is used more like a library in the respective UI plugin repositories it is yes and unlike neutron it does not have a seprate horizon-lib package.
From Release team perspective, the question is now whether the new django 5.2 version bump can be included or not in 2026.1 Gazpacho, and we need to have a decision as soon as possible - in order to be able to fix if any issue comes up from the change. In general, we are very late at the cycle, so probably the task has to be left to vendors to fix this downstream, but that is unfortunate :-/ It would be good to get some opinion about the django version bump so that we can act swiftly. Thanks, Elod irc: elodilles @ #openstack-release ________________________________________ From: Sean Mooney <smooney@redhat.com> Sent: Thursday, March 12, 2026 14:18 To: Michał Nasiadka; openstack-discuss@lists.openstack.org Subject: Re: [requirements][horizon] Requirements freeze exception request On 12/03/2026 07:04, Michał Nasiadka wrote: plugins inherit or consume templates, JavaScript components and python calsses/methods. the depencies are on boht the core horizion lib parts https://github.com/openstack/horizon/tree/master/horizon and the horzion dashbaord apllciation https://github.com/openstack/horizon/tree/master/openstack_dashboard https://codesearch.opendev.org/?q=openstack_dashboard&i=nope&literal=nope&files=&excludeFiles=&repos= there is also the https://github.com/openstack/horizon/tree/master/openstack_auth django extnsion which some plugins also need to consume https://codesearch.opendev.org/?q=from%20openstack_auth&i=nope&literal=nope&files=&excludeFiles=&repos= so its a mix of library component and a service with no clean split today.
Michal
On 11 Mar 2026, at 16:10, Jeremy Stanley <fungi@yuggoth.org> wrote:
On 2026-03-11 09:27:57 -0500 (-0500), Tatiana Ovchinnikova wrote: [...]
- Tests are failing now since the older Horizon release is used, need to update it to 26.0.0 [...]
I think this shows a fundamental disconnect between release process and requirements handling. We should not be constraining type:service deliverables in cross-project testing, only type:library and type:client-library. If the horizon deliverable is actually being used more as a library then the deadline for making the final release was a month ago to give time for requirements updates. If it's really being used as a service then we should be testing with the current branch state and not relying on trying to get requirements updates merged during release candidate week when that was frozen weeks ago.
I don't know how this should be solved for the current cycle, but it desperately needs to be revisited early next cycle. If it can't be reconciled, then affected jobs need to be setting horizon as a required-project and relying on tooling that installs it from Git instead of PyPI (and making on-the-fly edits to the constraints file to omit it at runtime). This currently works for normal Tox and DevStack based jobs, but I don't know which jobs you're referring to failing due to stale constraints so it's possible the jobs are simply misconfigured? -- Jeremy Stanley
If the risk is too much, I think it's actually fine if we release with Django 4.2 as the official dependency, but mention in the release notes that it also works with Django 5.2, so that distributions can use a supported version of Django if they choose to do so. If any of the plugins won't work with that, the distributions can then make a decision to either not ship them, or use an unsupported version. Horizon is already split into the Dashboard application itself (openstack-dashboard) and two libraries (python-django-horizon and openstack-auth) that are supposed to be used by the plugins. They go into separate packages when built. However, since the code lives in the same repository, and since you practically always have all three installed, plugin developers came to depend on all three of them, not just the libraries. I don't think the plugins have enough bandwidth to undertake a cleanup of their dependencies to only use the code from the libraries and not from the horizon application itself, though we could try to discuss the possibility of such an initiative. On Thu, Mar 12, 2026 at 2:56 PM Elõd Illés <elod.illes@est.tech> wrote:
From Release team perspective, the question is now whether the new django 5.2 version bump can be included or not in 2026.1 Gazpacho, and we need to have a decision as soon as possible - in order to be able to fix if any issue comes up from the change. In general, we are very late at the cycle, so probably the task has to be left to vendors to fix this downstream, but that is unfortunate :-/ It would be good to get some opinion about the django version bump so that we can act swiftly.
Thanks, Elod irc: elodilles @ #openstack-release
________________________________________ From: Sean Mooney <smooney@redhat.com> Sent: Thursday, March 12, 2026 14:18 To: Michał Nasiadka; openstack-discuss@lists.openstack.org Subject: Re: [requirements][horizon] Requirements freeze exception request
On 12/03/2026 07:04, Michał Nasiadka wrote:
Looking at
< https://codesearch.opendev.org/?q=import%20horizon&i=nope&literal=nope&files=&excludeFiles=&repos= horizon is used more like a library in the respective UI plugin repositories it is yes and unlike neutron it does not have a seprate horizon-lib
https://codesearch.opendev.org/?q=import%20horizon&i=nope&literal=nope&files=&excludeFiles=&repos= package. plugins inherit or consume templates, JavaScript components and python calsses/methods. the depencies are on boht the core horizion lib parts https://github.com/openstack/horizon/tree/master/horizon and the horzion dashbaord apllciation https://github.com/openstack/horizon/tree/master/openstack_dashboard
there is also the https://github.com/openstack/horizon/tree/master/openstack_auth django extnsion which
some plugins also need to consume
so its a mix of library component and a service with no clean split today.
Michal
On 11 Mar 2026, at 16:10, Jeremy Stanley <fungi@yuggoth.org> wrote:
On 2026-03-11 09:27:57 -0500 (-0500), Tatiana Ovchinnikova wrote: [...]
- Tests are failing now since the older Horizon release is used, need
to
update it to 26.0.0 [...]
I think this shows a fundamental disconnect between release process and requirements handling. We should not be constraining type:service deliverables in cross-project testing, only type:library and type:client-library. If the horizon deliverable is actually being used more as a library then the deadline for making the final release was a month ago to give time for requirements updates. If it's really being used as a service then we should be testing with the current branch state and not relying on trying to get requirements updates merged during release candidate week when that was frozen weeks ago.
I don't know how this should be solved for the current cycle, but it desperately needs to be revisited early next cycle. If it can't be reconciled, then affected jobs need to be setting horizon as a required-project and relying on tooling that installs it from Git instead of PyPI (and making on-the-fly edits to the constraints file to omit it at runtime). This currently works for normal Tox and DevStack based jobs, but I don't know which jobs you're referring to failing due to stale constraints so it's possible the jobs are simply misconfigured? -- Jeremy Stanley
-- Radomir Dopieralski
Horizon had a non-voting job for Django 5.2 since the beginning of the current cycle, however there's no good way to check if all the plugins work with 5.2 as well at this point. If we choose to release with Django 4.2, I would like to request an exception for updating it to 4.2.29 to include CVE fixes: https://review.opendev.org/c/openstack/requirements/+/980133 Regards, Tatiana On Thu, Mar 12, 2026 at 8:56 AM Elõd Illés <elod.illes@est.tech> wrote:
From Release team perspective, the question is now whether the new django 5.2 version bump can be included or not in 2026.1 Gazpacho, and we need to have a decision as soon as possible - in order to be able to fix if any issue comes up from the change. In general, we are very late at the cycle, so probably the task has to be left to vendors to fix this downstream, but that is unfortunate :-/ It would be good to get some opinion about the django version bump so that we can act swiftly.
Thanks, Elod irc: elodilles @ #openstack-release
________________________________________ From: Sean Mooney <smooney@redhat.com> Sent: Thursday, March 12, 2026 14:18 To: Michał Nasiadka; openstack-discuss@lists.openstack.org Subject: Re: [requirements][horizon] Requirements freeze exception request
On 12/03/2026 07:04, Michał Nasiadka wrote:
Looking at
< https://codesearch.opendev.org/?q=import%20horizon&i=nope&literal=nope&files=&excludeFiles=&repos= horizon is used more like a library in the respective UI plugin repositories it is yes and unlike neutron it does not have a seprate horizon-lib
https://codesearch.opendev.org/?q=import%20horizon&i=nope&literal=nope&files=&excludeFiles=&repos= package. plugins inherit or consume templates, JavaScript components and python calsses/methods. the depencies are on boht the core horizion lib parts https://github.com/openstack/horizon/tree/master/horizon and the horzion dashbaord apllciation https://github.com/openstack/horizon/tree/master/openstack_dashboard
there is also the https://github.com/openstack/horizon/tree/master/openstack_auth django extnsion which
some plugins also need to consume
so its a mix of library component and a service with no clean split today.
Michal
On 11 Mar 2026, at 16:10, Jeremy Stanley <fungi@yuggoth.org> wrote:
On 2026-03-11 09:27:57 -0500 (-0500), Tatiana Ovchinnikova wrote: [...]
- Tests are failing now since the older Horizon release is used, need
to
update it to 26.0.0 [...]
I think this shows a fundamental disconnect between release process and requirements handling. We should not be constraining type:service deliverables in cross-project testing, only type:library and type:client-library. If the horizon deliverable is actually being used more as a library then the deadline for making the final release was a month ago to give time for requirements updates. If it's really being used as a service then we should be testing with the current branch state and not relying on trying to get requirements updates merged during release candidate week when that was frozen weeks ago.
I don't know how this should be solved for the current cycle, but it desperately needs to be revisited early next cycle. If it can't be reconciled, then affected jobs need to be setting horizon as a required-project and relying on tooling that installs it from Git instead of PyPI (and making on-the-fly edits to the constraints file to omit it at runtime). This currently works for normal Tox and DevStack based jobs, but I don't know which jobs you're referring to failing due to stale constraints so it's possible the jobs are simply misconfigured? -- Jeremy Stanley
participants (7)
-
Elõd Illés
-
Jeremy Stanley
-
Michał Nasiadka
-
Radomir Dopieralski
-
Radomir Dopieralski
-
Sean Mooney
-
Tatiana Ovchinnikova