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