March 2024 - openstack-discuss - lists.openstack.org

[oslo] Removing feature branches of oslo.messaging
by Takashi Kajinami 01 Mar '24

01 Mar '24

Hello, # I already discussed this with a few people but am sending this email # mostly for records. Currently we have a few feature branches in oslo.messaging but it seems these are not actually used now. feature/amqp-dispatch-router : the feature was already merged into master feature/nats-driver : this branch contains no meaningful change feature/pika : the feature was already merged into master feature/zmq : the feature was already merged into master I'd propose deleting these useless branches. Note that currently the nats-driver branch is causing config error in zuul, which was triggered by TripleO's retirement, and my quick attempt revealed that, as I expected, CI in that branch is badly broken. Please let me know if you have any concern. Thank you, Takashi -- Takashi Kajinami irc: tkajinam github: https://github.com/kajinamit launchpad: https://launchpad.net/~kajinamit

3 2

[release] Release countdown for week R-4, March 04-08
by Herve Beraud 01 Mar '24

01 Mar '24

Development Focus ----------------- We just passed feature freeze! Until release branches are cut, you should stop accepting featureful changes to deliverables following the cycle-with-rc release model, or to libraries. Exceptions should be discussed on separate threads on the mailing-list, and feature freeze exceptions approved by the team's PTL. Focus should be on finding and fixing release-critical bugs, so that release candidates and final versions of the 2024.1/Caracal deliverables can be proposed, well ahead of the final 2024.1/Caracal release date. General Information ------------------- We are still finishing up processing a few release requests, but the 2024.1/Caracal release requirements are now frozen. If new library releases are needed to fix release-critical bugs in 2024.1/Caracal, you must request a Requirements Freeze Exception (RFE) from the requirements team before we can do a new release to avoid having something released in 2024.1/Caracal that is not actually usable. This is done by posting to the openstack-discuss mailing list with a subject line similar to: [$PROJECT][requirements] RFE requested for $PROJECT_LIB Include justification/reasoning for why a RFE is needed for this lib. If/when the requirements team OKs the post-freeze update, we can then process a new release. A soft String freeze is now in effect, in order to let the I18N team do the translation work in good conditions. In Horizon and the various dashboard plugins, you should stop accepting changes that modify user-visible strings. Exceptions should be discussed on the mailing-list. By March 25, 2024 this will become a hard string freeze, with no changes in user-visible strings allowed. Actions ------- stable/2024.1 branches should be created soon for all not-already-branched libraries. You should expect 2-3 changes to be proposed for each: a .gitreview update, a reno update (skipped for projects not using reno), and a tox.ini constraints URL update. Please review those in priority so that the branch can be functional ASAP. The Prelude section of reno release notes is rendered as the top level overview for the release. Any important overall messaging for 2024.1/Caracal changes should be added there to make sure the consumers of your release notes see them. Upcoming Deadlines & Dates -------------------------- Cycle Highlights Due: March 7th, 2024 (R-4 week) RC1 deadline: week of March 11, 2024 (R-3 week) Final RC deadline: week of March 25, 2024 (R-1 week) Final 2024.1/Caracal release: April 3, 2024 Dalmatian PTG: April 8-12, 2024 -- Hervé Beraud Senior Software Engineer at Red Hat irc: hberaud https://github.com/4383/

1 0

[TC][openapi] Request for new projects under the OpenStack hat
by gtema 01 Mar '24

01 Mar '24

Hi TC representatives, Some time ago I was communicating about my POC on generating OpenAPI schemas from the source code of services. I continued working on that and have now few projects (that I was developing on GitHub to make life easier) that I would like to bring under the OpenStack hood (and place them under the SDK team). I have also figured out that Nova is now reviewing spec on starting using supporting this (thanks Stephen) and Neutron folks expressed also interest. === codegenerator https://gtema.github.io/openstack-codegenerator/ This project is responsible for generation of the OpenAPI specs and generate other (currently user-facing) code ouf of them === openstack-openapi https://gtema.github.io/openstack-openapi/ This repo hosts rendered specs and provides analogue to the os-api-ref Sphinx extension that renders them into the html (what you see under the link is a mix of Swagger and os-api-ref style). I was not really effectively working on that rendering lately, the repo right now is more or less a storage for the specs themselves with a first sketch of sphinx extension of rendering and basic OpenAPI flavoring doc. === openstack-rs https://gtema.github.io/openstack/ This is a Rust monorepo project with few items: - SDK for OpenStack out of the rendered OpenAPI specs - experimental CLI following very different approach compared to the python- openstackclient. It is compiled into single binary (what helps those not willing to pull whole python with all deps and the insanity we experience lately or those who build docker containers with only OSC inside to bypass the mentioned hell) and purely auto-generated from the specs - [future] openstack-tui (similar to k9s for Kubernetes) Here it is all really oriented only on the user facing tooling. I am very convinced in this project and will continue working on it independent on the outcome. Any objections/ideas/comments? Should I just go and create 3 project-config changes pending the approval? ====== Since I am on this topic anyway I would also like to address another related question. While working for OpenTelekomCloud we developed HashiVault plugin for managing OpenStack credentials as secrets (I had a talk on that in Vancouver). We tried to bring this to OpenDev but were unsure under which namespace. Pretty shortly a Hashi license issue started circling around and after few back and forth iterations we were not sure what to do with that project at all. Anyway the plugin itself is Apache-2 and working. It should be possible to also use it with OpenBAO (as a fork of Vault), but it was not tested so far. I am now not with Telekom anymore, but people there are still willing to contribute it under the OpenStack. Do you have any opinions on that? Is there interest in getting this under the OpenDev and if yes then which namespace (openstack or X)? ======= Thanks, Artem

4 5

[tacker] Gate broken, and a fix patch has been posted
by Ayumu Ueha (Fujitsu) 01 Mar '24

01 Mar '24

Hi Tacker team, As you may know, the following two tacker’s gate jobs are broken since Feb 28. * tacker-functional-devstack-multinode-sol * tacker-functional-devstack-multinode-sol-multi-tenant I have investigated the cause, and posted bug report [1] and fixed patch [2]. Please refer to [1] and [2] for the problem and fix details. To: Yasufumi and Toshiaki, I have already confirmed that the above job is successful. Could you kindly review the patch [2] and merge it if it is no problem. [1] https://bugs.launchpad.net/tacker/+bug/2055431 [2] https://review.opendev.org/c/openstack/tacker/+/910720 Regards, Ayumu

1 0

Patch to ansible module os_subnet
by George Shuklin 01 Mar '24

01 Mar '24

Hello. I wrote a patch for subnet module about a moth ago. Unfortunately, no one looked at it, even after few nags in IRC. Can someone review it, please? https://review.opendev.org/c/openstack/ansible-collections-openstack/+/9073…

1 0

[all][ptls][release] Action needed to move forward Unmaintained branch policy
by Jay Faulkner 01 Mar '24

01 Mar '24

Hi all, If you are a PTL of a project, a release liason, or a person generally interested in older OpenStack branches, please make sure you take a look at the topic here: https://review.opendev.org/q/topic:%22vwx-unmaintained%22 and vote appropriately on projects you care about. More information can be found in the commit message for the patches themselves. A lot of folks have done work behind the scenes to enable this transition; please help us by doing your part and getting these reviews done in a timely manner is one way we can show gratitude to the releases team and others who have worked to make this transition possible. Thanks, Jay Faulkner OpenStack TC Chair

2 1

[blazar] Proposing Mark Powers and Matt Crees as core reviewers
by Pierre Riteau 01 Mar '24

01 Mar '24

Hello, I would like to nominate two new core reviewers for the Blazar project: - Mark Powers from University of Chicago - Matt Crees from StackHPC Mark Powers has been operating Blazar for several years for the Chameleon project (https://www.chameleoncloud.org) and maintains a fork of Blazar with many changes for this environment. The most useful changes are gradually being contributed upstream. Matt Crees has contributed several useful features to Blazar in the past few releases and helps to maintain the code. The Blazar project will benefit from their expertise and I trust their input as reviewers. Best wishes, Pierre Riteau (priteau)

1 1