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