February 2024 - openstack-discuss

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

01 Mar '24

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

4 5

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

01 Mar '24

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

2 1

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

29 Feb '24

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

1 1

[all] Gate issues and memory pressure; can you help?
by Jay Faulkner 29 Feb '24

29 Feb '24

Hi all, As some of you are aware, keeping the OpenStack CI system operating is a massive amount of work, and it's a team effort. Along those lines, we continue to have issues with CI, and memory pressure is a common thread. Recently at a TC meeting[0] we discussed how the gate is using more ram -- now in the form of swap. One additional concern is that this memory usage increase may be reflective of what our users are experiencing -- bugs that we need to fix for the sake of our users. A specific target of concern is oslo.privsep[1], but generally a need for an audit of memory usages of OpenStack services would be of significant value to the community. If you're interested in taking on this work, please reach out here, on the mailing list, or in any relevant #openstack-* channel, such as #openstack-tc. In any event, don't wait for permission! Take action and see if you can make things better, even a little bit. Thanks, Jay Faulkner OpenStack TC Chair 0: https://meetings.opendev.org/meetings/tc/2024/tc.2024-02-20-18.00.log.html 1: https://opendev.org/openstack/oslo.privsep

1 0

[cinder] FFE request for [NetApp] LUN space allocation support in 2024.1
by Borra, Jayaanand 29 Feb '24

29 Feb '24

Hello All, I would like to request FFE in the 2024.1 Caracal cycle for the below patch https://review.opendev.org/c/openstack/cinder/+/893106 Reason for FFE: Addressing review comments Thank you! Jayaanand.

3 2

Openstack Networking queries
by KK CHN 29 Feb '24

29 Feb '24

List, My kolla-ansible OpenStack installation all-in-one on Virtual Machine( Ubuntu 22.04, ) This base VM has three vNICs 1. ens192 with ip 10.170.16.128 from my organization's LAN with internet connectivity 2. ens224 is configured manually with a 10.220.0.51 IP ( from a VLAN for internal testing without internet) 3. ens160 This interface is made up without any IPs ( I don't know why this has to be up without any IP address, but kolla-ansible all-in-one installation document specifies one interface like this required ) Can I do the kolla-ansible deployment with the above 2 vNICs only ( ens192 and ens 224 ?) But ens192 I cannot have without IP addresses as it is my organizational LAN. Other clients in the office use this Segment for daily work . I don't have control on 10.170.16.0/24 but only on10.170.16.128 ip Any serious issues there by using only ens192 and ens224 alone in this case ? ( I can use ens224 ( 10.220.0.0/24 segment as floating IPs as it is in my control as a VLAN) But How can I connect the internet and external world communication to this vLAN 10.220.0.0/24 from 10.170.16.128 IP which has the internet. (to use these vLAN IPs as floating point IPs ) my tenant network can be ( all VMs can be on 10.0.0.0/24) How to provide the internet to this vLAN 10.220.0.0/24 from the available internet connected IP ens192 (10.170.16.128 with internet) I have only control on this IP but not on 10.170.16.0/24 network as it is not under my control. Can I use the following config for bootstrapping and deploying kolla-ansible all-in-one *Correct me what I am missing or what wrong I am doing in this setup ??* (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:~$

2 1

*[glance] Request for Feature Freeze Exception*
by Abhishek Kekane 29 Feb '24

29 Feb '24

Hi Team, I would like to request FFE for "Using centralized database for cache operations" feature. Patches: https://review.opendev.org/q/topic:%22centralized-cache-db%22 Status: Base functionality is merged Pending: - Devstack patch for defaulting cache_driver to centralized_db - https://review.opendev.org/c/openstack/devstack/+/907110 - Tempest tests for caching images on remote node - https://review.opendev.org/c/openstack/tempest/+/901525 - Grenade patch to change cache-driver to centralized_db on upgrade - https://review.opendev.org/c/openstack/grenade/+/901678 - New tempest job to test centralized db - https://review.opendev.org/c/openstack/glance/+/901429 - New Grenade job to test upgrade scenario - https://review.opendev.org/c/openstack/glance/+/901649 - Make centralized_db driver default in glance - https://review.opendev.org/c/openstack/glance/+/907111 Why miss the deadline: Some useful restructuring during milestone 3 This feature is useful as we just need a single database which reduces the need of maintaining sqlite3 database and also can enhance caching operations by introducing new APIs in future. Kindly consider this feature for the current cycle and assist with reviews and suggestions. Thank you, Abhishek Kekane

3 2

[nova] dry-run migration api
by Pavlo Shchelokovskyy 29 Feb '24

29 Feb '24

Hi all, Recently I've been looking into various load optimizations tooling for OpenStack (like Watcher), and noticed a lacking feature that could make such tooling much more robust and useful. The optimization tooling usually collects some metric about compute hosts and instances that nova may be totally unaware of (e.g. power consumption of a compute node in Watts), and then tries to reshuffle the instances between hypervisors to optimize said metric in some sense. The problem is, the tool has no idea beforehand if nova will actually allow moving this given instance to this given hypervisor. I am talking about resource consumption, resource provider traits, image and aggregate metadata matching, numa placement, server group affinities etc. To know all this for sure, the optimization tool would have to duplicate most of the nova scheduler and good part of placement inside of itself - which is not feasible. This is why AFAIU in Watcher all available strategies mention that they expect "any VM to be migrateable to any hypervisor", which is far from many if not most real life deployments. What I suggest is adding a new API to nova to effectively have a 'migration dry run' - it should return the list of target hosts a given instance may be migrated to, accounting for all the knowledge nova has about the instance and the hypervisors. The list can be already sorted by nova weighers to signal the preferred choice from nova side. AFAIU such a new API would not require any drastic changes in Nova - the most of the code is already there, used during migrations, only that at the last step, instead of choosing the best compute and actually initiating the migration process, the result of filtering and weighing will be returned to the caller in some form. Would there be interest in such an API? If yes, I could start writing and proposing a spec. Best regards, -- Dr. Pavlo Shchelokovskyy Principal Software Engineer Mirantis Inc www.mirantis.com

3 2

Re: Enabling external connectivity to VMs
by Eugen Block 29 Feb '24

29 Feb '24

Please don't drop the list from your response. I'm not very familiar with kolla, but if you're able to ping the instance via floating IP it seems okayish. Maybe you need to set neutron_external_interface to ens192 instead? Someone with more kolla experience will probably correct me here, so don't rely on my response. Zitat von KK CHN <kkchn.in(a)gmail.com>: > Hi Eugen, > > I have followed the > https://docs.openstack.org/kolla-ansible/latest/reference/networking/neutro… > > But mistakenly I have configured ens160 as neurton_external_interface: > "ens160" as the docs says an interface without IP address needed so I > create a vNIC ens160 without IP and used this without knowing What I am > doing..!!!! > > The issue is tenant VMs don't get Internet. also tenant VMs cant ping > base VM(Ubuntu 22.04 IP 10.220.0.51, or 10.176.16.128 .. ) totally > confused. > > > Could you help me to understand what I am doing wrong here ? > Greetings > Krish. > > *For more info what I have done so far : * Please refer to > the following... > > In the Base VM, I created 3 vNICs. > > 1. ens192 with my Org's dhcp LAN IP 10.176.16.128 which has the internet. > 2. ens224 with 10.220.0.51 IP which is a VLAN IP of (10.220.0.0/24) which > is created for testing purposes internally by N/W guy. This doesn't have > the internet.. > > 3. ens160 up active without IP address. ( Wrongly I specified this as the > e neutron_external_interface in globals.yml) > > > > *I have deployed the openstack..Everything up and running .. * > I am able to create Routers, Network and subnets and able to create > instances(all VMs spawning with 10.0.0.0/24 IPs) > > I created the networks(external with subnet 10.220.0.0/24 with > start=10.220.0.30 to end=10.220.0.50) and internal Network(with subnet > named demo-net 10.0.0.0/24 for tenants) > > I am able to associate the VMs with 10.0.0.0/24 IPs to Floating IPs from > 10.220.0.0/24 > > and from my Base(host) VM(Ubuntu22.04 with ens224 10.220.0.51) I am able > to ping the 10.0.0.28 tenant VM IP through the associated floating IPs as > > $ ip netns ( On base (host) VM) dsplays the router > (kolla_ansible_venv3) ubuntu@ubuntu-VM:~$ ip netns > qrouter-ecc6fe39-a733-4f30-bf67-ac42407227f8 (id: 1) > > qdhcp-c29f26ac-3594-4c40-bf20-f2d5ba7d6eea (id: 0) > > > $(kolla_ansible_venv3) ubuntu@ubuntu-VM:~$ sudo ip netns exec > qrouter-ecc6fe39-a733-4f30-bf67-ac42407227f8 ping 10.0.0.28 ( the VM > tenant IP address) > PING 10.0.0.28 (10.0.0.28) 56(84) bytes of data. > 64 bytes from 10.0.0.28: icmp_seq=1 ttl=64 time=0.972 ms > > (kolla_ansible_venv3) ubuntu@ubuntu-VM:~$ sudo ip netns exec > qrouter-ecc6fe39-a733-4f30-bf67-ac42407227f8 ping 10.220.0.44 ( the > Floating IP associated to 10.0.0.28 VM) > PING 10.220.0.44 (10.220.0.44) 56(84) bytes of data. > 64 bytes from 10.220.0.44: icmp_seq=1 ttl=64 time=0.840 ms > 64 bytes from 10.220.0.44: icmp_seq=2 ttl=64 time=0.599 ms > > (kolla_ansible_venv3) ubuntu@ubuntu-VM:~$ sudo ip netns exec > qrouter-ecc6fe39-a733-4f30-bf67-ac42407227f8 ping 10.220.0.33 ( The router > IP through which connects floating ip 10.220.0.44 and then to tenant VM ip > 10.0.0.28 ) > > PING 10.220.0.33 (10.220.0.33) 56(84) bytes of data. > 64 bytes from 10.220.0.33: icmp_seq=1 ttl=64 time=0.038 ms > > *Hence it works somehow. * But ens224 10.220.0.51 doesn't have > internet on the base VM. But only ens192->10.170.16.128 IP has.. > > How can I provide the internet connectivity of ens192 to ens224 Is this > possible or Am I doing some dump here.? What is the other way / best way > to do this .. > I am beginning my journey with OpensStack but stuck here without much > progress.. > > > (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:~$ > > > The following screenshot shown the tenant VM console(tty) where I am able > to ping floating IP(10.220.0.44 and its router ip 10.220.0.33 ) but > neither 10.220.0.51 the base VM ens224 IP nor ens192 10.17.16.128 > > > [image: image.png] > > > > krish > > On Tue, Feb 27, 2024 at 11:09 PM Eugen Block <eblock(a)nde.ag> wrote: > >> Hi, >> >> Check out this page: >> >> >> https://docs.openstack.org/kolla-ansible/latest/reference/networking/neutro… >> >> You need some sort of external network to provide connectivity for >> instances. >> >> Zitat von KK CHN <kkchn.in(a)gmail.com>: >> >> > 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 ? >> >> >> >>

1 0

[oslo][release][requirement] FFE request for oslo.context
by Takashi Kajinami 29 Feb '24

29 Feb '24

Hello, I'd like to request an exception to merge a change[1] to oslo.context and create a new stable/2024.1 release. This change is required to fix the problem which is current blocking us from bumping oslo.messaging to the final 2024.2 release version (14.7.0)[2]. The change is small and has quite limited impact. I've tested the modification locally and confirmed it fixes the heat unit tests. [1] https://review.opendev.org/c/openstack/oslo.context/+/910153 [2] https://review.opendev.org/c/openstack/requirements/+/909906 -- Takashi Kajinami irc: tkajinam github: https://github.com/kajinamit launchpad: https://launchpad.net/~kajinamit

3 4