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