- openstack-discuss - lists.openstack.org

Reg Snapshot
by Rohit Sansiya 27 Feb '24

27 Feb '24

Hii all, I am trying to upload a volume to an image but it has uploading as a snapshot but I want to upload my snapshot to an image "type". how to do that help me asap through cmd or openstack dashboard please help Your message is ready to be sent with the following file or link attachments: Rohit Sansiya https://sites.google.com/view/rpgcloud/research-india Note: To protect against computer viruses, e-mail programs may prevent sending or receiving certain types of file attachments. Check your e-mail security settings to determine how attachments are handled.

2 1

[tc][elections] Candidacy for the TC
by gtema 27 Feb '24

27 Feb '24

Hi All, I'd like to announce my candidacy for the Technical Committee. I have never applied for a TC seat so far and decided to do it this time. My relations with OpenStack started not terribly long ago, on the other side 6 years are also not less in my eyes. During that time I became PTL for OpenStackSDK/CLI (and to some extend OpenStack Ansible Modules). I think many of you have noticed my strong push to improve the user experience of OpenStack users. For that I took the PTL role over all those mentioned projects which are focused primarily on the users. You may have noticed my push on introduction of the OpenAPI to the whole OpenStack with the intention to serve those who work with OpenStack. What I currently observe is that there are a lot of representatives and voices from maintainers and operators in TC, but since combining of the TC and User Committee focus end users voice slowly disappeared. That is why I decided to apply for Technical Committee to ensure this aspect is not forgotten. Some of you know me as a "maker" and not as a "talker", so this position is not going to be trivial for me, but I believe it is necessary to have engineers and architects in the politics otherwise laws are just serving wrong targets. My stand point is that policies should not hinder the progress, but instead we should make policies that serve ourselves to be efficient and successful. OpenStack is not existing to keep maintainers happy, but because someone (operators and users) needs it. So let us focus on that. Thank you for considering my candidacy, Regards, Artem (irc: gtema)

1 0

[ironic] Control Power using PoE?
by Kai Jellinghaus 27 Feb '24

27 Feb '24

Hello, I'm looking into using ironic to control a bunch of low-power compute. I'm wondering whether it'd be possible, or even the right approach, to control power states via the PoE switch. This would only allow completely cutting off power, and I'm not sure that's the right kind of control for ironic. I'd combine this with PXE/iPXE, but the way I understand ironic that shouldn't make a difference. Has anyone worked with PoE? Is that even a reasonable approach? Kind Regards, Kai Jellinghaus

1 0

[ptl][election][horizon] PTL candidacy for 2024.2
by Tatiana Ovchinnikova 26 Feb '24

26 Feb '24

Hi all, I would like to announce my candidacy for PTL of the Horizon project for the 2024.2 (Dalmatian) cycle. During the Caracal cycle we did a great job on integration tests improvement, feature implementation, bug fixing, and have completed migration from Django 3.2 to Django 4.2. For the Dalmatian cycle, I would like to focus on the following: * Continue working with feature gap, * Switch from current integration tests to new pytest-based selenium tests, * Switch to OpenSDK * Triage more bugs * Involve more contributors into the community. Thank you for your consideration. Tatiana Ovchinnikova (tmazur)

1 0

[ptl][election][neutron] PTL candidacy for 2024.2
by Brian Haley 26 Feb '24

26 Feb '24

Hello Openstack Community, I am writing to submit my candidacy for the Neutron PTL position during the 2024.2 cycle, continuing in my role from the 2024.1 cycle. A lot of my priorities as PTL are the same as the 2024.1 cycle: * Always make sure the stable branches are consumable downstream. With the introduction of unmaintained branches, the community has extended the lifecycle in a new direction. As a member of the downstream community that relies on these branches, I will continue to dedicate part of my time to reviewing backports and keeping them maintained. * Continue pursuing CI stability. * Keep working on ongoing specs. We did a good job of getting some of the larger specs done this cycle, but there are still a few in our review pipeline. I would set a goal to get these completed next cycle if they fail to make 2024.1: ** Active-active L3 Gateway with Multihoming (LP #2002687) ** Multiple back-end support for L3 routers in ML2/OVN (LP #2020823) * Reduce the bug backlog. Over the past cycle we were able to keep our bug backlog constant through the continued great work of a lot of contributors. Having a reduction, either through verification or bug fixes, would be one of my goals. * Making sure we are good stewards of gate resources. * Always welcome new contributors. Thanks for your support. -Brian Haley (haleyb, haleyb.dev(a)gmail.com)

1 0

[tc] Next Technical Committee meeting Feb 27
by Jay Faulkner 26 Feb '24

26 Feb '24

Hi all, The next TC meeting will be February 27 at 1800 UTC in #openstack-tc on OFTC. The proposed agenda is below. Agenda - Roll call - Follow up on tracked action items - Gate health check - Implementation of Unmaintained branch statuses - Testing runtime for 2024.2 release (gmann) - https://review.opendev.org/c/openstack/governance/+/908862 - Murano inactivity and Caracal release - Should https://review.opendev.org/c/openstack/governance/+/908859/ be landed with/without the release removal change? - 2024.1 TC Tracker - https://etherpad.opendev.org/p/tc-2024.1-tracker - Open Discussion and Reviews Thanks, Jay Faulkner OpenStack TC Chair

1 0

[kolla][octavia][ovs] networking issue with dhcp-agent namespace
by Satish Patel 26 Feb '24

26 Feb '24

Folks, All my deployment is running on OVN and things are working great with octavia and its special lb-mgmt-net working. Recently I am deploying a new cloud using the OVS network plugin and found dhcp-agent namespace not pinging because I have a similar IP address configured on the host interface. My LBaaS nic /etc/netplan/00-network.yml ... ... # OS1_LBAAS bond0.15: id: 15 link: bond0 dhcp4: false dhcp6: false mtu: 1500 addresses: [ 192.168.32.201/24 ] Controller node interface # ifconfig bond0.15 bond0.15: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1500 inet 192.168.32.201 netmask 255.255.255.0 broadcast 192.168.32.255 inet6 fe80::b489:8ff:fe61:2298 prefixlen 64 scopeid 0x20<link> ether b6:89:08:61:22:98 txqueuelen 1000 (Ethernet) RX packets 1074073 bytes 54067608 (54.0 MB) RX errors 0 dropped 0 overruns 0 frame 0 TX packets 1594 bytes 78172 (78.1 KB) TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0 octavia DHCP agent namespace (lb-mgmt-net) # ip netns exec qdhcp-1008bdd3-372a-44af-8fd3-00fb99b8e489 ip a 1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000 link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00 inet 127.0.0.1/8 scope host lo valid_lft forever preferred_lft forever inet6 ::1/128 scope host valid_lft forever preferred_lft forever 13: tape6186f5a-40: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UNKNOWN group default qlen 1000 link/ether fa:16:3e:c7:bf:2d brd ff:ff:ff:ff:ff:ff inet 192.168.32.10/24 brd 192.168.32.255 scope global tape6186f5a-40 valid_lft forever preferred_lft forever inet 169.254.169.254/32 brd 169.254.169.254 scope global tape6186f5a-40 valid_lft forever preferred_lft forever My global.yml ################### # Octavia options ################### enable_octavia: "yes" octavia_network_interface: "bond0.15" octavia_amp_flavor: name: "amphora" is_public: no vcpus: 2 ram: 2048 disk: 5 octavia_amp_network: name: lb-mgmt-net provider_network_type: vlan provider_segmentation_id: 15 provider_physical_network: physnet1 external: false shared: false subnet: name: lb-mgmt-subnet cidr: "192.168.32.0/24" allocation_pool_start: "192.168.32.10" allocation_pool_end: "192.168.32.100" no_gateway_ip: yes enable_dhcp: yes When I ping from namespace to controller machine LBaaS interface I am not able to ping # ip netns exec qdhcp-1008bdd3-372a-44af-8fd3-00fb99b8e489 ping 192.168.32.201 PING 192.168.32.201 (192.168.32.201) 56(84) bytes of data. ^C --- 192.168.32.201 ping statistics --- 3 packets transmitted, 0 received, 100% packet loss, time 2039ms Seems like standard linux arp/kernel issue. How does it work? In OVN there is no namespace so everything works fine but in OVS because of namespace it doesn't work.

1 0

[ptl][election][manila] PTL candidacy for 2024.2
by Carlos Silva 26 Feb '24

26 Feb '24

Hello, I would like to announce my candidacy for the role of Manila PTL during the 2024.2 cycle. I have been serving as PTL to this amazing community for 4 cycles, and I would like to continue serving as PTL. With the brilliant work of the Zorillas, we managed to make great progress on several community wide efforts, and deliver good quality features and fixes that will for sure enhance the usability and stability of the features. For the next cycle, I would like to focus on: * Working with the contributors to harden the security of our code base by ensuring we have proper testing on CI, and working on security related tech debt such as the rootwrap migration to privsep. * Engaging contributors to assist in the completion of the integration of Manila with OpenStack SDK and Barbican. * Working on the stability of our CI jobs and getting more test scenarios implemented in all Manila repositories. * Continue increasing the number of active reviewers through mentoring and creating more community engagement opportunities, such as: promoting hackatons, bug squashes and collaborative review sessions. Thank you for your consideration! Carlos da Silva IRC: carloss

1 0

[ptl][election][tacker] Yasufumi Ogawa candidancy for Tacker PTL
by Yasufumi Ogawa 26 Feb '24

26 Feb '24

Hi, I'd like to nominate myself for Tacker PTL for 2024.2 cycle. I've contributed to Tacker as a PTL since victoria release. In caracal cycle, we've improved Tacker for the 5G usecases including radio-access network and core network. We also contributed to O-RAN SC to provide Tacker as Service Management and Orchestration (SMO) which is a key feature of resource management in O-RAN architecture as a collaboration activity of OpenStack and O-RAN SC. In the next cycle, we'll continue to improve Tacker for container management required for vRAN usecases in addition to the features developed in caracal, such as advanced monitoring for large amount of vRAN apps, the latest container networking for performance or descriptor for container. Regards, Yasufumi (yasufum)

1 0

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

26 Feb '24

Reposting Sean's response with my answers > > > > > 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. > if we crate an openapi spec file i woudl like to use that for api validation > in the serveircies and i would like to ensure that the two never get out of > sync which is why i want to have the OpenAPI spec file be part of the > project. From your comments further down in the message I see where you are heading. From all the tooling and docs around OpenAPI you can see there are 2 different use cases of OpenAPI spec: 1. generation of the spec from current sources giving you freedom to use whichever underlying technology you want (Stephen's nova-spec change is also explicitly going this way) 2. using spec in the sources in the runtime a) query parameters + body validation b) request routing Those are actually very contradicting with each other. We need to align what exactly we are talking about and what is the scope of the change Your direction feels like (2.) about having devs to write a standalone spec and letting service consume it to implement the API in runtime (2b). This requires that either all services switch to single framework or we implement OpenStack-flavoured OpenAPI support into all of the currently used frameworks (or of course we again stuck with services doing absolutely different things) My proposal (1.) is to have spec generated supporting current zoo of frameworks used by services for request routing without devs needing to deal with OpenAPI directly. That requires us to ensure current jsonschemas and docstrings in the code are complete. Currently I see a tendency in other opensource projects that the bigger projects tend to go for 1. (with Kubernetes and GitHub being examples here) while smaller ones tend to choose 2. This can be explained by the additional complexity you get with maintaining manually the spec for huge services (my current compute OpenAPI spec is 46511 lines of code). Last, but not least, is the evolution of the OpenAPI standard itself forcing you to rewrite the spec time to time. This approach does not let you to consume openapi to route requests while it still allows you to have a test suite that would validate your service behaves like the spec describes. If we are on that level of discussion I really would like to see TC to get more actively into the discussion and we all agree and commit on a single way. > > > 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. > > yep we can host it in the project docs sight. > besided the rendered api_ref. > we can also commit it to the git repo is if we want to. > i feel like not maing it the output of a build process also has advantages. > > > 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. > > i was not proposing having any generations of the schema and instead > modfiying them by hand when we are modifying the api to ensure the two > correalate and capture the intent of the api change. Ok, but this is exactly what I am proposing - generate spec from source code of services My analysis of the source code of services showed that there are much more things and bugs exposed then devs know/expect/want. Maintaining OpenAPI per hand is something people have problem with and is very error-prone with respect to OpenStack API nuances. > > 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. > > well having external schema files is also a stong no-go form me but im > trying not to draw red lines and find a way forward. > > there are three thing i want to prevent. > i never want to have an external schema definition result in a client > rejecting a api call that should have been valid for a given cloud. > i don't want to maintain two diffent vallidation schmea for the apis (one in > the proeject and a second external) finally i dont want to have to do a > seperate release of a lib just to udpate the schema to be able to merge a > new api microversion or the reverses to require an update an external repo > after every api microversion. > > if we have the openapi sechma defs in nova we should not need to update the > openstack sdk when we have an api uidate and woudl only need to update > openstack client to use that new api. Agreed, as said - I am ok with not keeping the rendered spec part of different repository and wasn't under any means proposing to have a "lib" like repo with releases and so on. 3rd party "doc" repo can be used to link specs of different services together. One more time clarifying since I still feel we are not in sync about one technical aspect: jsonschemas of request bodies are and must be in the service repository, service router is exposing list of supported routes/methods with corresponding body jsonschemas. OpenAPI spec combines information about those exposed routes with their corresponding bodies and descriptions and applies standard on how to document microversions and actions (your router just shows that there is /"servers/{server_id}/action" url while you need to further define all the different actions and microversions). > > > 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 > > so in my expected workflow the openapi spec file would be a file in the repo > that is updated and review as part of the normal review process > > > - 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 > > i also think we should have a job to publish the spec file too but im not > sure we need to have any generation step outside of what we already do for > the api ref. > > - [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) > > this gets a little dicey in terms of licensing as we currently have a policy > in openstack that all patches must be authored by a human who has signed > the icla with the exception of the depency bump patches so we would have to > make sure that any such patches dont fall foul of the guidance that > maintainer should not merge patches form AI bots > > in general any generated code not submitted by a human is problematic form a > copyright point of view and icla point of veiw which is partly why i woudl > prefer the spec update to be in the orginal patch to the project not > autogenerated via a job. This is not AI generated code. It is similar to a tooling that RM is using to open bunch changes to the projects (only difference is who triggers it: a human or Zuul as a result of another job). Here it is about rendering pre-defined templates with new values and automatically proposing that as a change. We control both the templates and the values. I really do not understand a point of discussion like in example when a job completely under your control is doing periodic check of new available dependencies versions following your update strategy and proposing an update once all tests are green. But I definitely do not want to move the discussion into the different aspect. It is not about that. Anyway, I hope we can address this aspect by adapting our policies where required or stop being productive in a fear of laws. > > > - 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. > > i think if we were to add rust to the supproted langugaes for openstack > projects then creating an openstack-sdk-rs project would make sense however > rust is not an appvoed lanague for use in offial project go, javascript adn > python are so for this to proceed in the openstack namespace you would need > to formally request rust be added via > https://github.com/openstack/governance/blob/master/reference/new-language-r > equirements.rst > > and we woudl have to defien a new rust pti likely targeting the rust stable > release. https://github.com/openstack/governance/tree/master/reference/pti Ouch, I completely missed when "Go" was added into that list. Right, and thus mentioning it here. At least now I see you are also thinking about usage of Rust so at least there are now 2 person and this can be triggered. If Rust is not accepted then my project will not be official OpenStack delivery. The real question is who wins in that case. > > > > > 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) > > ideally from my point of view we would remove our custom jsonschma > validation and replace it with an openapi spec file then use something like > https://github.com/python-openapi/openapi-core?utm_source=openapi-tools&utm_ > medium=website&utm_campaign=data-validators to load the spec file form disk > and use it ot add server side request validation. i would really like the > nova api to be able to do somethign like > ``` > from openapi_core import OpenAPI > openapi = OpenAPI.from_file_path('openapi.json') > try: > result = openapi.unmarshal_request(request) > handel_request(request) > excpet ValidationError: > ... > ``` > > the current json schema validation we have is a custom intergartion and im > inclidned to consider it techdebt and look to replace it with a better > supported, purpose built project that we dont have to maintain long term... This is an absolutely valid approach (as also pointed above), but in my eyes would require much more work and will not work for all OpenStack services together without enforcement of OpenStack flavor of OpenAPI (same as you can't enforce all services to use same wsgi framework as of now or to follow the accepted API guidelines). As described my proposal is about going a less offensive way and allows us have "auto-documented" code what could be standardized across services while keeping the service's freedom to use whichever technology it prefers. That does not block any service from implementing service relying on the spec, but puts certain requirements on the form of the spec. N.B: what really surprises and disappoints me is general lack of any reaction in this thread as well as all previous attempts. Is it so unimportant ? Is it a fear of debate or just understanding that this is going to be another heated discussion without consensus? Is it something too big to do and thus let us not even start doing that? Is the community "died out" short in front of elections? Is it just waiting for somebody to break the "governance/policies/rules" wall we built between each other? Or am I the only one who thinks to see this issue? But that would not match to what others tell me directly. P.S. I re-read my message and assume some may feel offended by the tone. It is not really intended, so sorry in advance. Regards, Artem

1 0

[ptl][election] Sylvain Bauza candidacy for Nova 2024.1 PTL
by Sylvain Bauza 26 Feb '24

26 Feb '24

Hey Nova and Placement folks, Yet again, I'm asking you to put myself on the Nova and Placement PTL seat. I was awaiting to see whether new candidates were wanting to nominate themselves for that seat but now I am convinced to run again for this position. Challenges are still upfront. Our gate is still coughing every single day and despite the excellent work that a very few awesome people did on stabilizing and which helped improving the situation (kudos to those who will recognize themselves), we are still urging to fix the most common patterns. As a PTL, I'll ensure to keep the energy to chase those issues and identify them so as a team we can fight them. Another concern to me is the reviewing pace. While we're continuing to deliver solid reviews on feature proposals and patches, our team isn't much evolving and we need fresh blood. In order to be able to deliver things, we need to ensure that we properly recognize those who dedicate a portion of their daytime to help others by providing valuable feedback (and I stress on the fact that this feedback *has to* be valuable in order to by worthy). As a PTL, I'll continue to encourage people to express their thoughts and concerns into Gerrit comments so that we are able to count on. The last challenge I have to mention here is the release cadence. Now that we are about to deliver 2023.1 (Caracal), it will be time to remember ourselves that 2023.2 (Dalmatian) will be a skippable release for operators and we need to carefully think about the implications of such things. I'll just finish on a last word. While I really appreciated acting as a PTL for the last 5 cycles, I'd be more than happy if someone would like to step up next cycle (E) so I could offer some mentoring for a smooth transition. Thanks, -Sylvain

1 0

[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

PTG April 2024 Teams List
by Kendall Nelson 23 Feb '24

23 Feb '24

Hello Everyone! The April 2024 Project Teams List is official! Projects + Teams - OpenInfra Foundation Teams - - Diversity & Inclusion Working Group - OpenInfra Edge Computing Group - Kata Containers - OpenDev - StarlingX - OpenStack - - Services - - Blazar - Cinder - CloudKitty - Designate - Glance - Horizon - Ironic - Keystone - Kolla - Magnum - Manila - Neutron - Nova - Octavia - OpenStackAnsible - OpenStack-Helm - OpenStackSDK/CLI - Quality Assurance - Release Management - Tacker - Other OpenStack Teams - - OpenStack Security SIG - OpenStack Technical Committee - PublicCloud SIG - RBAC - VDI If your team was planning to meet and isn’t on this list, please contact ptg(a)openinfra.dev IMMEDIATELY. Soon, I will be contacting moderators to sign up for time via the PTGBot[1] once I have it configured for the teams that are signed up to attend the event. Otherwise, please don't forget to register[2] — it's FREE! As usual, feel free to let us know if you have any questions! Thanks! -Kendall (diablo_rojo) [1] PTGBot Docs: https://github.com/openstack/ptgbot#open-infrastructure-ptg-bot [2] PTG Registration: https://ptg2024.openinfra.dev/ <http://ptg2023.openinfra.dev/>

1 1

[election][ptl][sunbeam] non-candidacy for Sunbeam
by James Page 23 Feb '24

23 Feb '24

Hi All I'm not going to stand for PTL of the Sunbeam project for the upcoming cycle in order to allow others in the core dev team to stand for this position. Cheers James

1 0

[all][diversity] Final call for mentors and projects for the May 2024 Outreachy round
by Dmitry Tantsur 22 Feb '24

22 Feb '24

Hi folks, Sorry for the late heads-up. We don't currently have any projects submitted for OpenStack this cycle. If you have a project and would like to contribute to make the world a better place, please submit at https://www.outreachy.org/communities/cfp/openstack/ until tomorrow, Feb 23rd, 4pm UTC. Don't hesitate to reach out with any questions! Dmitry

1 0

[antelope][kolla-ansible][magnum]Multidomain problem
by Franck VEDEL 22 Feb '24

22 Feb '24

Hello I'm coming back to you with a new problem, which has already been submitted. I thought it worked with Antelope but maybe not. I have a kolla-ansible installation, antelope, on Ubuntu22.04, multinode. everything works as I want. If I leave only one domain (Default), I add heat and magnum. This works (with /etc/kolla/config/magnum.conf and cluster_user_trust = True). I add a second domain (users from an Active Directory). And there, adding magnum no longer works. When I do a "kolla-ansible reconfigure.....), I get the error: "action": "os_user_role", "changed": false OK, a search gives me this link: https://github.com/ansible/ansible/issues/57099 But I'm in the antelope version. Is this problem still relevant? How can we solve it? Thanks for your advices. Franck.

1 0