Given that in practice it is not really a library, it's not listed in global-requirements, and we will likely switch its type next cycle, I would consider just allowing a new release to fix this.

It should not create any issue with requirements since nothing lists it as a dependency. It would not even need a RFE.

Előd Illés wrote:

Hi,

Sorry for the late answer.

First of all we are in library freeze period already and blazar-nova is currently marked as library. Though a Requirements Freeze Exception might be granted (would need to check with Matthew), I think it's not necessary. This is mostly a problem when distros do their packaging, but I guess due to nova's lower constraints change they already need to use the higher minimums.

Some more comments:

• though requirements shouldn't be changed on stable branches in

general, i think this can be backported *after* the final yoga release (to unblock the gate)

• I think release model change is OK and can be proposed for Zed cycle

Cheers,

Előd

On 2022. 03. 04. 17:36, Pierre Riteau wrote:

...

Hello release team,

blazar-nova is a package including a nova scheduler filter, which must be installed together with nova to be used.

The blazar-nova deliverable for Yoga was tagged with 2.4.0 at the time of the final release for non-client libraries. A few days ago, stable/yoga patches were automatically proposed. This is when I discovered that the lower-constraints job was broken because nova bumped some requirements / lower-constraints after we released [1] [2]. Because blazar-nova and nova are installed together, we keep our requirements in sync for testing purposes.

Now, I believe it is just the lower-constraints testing that is broken, since nova requirements are still compatible with what blazar-nova requires: nova just requires more recent versions of some packages. I can run "pip install blazar-nova git+https://opendev.org/openstack/nova.git@master#egg=nova" fine.

I fixed the issue on the blazar-nova master branch [3] and proposed a backport to stable/yoga [4], but realised this was probably breaking release policy. Should we leave stable/yoga as released and just drop the lower-constraints job?

As an aside, would it be possible to requalify blazar-nova as a cycle-with-rc deliverable for the next release? It is typed as a library but nothing depends on it: if anything, it depends on nova itself.

Thanks, Pierre Riteau (priteau)

[1] https://review.opendev.org/c/openstack/nova/+/712139 [2] https://review.opendev.org/c/openstack/nova/+/821606 [3] https://review.opendev.org/c/openstack/blazar-nova/+/831741 [4] https://review.opendev.org/c/openstack/blazar-nova/+/831832

Thank you both for your help. blazar-nova 2.5.0 has been released, this issue is now resolved.

On Wed, 16 Mar 2022 at 15:10, Előd Illés elod.illes@est.tech wrote:

Thanks Thierry, you are right. Let's release then!

Előd

On 2022. 03. 16. 14:25, Thierry Carrez wrote:

...

Given that in practice it is not really a library, it's not listed in global-requirements, and we will likely switch its type next cycle, I would consider just allowing a new release to fix this.

It should not create any issue with requirements since nothing lists it as a dependency. It would not even need a RFE.

Előd Illés wrote:

...

Hi,

Sorry for the late answer.

First of all we are in library freeze period already and blazar-nova is currently marked as library. Though a Requirements Freeze Exception might be granted (would need to check with Matthew), I think it's not necessary. This is mostly a problem when distros do their packaging, but I guess due to nova's lower constraints change they already need to use the higher minimums.

Some more comments:

• though requirements shouldn't be changed on stable branches in

general, i think this can be backported *after* the final yoga release (to unblock the gate)

• I think release model change is OK and can be proposed for Zed cycle

Cheers,

Előd

On 2022. 03. 04. 17:36, Pierre Riteau wrote:

...

Hello release team,

blazar-nova is a package including a nova scheduler filter, which must be installed together with nova to be used.

The blazar-nova deliverable for Yoga was tagged with 2.4.0 at the time of the final release for non-client libraries. A few days ago, stable/yoga patches were automatically proposed. This is when I discovered that the lower-constraints job was broken because nova bumped some requirements / lower-constraints after we released [1] [2]. Because blazar-nova and nova are installed together, we keep our requirements in sync for testing purposes.

Now, I believe it is just the lower-constraints testing that is broken, since nova requirements are still compatible with what blazar-nova requires: nova just requires more recent versions of some packages. I can run "pip install blazar-nova git+https://opendev.org/openstack/nova.git@master#egg=nova" fine.

I fixed the issue on the blazar-nova master branch [3] and proposed a backport to stable/yoga [4], but realised this was probably breaking release policy. Should we leave stable/yoga as released and just drop the lower-constraints job?

As an aside, would it be possible to requalify blazar-nova as a cycle-with-rc deliverable for the next release? It is typed as a library but nothing depends on it: if anything, it depends on nova itself.

Thanks, Pierre Riteau (priteau)

[1] https://review.opendev.org/c/openstack/nova/+/712139 [2] https://review.opendev.org/c/openstack/nova/+/821606 [3] https://review.opendev.org/c/openstack/blazar-nova/+/831741 [4] https://review.opendev.org/c/openstack/blazar-nova/+/831832