- openstack-discuss - lists.openstack.org

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

01 Mar '24

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

1 1

[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

[magnum] Dropping default Cluster API driver
by Mohammed Naser 29 Feb '24

29 Feb '24

Hi everyone, It seems that based on a recent post that I saw on the Twitter-sphere[1], it seems that the Magnum team has decided to move forward with setting a default driver for the Cluster API. I don't agree with this. Unfortunately, we don't have much recordings of our PTG conversations, and since the notes on the PTG are pretty light[2], I don't see any details of that. I don't see why we should be merging a native Cluster API driver and not allowing the operators and deployment tools decide which one they want to support. Personally, I think that the Helm driver should be built in a separate repository and then installed by the user as a Python package once they understand what are the backends and their options, as opposed to shipping one out of the box with far less features. We already have successful users which are using our implementation in production that have also posted blogs and shared their experience, we'd be doing them a disservice by now announcing a 'native' built-in driver. Can the decision be changed so that there is no built-in driver, and you must decide to install one yourself? Also, I would be really happy to hear feedback from users of the driver for their comments here. Thanks, Mohmamed [1]: https://www.stackhpc.com/magnum-clusterapi.html [2]: https://etherpad.opendev.org/p/r.5b94a5a9dbf4e3bf8202b5e57cb93770

19 34

[ptl][election][trove] PTL candidacy for 2024.2
by chunyang wu 28 Feb '24

28 Feb '24

Hello everyone: I would like to announce my candidacy for PTL of the Trove project for the 2024.2 cycle. For the Dalmatian cycle, i'd like to focus on the following: * review the coming patches * Add more tempest tests * Add CI tests for the latest datastore(mysql, mariadb, postgresql) version * improve docs thanks wu.chunyang

2 2