February 2024 - openstack-discuss

[all][elections][ptl][tc] Combined PTL/TC 2024.2 cycle Election Nominations Kickoff
by Ian Y. Choi 26 Feb '24

26 Feb '24

Nominations for OpenStack PTLs (Project Team Leads) and TC (Technical Committee) positions (5 positions) are now open and will remain open until Feb 28, 2024 23:45 UTC. All nominations must be submitted as a text file to the openstack/election repository as explained at https://governance.openstack.org/election/#how-to-submit-a-candidacy Please make sure to follow the candidacy file naming convention: candidates/2024.2/<Project_Name or "TC">/<email_address> (for example, "candidates/2024.2/TC/stacker(a)example.org"). The name of the file should match an email address for your current OpenStack Foundation Individual Membership. Take this opportunity to ensure that your OSF member profile contains current information: https://www.openstack.org/profile/ Any OpenStack Foundation Individual Member can propose their candidacy for an available, directly-elected seat on the Technical Committee. In order to be an eligible candidate for PTL you must be an OpenStack Foundation Individual Member. PTL candidates must also have contributed to the corresponding team during the 2023.2 to 2024.1 timeframe, Mar 03, 2023 00:00 UTC - Feb 28, 2024 00:00 UTC. Your Gerrit account must also have a verified email address matching the one used in your candidacy filename. Both PTL and TC elections will be held from Mar 06, 2024 23:45 UTC through to Mar 20, 2024 23:45 UTC. The electorate for the TC election are the OpenStack Foundation Individual Members who have a code contribution to one of the official teams over the 2023.2 to 2024.1 timeframe, Mar 03, 2023 00:00 UTC - Feb 28, 2024 00:00 UTC, as well as any Extra ACs who are acknowledged by the TC. The electorate for a PTL election are the OpenStack Foundation Individual Members who have a code contribution over the 2023.2 to 2024.1 timeframe, Mar 03, 2023 00:00 UTC - Feb 28, 2024 00:00 UTC, in a deliverable repository maintained by the team which the PTL would lead, as well as the Extra ACs who are acknowledged by the TC for that specific team. The list of project teams can be found at https://governance.openstack.org/tc/reference/projects/ and their individual team pages include lists of corresponding Extra ACs. Please find below the timeline: PTL + TC nomination starts @ Feb 14, 2024 23:45 UTC PTL + TC nomination ends @ Feb 28, 2024 23:45 UTC TC campaigning starts @ Feb 28, 2024 23:45 UTC TC campaigning ends @ Mar 06, 2024 23:45 UTC PTL + TC elections start @ Mar 06, 2024 23:45 UTC PTL + TC elections end @ Mar 20, 2024 23:45 UTC Shortly after election officials approve candidates, they will be listed on the https://governance.openstack.org/election/ page. The electorate is requested to confirm their email addresses in Gerrit prior to 2024-02-28 00:00:00+00:00, so that the emailed ballots are sent to the correct email address. This email address should match one which was provided in your foundation member profile as well. Gerrit account information and OSF member profiles can be updated at https://review.openstack.org/#/settings/contact and https://www.openstack.org/profile/ accordingly. If you have any questions please be sure to either ask them on the mailing list or to the elections officials: https://governance.openstack.org/election/#election-officials

1 1

Re: [TC][openapi] Request for new projects under the OpenStack hat
by gtema 26 Feb '24

26 Feb '24

Ups, used wrong button and replied to Sean only, reposting my replies here directly > Hey, > > thanks for feedback > > see comments inline > > > > === 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. > > > > i personally object to haveing a offical repo to define the open api > > scemas > > for offial projcet that scope of the relevent repo. > > > > i.e. i do not agree that we shoudl have openapi defintion for the nova api > > ourside of the nova repo or a repo that is not a deliverable of the > > comptue > > project. > > > > stephen has proposed a spec to add openapi support to nova directly > > https://review.opendev.org/c/openstack/nova-specs/+/909448 > > I was referring to that spec in the header of my email > > > what i really dont wnat to see is going forward an api change to nova > > woudl > > also requrie the oepnapi schema be updated by submiting a patch to a > > speratre repo. > > so im fine with haveing schemas in the nova repo but im not ok with having > > a https://opendev.org/openstack/openstack-openapi/ repo > > Please do not mix jsonschemas in services and the resulting OpenAPI spec > file. > > Anyway, I was thinking about such approach also. Issue, but not really > critical for me, is that having schemas in various repos will make it harder > for the user to actually grep them, unless we build a single page with > links to all specs. > > In addition to that with the spec generated by a different tool we are going > to have some workflow issue: schema is an artifact of a build and need to > be hosted somewhere permanently. You would be having problem in having an > API affecting change which during merge generates spec and this spec being > submitted into the repo as well. > Forcing devs to manually invoke the generator and include the spec into the > change is definitely a very strong no-go for me, this will be a disaster. > Pushing rendered specs to some artifacts server is necessary. > > In any case what is required is to have a sphinx-extension that allows us to > generate docs for the schema and this repo is primarily is exactly about > that (I have no issue renaming it to better indicate that fact). Just as a > matter of temporary demonstration it also hosts the rendered specs. > > > # My "ideal" workflow would look like that: > > - service developer creates change like above that changes the API > > - Zuul job generates OpenAPI spec for the service respecting the change and > publishes it together with job artifacts (just like docs right now) > > - Once a change is merged the OpenAPI spec artifact is published as a > deliverable (just like doc job publishes built docs). Maybe the api-ref job > can be modified to publish openapi spec and rendered HTML together > > - [from here absolutely speculatively] > > - another job kicks in and automatically proposes changes to projects that > consume this OpenAPI spec (like a change toward the SDK is automatically > opened that applies corresponding change) > > - dependent project developers review this automatic change and merge/modify > it as necessary > > > > === 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) > > > > i was actully playing with rust and pyo3 to try and generate rust data > > types form the jsonscheam defintion of novas oslo versioend objects > > https://github.com/SeanMooney/nova-oxide thats mainly to paly with rust > > and > > rust<>python interaction in partarlary. > > > > i was toying with the idea of writing a deamon that coudl comuncitate with > > nova comonets over the rpc bus effectivly a rust implemetiaon of a > > nova-comptue agent as way to learn rust. basically nova-comput ewould need > > effectivly a rewrite to remove our use of eventlet anyway so i was toying > > with the idea of if we are rewriting should we rewtien in something other > > then python. > > > > have you considerd using something like pyo3 to provide python binding > > around a rust inmpelmation of the sdk to support both lanageues form a > > singel codeabse. https://pyo3.rs/v0.20.3/ > > Yes, it is clearly possible and I am poking with idea of integrating > generated code into the openstacksdk (at least in some parts like auth > caching). > > I really think of having a new openstacksdk2 that is either also generated > from specs or is under the hood uses the rust sdk. > Changing the current OpenStackSDK would require huge breaking changes, so > this is not in the scope right now. > > > > 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? > > > > yep see above. > > mainly just decopleing the schmas form the implemation. > > if we keep the schemas with the python code in the same repo or in a lib > > repo provded by each service project > > I do not get the point here really. > > - Ideally every service is extending schemas already present in the code and > adds descriptions directly into the code. > - from schemas in the service code we are able to generate OpenAPI > - the OpenAPI spec can be used to render API docs of the service > - OpenAPI specs can be used to generate client facing (and possibly also > server bindings) tooling (sdk, cli, etc)

1 0

[neutron] Bug Deputy Report February 19 - 25
by Lucas Alvares Gomes 26 Feb '24

26 Feb '24

Hi, This is the Neutron bug report from February 19th to 25th. Only a few bugs this week. High: * https://bugs.launchpad.net/neutron/+bug/2054435 - "Testing errors when using new netaddr library" Unassigned Medium: * https://bugs.launchpad.net/neutron/+bug/2054324 - "Iptables rule wrong if created a rule with protocol 4" Assigned to: Brian Haley Needs further triage: * https://bugs.launchpad.net/neutron/+bug/2008238 - "SRIOV port binding_profile attributes for OVS hardware offload are stripped on instance deletion or port detachment" Unassigned Note re #2008238 <https://bugs.launchpad.net/neutron/+bug/2008238>, this bug is old and was originally assigned and fixed in Nova, reading the comments I see that Rodolfo has added Neutron to it with the following message: "Adding Neutron to this bug. A port extension could be needed to avoid writing in the port port_binding register when creating a port. That will avoid the Neutron policy restriction, that only allows to write on this field to service role." It seems like an enhancement on our side to avoid writing to the port's port_binding field directly. Perhaps this needs further triage or even a LP of its own. Cheers, Lucas

1 0

[elections][tc] Candidacy for the TC for 2024.2
by Sławek Kapłoński 26 Feb '24

26 Feb '24

Hi Stackers, I have been a member of the TC for the last 2 years and I would like to keep doing that for the next year. I have been an OpenStack contributor for many years now and have contributed to many different projects with primary focus on the OpenStack Neutron. As a member of the Technical Committee I am focusing on the day to day job to keep OpenStack projects in the healthy state and to make contributors' lives easier. I was helping to improve gate stability by e.g. monitoring rechecks made by contributors of the projects. I am also monitoring the overall state of the official OpenStack projects and helping less active ones to find new contributors and keep them running. I want to use my experience as a TC member and continue working in the TC in those areas for the next year. Thank you for considering my candidacy for the Technical Committee. -- Slawek Kaplonski (slaweq) Principal Software Engineer Red Hat

1 0

[openstack][skyline] Some works with skyline
by Nguyễn Hữu Khôi 26 Feb '24

26 Feb '24

Hello guys. I am working on Skyline. I can integrate my monitor tab on it. I will try to do something about it. If it works properly, I can contribute. It is a very nice project. I hope it will grow and grow in the future. Thanks Skyline Team. [image: image.png] Nguyen Huu Khoi

3 7

OpenStack on Production Servers : Few Queries
by KK CHN 24 Feb '24

24 Feb '24

List, I am going ahead to adopt OpensStack for our Live deployment sites which all are running previously on proprietary HCI solutions. *Few queries.* 1. Which base Operating System need to be selected for production? ( prefer OpenSource community Operating Systems.) Is Debian a good choice? If so, which version ? Or any other suggestions? 2. What backend / SDS needs to be configured for a crash resistant FaultTolerant cluster. In case of a node / Disks failure which can withstand the workload and most preferably avoid data loss in the worst case scenario. 3. Heard about Ceph. How its a best choice for a 24x7 mission critical cluster? kindly advise. If so, what configuration architecture needs to be considered ? 3. My luxury is only at an On Prem Server Cluster comprising a minimum 3 to max 4 Nodes. ( possible DELL 650 or 750 series OR HPE servers ) . 4. As my cluster resources are limited to 3 to 4 server nodes / site ( 2 X32C 64 Threads, Intel Xeon Gold processors, with min 512 GB Ram , 4 x3.94TB SSD or 8 x1.92TB in each node) Is it reliable/advisable to set Controllers, Compute and Storage all together in these three or four nodes? Which is the best possible deployment options I can have with these 3/4 nodes. Kindly shed some light . 5. Any other points need to be considered while this must be a reliable infrastructure for running a mission critical 24x7 operation. 6. Which mode of installation I can choose, the Kolla-ansible multinode is advisable for a production deployment ? ( I am familiar with the kolla-ansible all-in-one installation ) OR ther a better deployment method for production sites ? ) Kindly shed some light and your valuable suggestions . Any hints most welcome. Thank you, Krish

2 1

[kolla][magnum] Creating Magnum trustee user role
by Satish Patel 24 Feb '24

24 Feb '24

Folks, I am deploying magnum using openstack release 2023.1 but getting this error. But I have a similar deployment running in another datacenter which didn't give any error. What could be the problem? TASK [magnum : Creating Magnum trustee user] **************************************************************************************** ok: [os-eng-ctrl-01] TASK [magnum : Creating Magnum trustee user role] *********************************************************************************** fatal: [os-eng-ctrl-01]: FAILED! => {"action": "os_user_role", "changed": false, "extra_data": {"data": null, "details": "None", "response": "None"}, "msg": "Must specify either a user or a group"}

4 6

[release] Release countdown for week R-5
by Thierry Carrez 23 Feb '24

23 Feb '24

General Information ------------------- This coming week is the deadline for client libraries: their last feature release needs to happen before "Client library freeze" on February 29th, 2024. Only bugfix releases will be allowed beyond this point. When requesting those library releases, you can also include the stable/2024.1 branching request with the review. As an example, see the "branches" section here: https://opendev.org/openstack/releases/src/branch/master/deliverables/pike/… February 29th, 2024 is also the deadline for feature work in all OpenStack deliverables following the cycle-with-rc model. To help those projects produce a first release candidate in time, only bugfixes should be allowed in the master branch beyond this point. Any feature work past that deadline has to be raised as a Feature Freeze Exception (FFE) and approved by the team PTL. Finally, feature freeze is also a good time for submitting a first version of your cycle-highlights. Cycle highlights are the raw data that helps shape what is communicated in press releases and other release activity at the end of the cycle, avoiding direct contacts from marketing folks. See https://docs.openstack.org/project-team-guide/release-management.html#cycle… for more details. Upcoming Deadlines & Dates -------------------------- Caracal-3 milestone (feature freeze): February 29th, 2024 (R-5 week) Cycle Highlights Due: March 7th, 2024 (R-4 week) RC1 deadline: March 14, 2024 (R-3 week) Final RC deadline: March 28, 2024 (R-1 week) 2024.1 Caracal final release: April 3rd, 2024 Dalmatian PTG: April 8-12, 2024 -- Thierry Carrez (ttx)

1 0

[openstack-ansible][live migration/migration of Paused VM] Need to migrate Paused VM on different host.
by Danish Khan 23 Feb '24

23 Feb '24

Hello Team, Is it possible to live migrate or migrate VM which is in paused state? I have few VMs which are in paused state which I need to migrate to a different host. Regards, Danish Khan

2 1

[neutron][ovs] br-tun bridge setup
by Jaime Ibar 23 Feb '24

23 Feb '24

Hi all, I'm setting up neutron and ovs and I can't make br-tun work and pick up the ip address configured in openvswitch_agent.ini file. If I tcpdump br-tun tcpdump -l -n -i br-tun 'port 4789' I don't see any traffic getting through however(it goes through the physical interface) if I spin up a vm, it reaches the internet, I can ping it from another machine after allocating a floating ip but can't ssh into it. Can anyone please share the /etc/network/interfaces file configuration for br-tun? Should the br-tun ip address be configured on the bridge or in the physical interface the bridge is attached to? Should the vxlan traffic go through br-tun bridge? Thanks Jaime -- salu2 Jaime

3 5