- openstack-discuss - lists.openstack.org

[ptl][election][kuryr] PTL non-candidacy for 2024.2
by Roman Dobosz 28 Feb '24

28 Feb '24

Hello, I'm not going to run for PTL of Kuryr for Dalmation. I encourage Kuryr contributors to run for PTL and will offer any assistance needed for whoever is elected. Thanks, Roman Dobosz (gryf)

1 0

[election][tc] Candidacy for the TC
by James Page 28 Feb '24

28 Feb '24

Hi All, I'd like to announce my candidacy for the Technical Committee. For those of you who do not know me, I've been involved with OpenStack from the very early days of the project. I've attended many OpenStack summits and Project Teams Gatherings over the years and have been privileged to help the project grow from its small beginnings to the established cloud platform that it has now become. I was the main driver behind migration of the OpenStack Charms to its current home as an official OpenStack project which I then led for many cycles as PTL and I remain an active core developer on this project. I'm the current PTL of Sunbeam which was accepted into OpenStack last year as a new incubating project, providing a reboot of the charmed approach to deploying OpenStack utilising the many new projects that have appeared since we started the OpenStack Charms project back in 2011. I also work as part of the team responsible for the packaging and distribution of OpenStack as part of Ubuntu. I have been a member of the TC for the last year providing a voice from a deployment tooling and distribution perspective. I would like the opportunity to continue in this role providing what I believe is a valuable perspective to the technical governance of the OpenStack project. In particular I think we need to address some of the challenges around the general health of wider ecosystem dependencies of OpenStack to ensure that we move forward onto a stable base benefiting operators, distributors and developers. Thank you for taking the time to consider my candidacy for this role. Regards James Page (irc:jamespage)

1 0

[puppet][murano] Retiring puppet-murano
by Takashi Kajinami 28 Feb '24

28 Feb '24

Hello, As you may know, TC decided to exclude Murano from 2024.1 release because of its health status[1]. Based on this fact, and also another fact that puppet-murano has had no real development activities for long, I'd propose retiring puppet-murano now. It may be too late to make release deliverable decision. However our puppet modules are tightly coupled with openstack release cycles and we can't assure compatibility between our modules and inactive components, which are no longer aligned with the consistent release cycle. Please let me know if you have any concerns. Thank you, Takashi [1] https://lists.openstack.org/archives/list/openstack-discuss@lists.openstack… -- Takashi Kajinami irc: tkajinam github: https://github.com/kajinamit launchpad: https://launchpad.net/~kajinamit

1 0

[ptl][election][sunbeam] PTL candidacy for 2024.2
by Hemanth N 28 Feb '24

28 Feb '24

Hello OpenStack Community, I am nominating myself for the Sunbeam PTL position during the 2024.2 cycle. I am a core team member of the Sunbeam project from the incubation stage and contributed to most of the charms that are part of the sunbeam project. In the last cycle we focussed on moving the 20+ charm repo's to a mono repo which helped reduce the codebase and easy maintenance of all the sunbeam charms. In the 2024.2 cycle, my priorities will be * Adding new features or charms and filling gaps to enable charms to be production ready * Stabilise the existing charms or libraries * Bug smashing * CI stability Thank you for your support. Best Regards, Hemanth Nakkina (hemanth, hemanth.nakkina(a)canonical.com)

1 0

Tim Burke candidacy for Swift PTL
by Tim Burke 28 Feb '24

28 Feb '24

I'm pleased to announce my candidacy for Swift PTL for the Dalmation cycle. As usual, we have a great many projects currently in flight: - Supporting Python 3.12 - Adding more fine-grained metrics, while keeping it configurable to not break existing metrics pipelines nor overwhelm them - Improving S3 compatibility, enabling a broader community of tools to work out of the box - More operator tooling for expiring objects - Better process management for WSGI servers - Backend ratelimiting to improve per-node load shedding I'm excited to see how each of these will move forward over the next cycle. Tim Burke

2 1

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

28 Feb '24

A quick reminder that we are in the last hours for declaring PTL and TC candidacies. Nominations are open until Feb 28, 2024 23:45 UTC. If you want to stand for election, don't delay, follow the instructions at[1] to make sure the community knows your intentions. Make sure your nomination has been submitted to the openstack/election repository and approved by election officials. All members of the community are encouraged to confirm their email address and opt in to the CIVS election as described at: https://governance.openstack.org/election/#electorate Election statistics[2]: Nominations started @ 2024-02-14 23:45:00 UTC Nominations end @ 2024-02-28 23:45:00 UTC Nominations duration : 14 days, 0:00:00 Nominations remaining : 23:49:45 Nominations progress : 92.91% --------------------------------------------------- Projects[1] : 47 Projects with candidates : 30 ( 63.83%) Projects with election : 0 ( 0.00%) --------------------------------------------------- Need election : 0 () Need appointment : 17 (Barbican Cloudkitty Ec2_Api Freezer Glance Keystone Kuryr Magnum Murano OpenStackAnsible OpenStack_Charms Sahara Senlin Skyline Solum Trove Watcher) --------------------------------------------------- TC Candidates : 7 (5 Required) =================================================== Stats gathered @ 2024-02-27 23:55:15 UTC This means that with approximately 2 days left, 17 projects will be deemed leaderless. In this case the TC will oversee PTL selection as described by [3]. Thank you, [1] https://governance.openstack.org/election/#how-to-submit-a-candidacy [2] Any open reviews at https://review.opendev.org/q/project:openstack/election+is:open+file:candid… have not been factored into these stats. [3] https://governance.openstack.org/resolutions/20141128-elections-process-for…

1 0

[ptl][election][cinder] PTL candidacy for 2024.2
by Jon Bernard 28 Feb '24

28 Feb '24

Hi All, I would like to announce my candidacy for PTL of the Cinder project for the 2024.2 cycle. I think Rajat has done an excellent job serving the project and I would like to carry existing efforts forward while continuing to focus maintaining a healthy and productive community around the Cinder project. I've been contributing to the Cinder project in varying capacity for close to 10 years. I've worked on migration and replication at the driver layer, mentored new contributors from the outreachy project, and provided bug fixes and reviews wherever possible. I'm a core reviewer and also a stable core. I have served as the release liaison for the last 2 cycles and run a weekly bug squashing meeting to help maintain our launchpad backog. We continue to face review bandwidth pressure. Emphasis should be placed on encouraging contributors to do code reviews and to recognize the efforts of those currently participating. There are several potential core reviewers and I feel that empowering the community is one way to increase engagement and the quality of our releases. 3rd party CI continues to be crucial resource for evaluating driver-specific changes. Maintaining good 3rd party CI for the drivers supported in Cinder by providing clear documentation and requirements will be a focus. Additionally, we have room for improvement in our backup and restore use case. My goal is to improve the entire backup/restore situation so that it can be leveraged by users in production environments. Our customers are using 3rd party backup products to backup workloads and volumes and I think this is one are where improvements here can directly benefit users. In summary, I would like to continue the efforts made by Rajat and continue to focus the areas most in need of attention for the 2024.2 cycle. I will do my best to make a positive contribution to both the technical and community aspects of Cinder during my time as PTL. Thank you for your consideration. -- Jon Bernard (jbernard)

1 0

Enabling external connectivity to VMs
by KK CHN 28 Feb '24

28 Feb '24

List, I am a bit confused with the OpenStack Networking configuration for Created virtual machines on a (Kolla-ansible all-in-one on an Ubuntu 22.04 VM ) openstack installation. I am able to create virtual machines through the dashboard as well as CLI. I have used the default network/cirros images created from init-runonce script. But Real time, how can I configure these new VMs to communicate with Base VM or external world by ping, ssh or make internet connection etc. Base VM is Ubuntu22.04 - with IPs ens192=>10.170.16.128(with Internet), second interface => ens224 => 10.220.0.51 and ens160 up and running without IP address for neutron_external_interface: All the VMs which I created getting IP addresses in series (10.0.0.X). But How to allocate Internet and make external world communication to and from these VMs ? Any hints/directions towards this much appreciated. Greetings, Krish If required more inputs here follows the additional information. (kolla_ansible_venv3) ubuntu@ubuntu-VM:~$ grep ^[^#] /etc/kolla/globals.yml --- workaround_ansible_issue_8743: yes config_strategy: "COPY_ALWAYS" kolla_base_distro: "ubuntu" openstack_release: "2023.1" kolla_internal_vip_address: "10.220.0.24" kolla_external_vip_address: "{{ kolla_internal_vip_address }}" kolla_container_engine: docker network_interface: "ens224" neutron_external_interface: "ens160" neutron_plugin_agent: "openvswitch" nova_compute_virt_type: "qemu" (kolla_ansible_venv3) ubuntu@ubuntu-VM:~$ Additional inputs: There are 3 virtual interfaces on the base Ubuntu22.04 Virtual Machine. ens192->10.170.16.128 with internet, ens224->10.220.0.51 , ens160 up without IP 1. First Interface contain IP address from My organizations DHCP lease from LAN(10.16.16.0) Which has Internet connectivity. ens192: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP group default qlen 1000 link/ether 00:0c:29:33:18:3c brd ff:ff:ff:ff:ff:ff altname enp11s0 inet 10.170.16.128/23 brd 10.170.17.255 scope global dynamic noprefixroute ens192 valid_lft 786963sec preferred_lft 786963sec inet6 fe80::cd1a:bc6c:b129:f91f/64 scope link noprefixroute valid_lft forever preferred_lft forever3 2. Interface I have 10.220.0.51 ens224: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP group default qlen 1000 link/ether 00:0c:29:33:18:46 brd ff:ff:ff:ff:ff:ff altname enp19s0 inet 10.220.0.51/24 brd 10.220.0.255 scope global noprefixroute ens224 valid_lft forever preferred_lft forever inet 10.220.0.24/32 scope global ens224 valid_lft forever preferred_lft forever inet6 fe80::a8b6:f094:c47:8282/64 scope link noprefixroute valid_lft forever preferred_lft forever 3. ens160 without any IP address which is up and running configured for Kolla neutron_external_interface: "ens160" ens160: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq master ovs-system state UP group default qlen 1000 link/ether 00:0c:29:33:18:32 brd ff:ff:ff:ff:ff:ff altname enp3s0 1. What networks need to be created additionally ? 2. Bridges and bonds required here or not ? 3. To enable these New VMs to talk to external world( ssh, ping, internet connection to all these VMs ) what all the steps need to be performed or I left out ?

2 1

Re: Use Openstack SDK for Swift
by gtema 28 Feb '24

28 Feb '24

> I didn't see a response to this email so I am re-sending. That's interesting because I responded. My Email client decided by default to respond to a single person dropping discuss, but response to you went out. Anyway, reposting my answer On Thursday, 22 February 2024 12:11:31 CET you wrote: > Hey > > this is a tricky thing explained by a single auth concept: in OpenStack when > you connect to the cloud as a regular user you request certain scope which > normally grants you access to the single domain or the project. Moreover > with this authorization you get list of endpoints you can communicate with > and for Swift this is a project bound endpoint that look somehow like > https:// swift.example.com/v1/AUTH_<project_id>. But the "AUTH_" part may > be actually different since it is part of the swift config. If you are an > admin the situation is a bit different > > In summary that means that you want to do something in the way the API was > not designed for. > > Solutions: > > generally first question you must address is the authorization: is your user > able to access containers of different projects or not. If not you have no > chance and you need to establish new connection with another credentials > When the answer is "yes" you have some options: > > - switch your authorization using > https://opendev.org/openstack/openstacksdk/ > src/branch/master/openstack/cloud/openstackcloud.py#L123. That gives you > new session for a different project that you can use in scope of a certain > project > > - use you single session for pure API calls. This has a disadvantage that > you have raw API communication and need to do lot of tricky things yourself > ``` > conn.get("../AUTH_<another_project_id>/") > ``` > > Unfortunately there is nothing else what could help you, but even with > alternative API wrappers you have the same issue. > > Hope this helps, > Artem > > On Tuesday, 20 February 2024 21:59:19 CET Albert Braden wrote: > > I'm writing a script that will use admin credentials to check user > > projects > > for containers. I'm already doing something similar for non-swift > > accounts, > > doing things like: > > > > cloud.network.networks(project_id=projectid): > > > > I read here about the Object SDK: > > > > https://docs.openstack.org/openstacksdk/latest/user/guides/object_store.ht > > ml > > > > And I tried this: > > > > cloud.object_store.containers(project_id=projectid): > > > > But I get an error: > > > > Invalid query params: project_id > > > > I read the Object SDK document here and it doesn't seem to say anything > > about how to specify a project: > > > > https://docs.openstack.org/openstacksdk/latest/user/proxies/object_store.h > > tm l > > > > But when I read the Swift API document, I see that I can use > > "/v1/{account}/{container}", so I'm guessing that there must be a way to > > do > > it via the SDK. > > > > https://docs.openstack.org/api-ref/object-store/#show-container-details-an > > d-> list-objects > > > > Is it possible to specify the project in an Object SDK call, or do I need > > to use the old python API for this?

2 1

[cinder] This week's meeting will be in video+IRC
by Rajat Dhasmana 28 Feb '24

28 Feb '24

Hello Argonauts, As we keep last meeting of the month in video + IRC mode, this week's meeting (tomorrow) will be held in video + IRC mode with the following details: Date: 28th February, 2024 Time: 1400 UTC Meeting link: https://meet.google.com/xqc-ekpa-dao IRC Channel: #openstack-meeting-alt Make sure you're connected to both the gmeet meeting and IRC. Thanks Rajat Dhasmana

1 0

[Kolla][Ironic] Ironic inspector ignore BareMetal node mac address
by Jayesh5.Chaudhari＠ril.com 28 Feb '24

28 Feb '24

Hi All, I have implemented ironic in my kolla ansible yoga cloud. When I am adding new BareMetal node, it's getting added successfully. But the ironic inspector put the ignore label in the data directory in front of its mac address. I tried to remove it manually, but inspector immediately reverted it. Please help me, how I can proceed from here? Thanks, Jayesh "Confidentiality Warning: This message and any attachments are intended only for the use of the intended recipient(s). are confidential and may be privileged. If you are not the intended recipient. you are hereby notified that any review. re-transmission. conversion to hard copy. copying. circulation or other use of this message and any attachments is strictly prohibited. If you are not the intended recipient. please notify the sender immediately by return email. and delete this message and any attachments from your system. Virus Warning: Although the company has taken reasonable precautions to ensure no viruses are present in this email. The company cannot accept responsibility for any loss or damage arising from the use of this email or attachment."

2 1

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 27 Feb '24

27 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 27 Feb '24

27 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 27 Feb '24

27 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 27 Feb '24

27 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 27 Feb '24

27 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 27 Feb '24

27 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 27 Feb '24

27 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