- openstack-discuss - lists.openstack.org

[Horizon][Skyline][API] Recommendation for a Web Application Firewall in front of Services
by Kaster, Jörn 30 Apr '24

30 Apr '24

Hello together, are there any recommendations or best practices how to expose the openstack API and/or WebUI's over a WAF (web application firewall) to the internet? We think we would use VMware NSX ALB [1] for this, but with the current broadcom trouble in the VMware sphere, we are uncertain for the future with this product. Are there any alternative software tools to reach the waf functionality to secure the api and http path's to openstack? regards Jörn [1]https://docs.vmware.com/en/VMware-NSX-Advanced-Load-Balancer/index.html [https://docs-prod.vmware.com/en/VMware-NSX-Advanced-Load-Balancer/images/GU…]<https://docs.vmware.com/en/VMware-NSX-Advanced-Load-Balancer/index.html> VMware NSX Advanced Load Balancer Documentation<https://docs.vmware.com/en/VMware-NSX-Advanced-Load-Balancer/index.html> Welcome to the VMware NSX Advanced Load Balancer (formerly known as Avi Networks). The NSX Advanced Load Balancer makes it easy to apply load balancing, web application firewall, and container ingress to any application in any datacenter and cloud. docs.vmware.com

1 0

[neutron] neutron-dynamic-routing advertising IPv4 AND IPv6 routes for true MP-BGP OR running multiple BGP speakers per agent (host)?
by Christian Rohmann 30 Apr '24

30 Apr '24

Hello OpenStack-Discuss, when setting up Neutron Dynamic Routing [1] to advertise IPV4 floating IPs and also IPv6 tenant networks I ran into some questions / issues. I was just about to ask about them here on the ML, when I found the older thread [2] discussing the advertising of IPv6 routes (e.g. from tenant networks). There Sean mentioned [4] that even with MP-BGP support [3] it's required to have two BGP speakers. While [3] means IPv4 or IPv6 can be used to establish the BGP session itself to then advertise routes for either address family, it's not possible to advertise IPv4 AND IPv6 routes via the same session. To cut to the chase of this threat .... It's not uncommon to simply use individual (non Multi-Protocol) BGP sessions to exchange routes for IPv4 and IPv6 individually and to me this poses no issue to me. The problem with Neutron is though, that the os_ken dragent driver only supports one BGP speaker [5] per agent. This leads to only one of the BGP speakers (IPv4 or IPv6) running per individual (control plane, networking) host. Or am I not seeing something or am misreading the capabilities of the components involved? If not, I see two options for improvement here: 1) Enabling a BGP speaker to have more than one address family (dragent driver already has MP-BGP support via [3]), so the query fetching the routes [6] simply returns them both. 2) Somehow get more than one BGP speaker per dragent working by ... a) ... extending the driver to host more than one BGP speaker b) ... extending dragent to have more than one driver instance Would love to hear how others have set up their dynamic routing and what your ideas are! Regards Christian [1] https://github.com/openstack/neutron-dynamic-routing [2] https://lists.openstack.org/archives/list/openstack-discuss@lists.openstack… [3] https://review.opendev.org/c/openstack/neutron-dynamic-routing/+/608302 [4] https://lists.openstack.org/archives/list/openstack-discuss@lists.openstack… [5] https://github.com/openstack/neutron-dynamic-routing/blob/ffaaf5a25d846fead… [6] https://github.com/openstack/neutron-dynamic-routing/blob/ffaaf5a25d846fead…

3 4

[tc][all] OpenStack Technical Committee weekly summary and meeting agenda
by Goutham Pacha Ravi 29 Apr '24

29 Apr '24

Hello Stackers, We're slowly approaching Milestone-1 of the 2024.2 (Dalmatian) release cycle [1]. As you observe, there is a buzz of activity across all OpenStack repositories as we've just gotten out of our design and planning event. I hope you've been enjoying the PTG summaries that have been posted thus far; I would especially recommend reading through the summary JayF put up for the Technical Committee meetings [2]. Allow me to take you through the latest news from the Technical Committee: === Weekly Meeting === Last week's TC meeting was held on IRC on Apr 23rd, 2024. The meeting was logged to eavesdrop [3]. Our main topic of discussion was about the fate of unmaintained branches, and the discussion was timely given that Elod Iles from the OpenStack Release Management SIG brought a discussion to this list about transitioning the "stable/zed" branch of all release-cycle deliverables to "unmaintained/zed" [5]. This process is underway [6]. Concerns were expressed that the unmaintained process may be easy for teams to opt in, and the burden on the "unmaintained-core" team is growing with each branch. Project Teams are expected to actively assist in transitioning branches to end-of-life. Since this isn't happening, and since the TC has noted that a number of projects have CI (Zuul) configuration errors on these "unmaintained" branches, it was proposed that we be aggressive about proposing end-of-life for unmaintained branches. It was also argued that our release model is going too fast for real-world deployments to catch up, and transitioning a lot of branches simultaneously to EOL may impact many consumers. In the interest of time during the meeting, we decided not to interfere with the transition of stable/zed to "unmaintained/zed". We encourage project leaders to: - Get their CI configuration in order for any unmaintained branches - If there is no interest/time to maintain any unmaintained branch, please actively pursue the branch's EOL process [7] In the rest of the meeting, we went through open governance proposals. We have been distracted by the PTG and Action Items across OpenStack, so some of these proposals are lacking review attention. We'll be focusing on getting these adequate review attention in the coming week/s. The next TC meeting is today, Apr 30th, 2024, at 1800 UTC on OFTC's #openstack-tc channel [4]. The agenda feels light, but we'll try to address a number of TC trackers at this meeting. This meeting is enhanced by the community's participation. We'd especially invite project leaders (PTLs, DPLs, Core maintainers) to participate and propose topics. === Goal Proposals === I'd like to request a community review of the following OpenStack community goals and updates: - Migrate eventlet usages to asyncio (https://review.opendev.org/c/openstack/governance/+/902585) - Goal: Remove eventlet requirements from shared libraries (https://review.opendev.org/c/openstack/governance/+/916546) - Add timeline to remove enforce_scope in RBAC goal (https://review.opendev.org/c/openstack/governance/+/915179) === Governance Proposals === The following governance proposals are close to being merged: - Add option to move leaderless project to Inactive status (https://review.opendev.org/c/openstack/governance/+/914726) - Appoint Wenxiang Wu as PTL of Skyline | (https://review.opendev.org/c/openstack/governance/+/915108) - Transition Freezer project to DPL | (https://review.opendev.org/c/openstack/governance/+/914911) The following governance proposals are actively being discussed: - Add DPL model & liaison reset policy (https://review.opendev.org/c/openstack/governance/+/916833) - Update to include docs and miscellaneous repos for AC status (https://review.opendev.org/c/openstack/governance/+/915021) - Clarify the timeline for a project to move to Inactive state (https://review.opendev.org/c/openstack/governance/+/908880) The following governance proposals need some review attention: - Move openstack/kuryr and openstack/kuryr-libnetwork to Zun (https://review.opendev.org/c/openstack/governance/+/917517) - 2023 User Survey TC Question Analysis (https://review.opendev.org/c/openstack/governance/+/900516) And finally, please consider volunteering as an Election official for the next OpenStack elections! [8] Thank you very much for reading! On behalf of the OpenStack TC, Goutham Pacha Ravi (gouthamr) OpenStack TC Chair [1] https://releases.openstack.org/dalmatian/schedule.html [2] https://lists.openstack.org/archives/list/openstack-discuss@lists.openstack… [3] https://meetings.opendev.org/meetings/tc/2024/tc.2024-04-23-18.00.log.html [4] https://wiki.openstack.org/wiki/Meetings/TechnicalCommittee#Next_Meeting [5] https://lists.openstack.org/archives/list/openstack-discuss@lists.openstack… [6] https://review.opendev.org/q/topic:zed-unmaintained [7] https://governance.openstack.org/tc/resolutions/20230724-unmaintained-branc… [8] https://lists.openstack.org/archives/list/openstack-discuss@lists.openstack…

1 0

[all][oslo] Removing Python 3.8 support
by Takashi Kajinami 29 Apr '24

29 Apr '24

Hello, I'm sending this to remind you of the fact that Python 3.8 support will no longer be part of the tested python versions for 2024.2 . Based on the plan, I'll drop Python 3.8 support from all oslo libraries and update the minimum python version from 3.8 to 3.9, in the final release of oslo deliverables. Please make sure that none of the master jobs are dependent on Python 3.8 . We faced some problems when we first attempted to remove python 3.8 support early and the removal was eventually reverted because of remaining usage of Focal and remaining lifecycle of Python 3.8. However now Python 3.8 is actually reaching its EOL, we may no longer attempt the same revert. https://governance.openstack.org/tc/reference/runtimes/2024.2.html Thank you, Takashi Kajinami -- Takashi Kajinami irc: tkajinam github: https://github.com/kajinamit launchpad: https://launchpad.net/~kajinamit

1 0

[tc][election] A call for election officials for 2024.2
by Goutham Pacha Ravi 29 Apr '24

29 Apr '24

Hello Stackers, I'd like to express my gratitude to Ian Y Choi and Tony Breeds for their service as OpenStack's election officials for the 2024.1 term. A hallmark of our community has been its leadership and the guiding principles [1] we use when defining them. In Aug-Sep 2024, we're going to be electing the next set of OpenStack Project Team Leads as well as 4 members of the OpenStack Technical Committee. We've run a combined election for PTLs and TC seats in the past few years. We envision doing the same for this upcoming election. Most of the election process is automated, and election officials help execute and oversee this process [2]. If you're interested in being an election official, please reach out to me. If you've previously served as an election official, please do not hesitate to reach out. If we have enough volunteers, you may do us a great favor by mentoring those doing this for the first time. Thank you, Goutham Pacha Ravi (gouthamr) OpenStack TC Chair [1] https://governance.openstack.org/tc/reference/principles.html [2] https://governance.openstack.org/election/process.html

1 0

Re: [magnum][magnum-capi][cinder] Override csi plugin to override availability zone for cinder
by Satish Patel 29 Apr '24

29 Apr '24

Thanks for the quick response. I would like to have this in the MCAPI driver so we have more control on variables by labels. Because each deployment is different. I have created issue here: https://github.com/vexxhost/magnum-cluster-api/issues/366 On Mon, Apr 29, 2024 at 5:26 PM Mohammed Naser <mnaser(a)vexxhost.com> wrote: > Hi Satish, > > > Replies inline, as I’m trying to “decompose” this. 😊 > > > > *From: *Satish Patel <satish.txt(a)gmail.com> > *Date: *Monday, April 29, 2024 at 5:13 PM > *To: *OpenStack Discuss <openstack-discuss(a)lists.openstack.org> > *Subject: *[magnum][magnum-capi][cinder] Override csi plugin to override > availability zone for cinder > > Folks, > > > > I have deployed a magnum with magnum-capi driver. Now trying to work with > a cinder for PV stuff and found some strange issue related to the > Availability Zone. > > > > My k8s cluster running in AZ: foo > > My Ceph/Cinder running in AZ: nova (default) > > > > I have created k8s cluster using magnum-capi selecting AZ: foo but when I > am trying to create/attach PV then getting an error saying invalid AZ. Ofc > because its in different AZ so I have add following snippet in Storage > class to override AZ of CSI > > > > allowedTopologies: - matchLabelExpressions: - key: > topology.cinder.csi.openstack.org/zone values: - nova > > > > So in this case, you do allow cross az attach inside OpenStack in order to > allow this, is this correct? Since the AZ of your storage != the AZ of > your compute nodes. > > > > PV creation completed successfully after applying the above change. Now > when I try to deploy ngnix and pass that PV then again I get a volume > affinity issue because worker nodes and volume are in different AZ. > > > > I did the following to change CSI plugin az to nova for worker node to > make it fix. > > > > kubectl label nodes kube-acrsf-default-worker-rxmg6-t7wzd > topology.cinder.csi.openstack.org/zone=nova --overwrite > > > > What is the proper workaround here for the above scenario and what would > be the proper way to fix it? > > > > In this case, what you’re doing is telling the node that it is running in > the `nova` AZ (which it is not!) > > > > Does magnum have Cinder CSI AZ label to override availability zone in > magnum template? > > > > > https://github.com/kubernetes/cloud-provider-openstack/blob/master/docs/cin… > > > > I believe in this case, you’ll need to set the ignore-volume-az if I > understand correctly, it seems Magnum does not have a default label for > this. If you want to file an issue to the CAPI driver we can add an option > to enable this and make it ignore it. >

1 0

[magnum][magnum-capi][cinder] Override csi plugin to override availability zone for cinder
by Satish Patel 29 Apr '24

29 Apr '24

Folks, I have deployed a magnum with magnum-capi driver. Now trying to work with a cinder for PV stuff and found some strange issue related to the Availability Zone. My k8s cluster running in AZ: foo My Ceph/Cinder running in AZ: nova (default) I have created k8s cluster using magnum-capi selecting AZ: foo but when I am trying to create/attach PV then getting an error saying invalid AZ. Ofc because its in different AZ so I have add following snippet in Storage class to override AZ of CSI allowedTopologies: - matchLabelExpressions: - key: topology.cinder.csi.openstack.org/zone values: - nova PV creation completed successfully after applying the above change. Now when I try to deploy ngnix and pass that PV then again I get a volume affinity issue because worker nodes and volume are in different AZ. I did the following to change CSI plugin az to nova for worker node to make it fix. kubectl label nodes kube-acrsf-default-worker-rxmg6-t7wzd topology.cinder.csi.openstack.org/zone=nova --overwrite What is the proper workaround here for the above scenario and what would be the proper way to fix it? Does magnum have Cinder CSI AZ label to override availability zone in magnum template?

1 0

[tacker] Cancelling IRC meeting
by Yasufumi Ogawa 29 Apr '24

29 Apr '24

Hi team, Due to holidays in Japan, I'd like to skip IRC meeting this week. Thanks, Yasufumi

1 0

[ironic][nova-scheduler] "host_state" in nova filters has stale aggregate information
by Michael Sherman 29 Apr '24

29 Apr '24

Hi all, We’re running into an issue, where for two sites with 150-250 ironic nodes on a single conductor and nova-compute instance, we’ve started to get “no hosts available” errors from nova scheduler. We’re using the blazar-nova filter to match on hosts in specifically tagged aggregates. After adding some debug logs, I found that the “host_state” object passed to the filter seems to have out-of-date aggregate information. Specifically, if I query the system with “openstack aggregate show …” or “openstack allocation candidate list”, I see the correct aggregate for the nodes in question, but the contents of “host_state” reflect a previous state. This “staleness” does not seem to correct itself over time, but is resolved by restarting the nova-scheduler process (actually restarting the kolla docker container, but the same effect). However the issues return over the course of a couple hours. We haven’t increased the number of nodes, or otherwise changed the hardware, so I’m not sure what could have triggered this issue. Any advice on further debugging steps would be greatly appreciated. Thank you! -- Michael Sherman Infrastructure Lead – Chameleon Computer Science, University of Chicago MCS, Argonne National Lab

3 13

[publiccloud-sig] Meeting on May 1st will be skipped
by Felix Kronlage-Dammers 29 Apr '24

29 Apr '24

Hi everyone, This Wednesday (May 1st) the next meeting of the publiccloud sig would be scheduled. However in a lot of the european countries this is a public holiday. As such Tobias and I decided that we will skip this call. A lot of us will be at the OpenInfra Day Berlin on the 15th of May - which would be the date for the next publiccloud sig, as such the one meeting on the 15th will happen during coffee break at the OID berlin :) (More infos on the OID Berlin here: https://oideurope2024.openinfra.dev/germany/#:~:text=15%20May%202024%20%7C%….) regards felix -- Felix Kronlage-Dammers Sovereign Cloud Stack — standardized, built and operated by many Ein Projekt der Open Source Business Alliance - Bundesverband für digitale Souveränität e.V. Tel.: +49-30-206539-205 | Matrix: @fkronlage:matrix.org | fkr(a)osb-alliance.com

1 0

[oslo] Rootwrap configuration issues (sudoers entries?)
by Francesco Di Nucci 29 Apr '24

29 Apr '24

Hello, I am configuring oslo rootwrap on my OpenStack instance, but I could only find documentation about nova-rootwrap like here <https://docs.openstack.org/oslo.rootwrap/latest/user/usage.html>. On the compute nodes it is now working, while I'm having troubles with eg. network nodes. I have added a sudoers entry on the like of the nova one: neutron ALL = (root) NOPASSWD: /usr/bin/neutron-rootwrap /etc/neutron/rootwrap.conf * But I don't know if it is correct, is there any documentation about it? Regards Francesco Di Nucci

2 3

[kolla] Weekly meeting cancelled on 1st of May
by Michał Nasiadka 29 Apr '24

29 Apr '24

Hello Koalas, Due to 1st of May being public holiday in some European countries (including Poland) - Kolla weekly meeting is cancelled. See you next week - 8th May. Michal

1 0

[neutron] Bug deputy - week of Apr 22
by Sławek Kapłoński 28 Apr '24

28 Apr '24

Hi, I was bug deputy last week and below is summary of what new bugs opened for Neutron during that time: ## High - https://bugs.launchpad.net/neutron/+bug/2063043 - octavia/ovn: filedescriptor out of range in select() - assigned to Fernando Royo ## Medium - https://bugs.launchpad.net/neutron/+bug/2063081 - [ovn] connectivity to load balancer with FIP from a server connected to a router with external gateway - assigned to Fernando Royo - https://bugs.launchpad.net/neutron/+bug/2063459 - # DHCP agent might use default gateway of unrouted subnets - assigned to Sebastian Lohff, patch already proposed ## Low - https://bugs.launchpad.net/neutron/+bug/2063669 - DNS extensions reported as available even if not enabled - unassigned, seems like kind of low hanging fruit for someone who wants to start ## Others - https://bugs.launchpad.net/neutron/+bug/2063463 - [ovn-octavia-provider] hairpin_snat_ip not set - unassigned -- Slawek Kaplonski Principal Software Engineer Red Hat

1 0

Losing connection when connecting br-ex to bond
by sarasoltanm2000＠gmail.com 28 Apr '24

28 Apr '24

The problem started from where I realized I couldn't ping or ssh the instances in openstack then I realized that it was a networking problem and that br-ex was not connected to my interfaces. for some reason I had to create a bond with a static private ip address of the second interface. (172.16.8.2/24). so to solve this problem I tried to connect the bond to the br-ex but as soon as I connect the bond to br-ex I get disconnected from the server (server cannot ping its gateway) and br-ex state goes down, when I connect it to the bond by the following command: sudo ovs-vsctl add-port br-ex bond0 and when I try to bring the bridge br-ex back up, the bond is automatically deleted from the ports. this is the configuration of bridges before adding the bond port: #ovs-vsctl show Manager "ptcp:6640:127.0.0.1" is_connected: true Bridge br-ex Controller "tcp:127.0.0.1:6633" is_connected: true fail_mode: secure datapath_type: system Port phy-br-ex Interface phy-br-ex type: patch options: {peer=int-br-ex} Port br-ex Interface br-ex type: internal Bridge br-int Controller "tcp:127.0.0.1:6633" is_connected: true fail_mode: secure datapath_type: system Port br-int Interface br-int type: internal Port "tapf556c-c7" tag: 1 Interface "tapf556c-c7" type: internal Port "tapd2980-19" tag: 4095 Interface "tapd2980-19" type: internal Port "qr-8ea26-da" tag: 4095 Interface "qr-8ea26-da" type: internal Port "tap89cc3-c0" tag: 2 Interface "tap89cc3-c0" type: internal Port int-br-ex Interface int-br-ex type: patch options: {peer=phy-br-ex} ovs_version: "2.12.0" any idea why this happens and what is the solution? btw the instance is not connected to a router and it is basically connected to 2 networks (172.16.8.32/28 and 172.16.8.48/28)

2 1

[Neutron] Openvswitch forcing MTU 1450
by Karl Kloppenborg 27 Apr '24

27 Apr '24

Hey Neutron team. I have an issue where within the VXLAN network of tenancies the expected 1500 MTU is honoured but despite all MTU in the underlay being 9k and all networks and paths set to 1500, Openvswitch caps the MTU transiting north/south to 1450. This is causing considerable pain to some of our customers and despite trying to force the openvswitche bridges request_mtu to 1500, and all interfaces look right, it’s still caping at 1450. Note, TCP dumps show the pings set to 1500 getting to the network namespace on the openvswitch agent, so it appears something between the nat/snat process. VM1 private -> VM2 private (mtu 1500) = works VM1 private -> VM2 public (mtu 1500) = fails VM -> External (mtu 1500) = fails External Host -> VM (mtu 1500) = fails Adusting to 1422 on ping sizes works. Anyone experienced this? I cannot seem to make heads or tails of it. Thanks, Karl.

1 1

[nova] allow only specific instances on host aggregate
by Eugen Block 26 Apr '24

26 Apr '24

Hi, I'm playing around with host aggregates and the aggregate_instance_extra_specs for flavors. I successfully created a host aggregate, it allows me to schedule instances with a specific flavor on that aggregate only. But is there a way to prevent other VMs from starting on that aggregate (which were launched with different flavors)? The only thing coming to mind is to put that compute node(s) into a different availbility zone. Since the default is "nova", this would prevent anything else to start on that hypervisor. Is there anything I missed with aggregates? Any pointers are appreciated! Thanks! Eugen

3 7

how to set up configuration parameter for a datastore
by 龚永生 26 Apr '24

26 Apr '24

hi, chunyang I installed torve 2023.2, but failed to list the configuration parameter list: root@compute2:~# openstack datastore list +--------------------------------------+----------+ | ID | Name | +--------------------------------------+----------+ | ee74cbff-92d1-4f83-a06e-cd40fb45bac6 | dt_mysql | +--------------------------------------+----------+ root@compute2:~# openstack datastore version list dt_mysql +--------------------------------------+------------+---------+ | ID | Name | Version | +--------------------------------------+------------+---------+ | 82e71712-4e4d-4ff6-947f-8de4c1535d15 | ver_5.7.29 | 5.7.29 | | 8ba2ab5f-6dd1-4f25-b571-4031361a91cf | ver_8.3 | 8.3 | +--------------------------------------+------------+---------+ root@compute2:~# openstack database configuration parameter list 82e71712-4e4d-4ff6-947f-8de4c1535d15 and failed to create configruantion group as well: root@compute2:~# openstack database configuration create group1 '{"sync_binlog" : 1}' --datastore dt_mysql Configuration groups are not supported for this datastore: dt_mysql ver_8.3 (HTTP 422) could you tell me how to enable the configuration parameter list? regards. 龚永生浙江九州未来信息科技有限公司 99CLOUD Co. Ltd. 邮箱（Email）：gong.yongsheng(a)99cloud.net 地址：海淀区上地六街研华大厦5层南侧手机（Mobile)：+86-18618199879 公司网址（WebSite）：http://99cloud.net

1 0

Instance stuck in BUILD status
by 西岭 25 Apr '24

25 Apr '24

Dear openstack trove module developers, I was having trouble creating a trove instance and kept showing build status. My create command is: trove create mysql_zh-11 1 --size 5 --nic net-id=5f161d13-0cfb-4707-9bd6-f23850d86fbf --databases dbtest --users user:password --datastore mysql --datastore_version mysql-5.6 After entering the trove list command, the final state is: | bdcb298c-86d3-42c5-b7af-1cc0c7f93904 | mysql_zh-11 | mysql | mysql-5.6 | BUILD | 1 | 5 | RegionOne | The image I used was downloaded from the openstack website: trove-train-mysql-ubuntu-xenial Enter the openstack server list command and it will display: 2bf580eb-3c93-4689-9b53-e76307beb241 | mysql_zh-11 | ACTIVE | external-net=192.168.0.56 | trove-train-mysql-ubuntu-xenial | mysql-mini | I don't know the username and password of the image, so I can't see the specific information inside the cloud host. In addition, when I used the tool to change the login username and password of the above image, and created the trove instance with the image, after waiting 3600 seconds, it showed: trove.taskmanager.models [-] Service status: ERROR, service error description: guestagent error: TroveError: Failed to get server 0908ee4e-9f1d-444a-9c69-c8b8cc9d8938 for instance 03c2a10c-87f1-4169-9cf7-13735ff8756c, error: Failed to validate token (HTTP 404) (Request-ID: req-9604fb4c-4aae-4351-8996-5ee4dfbd9ad3) This time, I was able to log in to the cloud host generated during the creation of trove. After entering, I found that the guest-agent service failed to start. The reasons were: sudo chown -R ubuntu:root /etc/trove/conf.d cannot be executed. I wonder if it is because the password of the image has been changed? Then, I used the same image to create the trove instance again, and during the instance creation process, I went to the cloud host and started the guest-agent service manually. The result was the same. What else did I miss when creating the instance? How to solve this problem? See attachment for details of trove log. Thank you very much for your help. ----------------------------------------------------- Xi Ling, from Qingdao, China April 25, 2024

2 1

[openstack][nova] Resize instance cause instance error
by Nguyễn Hữu Khôi 25 Apr '24

25 Apr '24

Hello everyone. Sometimes, I resize instance and this instance cannot be resized then it will be error state. I use Kolla-Ansbile Yoga with Dell Powestore5000T as backend with iscsi protocol. I report in this: https://bugs.launchpad.net/nova/+bug/2063345 Pls give some ideas on it? Thank you much Nguyen Huu Khoi

1 1

red hat integration with ceph error
by Adivya Singh 25 Apr '24

25 Apr '24

hi, anybody see this error before, while integrating red hat open stack with ubuntu ceph overcloud-computeids-2 | error={"ansible_job_id": "34 6042025410.662459", "attempts": 2, "changed": false, "finished": 1, "msg": "Paunch failed with config_id tripleo_step4", "rc": 1, "stderr": "Error executing ['podman', 'container', 'exists' , 'nova_libvirt_init_secret']: returned 1\nDid not find container with \"['podman', 'ps', '-a', '--filter', 'label=container_name=nova_libvirt_init_secret', '--filter', 'label=config_id=tri pleo_step4', '--format', '{{.Names}}']\" - retrying without config_id\nDid not find container with \"['podman', 'ps', '-a', '--filter', 'label=container_name=nova_libvirt_init_secret', '--f ormat', '{{.Names}}']\"\nError executing ['podman', 'run', '--name', 'nova_libvirt_init_secret', '--label', 'config_id=tripleo_step4', '--label', 'container_name=nova_libvirt_init_secret', '--label', 'managed_by=tripleo-Computeids', '--label', 'config_data={\"command\": [\"/bin/bash\", \"-c\", \"/usr/bin/virsh secret-define --file /etc/nova/secret.xml && SECRET_UUID=$(fgrep \ \\\\"fsid = \\\\\" /etc/ceph/ceph.conf | cut -d \\\\\" \\\\\" -f 3) && test -n \\\\\"$SECRET_UUID\\\\\" && SECRET_KEY=$(fgrep \\\\\"key = \\\\\" /etc/ceph/ceph.client.openstack.keyring | cu t -d \\\\\" \\\\\" -f 3) && test -n \\\\\"$SECRET_KEY\\\\\" && /usr/bin/virsh secret-set-value --secret $SECRET_UUID --base64 $SECRET_KEY\\\\n\"], \"detach\": false, \"image\": \"192.168.0. 1:8787/rhosp-rhel8/openstack-nova-libvirt:16.2\", \"net\": \"host\", \"privileged\": false, \"security_opt\": \"label=disable\", \"user\": \"root\", \"volumes\": [\"/etc/hosts:/etc/hosts:ro \", \"/etc/localtime:/etc/localtime:ro\", \"/etc/pki/ca-trust/extracted:/etc/pki/ca-trust/extracted:ro\", \"/etc/pki/ca-trust/source/anchors:/etc/pki/ca-trust/source/anchors:ro\", \"/etc/pk i/tls/certs/ca-bundle.crt:/etc/pki/tls/certs/ca-bundle.crt:ro\", \"/etc/pki/tls/certs/ca-bundle.trust.crt:/etc/pki/tls/certs/ca-bundle.trust.crt:ro\", \"/etc/pki/tls/cert.pem:/etc/pki/tls/c ert.pem:ro\", \"/dev/log:/dev/log\", \"/etc/puppet:/etc/puppet:ro\", \"/var/lib/config-data/puppet-generated/nova_libvirt/etc/nova:/etc/nova:ro\", \"/etc/ceph:/etc/ceph:ro\", \"/etc/libvirt :/etc/libvirt\", \"/var/run/libvirt:/var/run/libvirt:shared,z\", \"/var/lib/libvirt:/var/lib/libvirt:shared\"], \"environment\": {\"TRIPLEO_CONFIG_HASH\": \"f780b2585d2cb2edc5954608158cf938 \"}}', '--conmon-pidfile=/var/run/nova_libvirt_init_secret.pid', '--log-driver', 'k8s-file', '--log-opt', 'path=/var/log/containers/stdouts/nova_libvirt_init_secret.log', '--env=TRIPLEO_CON regards Adivya Sungh

2 1

[I18n][PTG] 2024.2 Dalmatian PTG - I18n SIG summary
by Ian Y. Choi 25 Apr '24

25 Apr '24

Hi all, As I18n SIG lead, I would like to share with you a summary of the recent discussions held during the 2024.2 Dalmatian PTG regarding the Internationalization (I18n) Special Interest Group (SIG). Firstly, I would like to express my sincere appreciation to the entire community for their commitment to make OpenStack more internationalized. The efforts put forth in translating and making OpenStack accessible globally are truly commendable, thanks to the contributions of numerous individuals, although we are under unprecedented situations and even Zanata will sunset soon [1]. During the PTG, I18n SIG covered several important topics with active and invaluable contributors including Seongsoo (a special thanks for his leadership both I18n team and within the Korea User group): 1. Progress on open reviews for I18n: We discussed pending items in the OpenStack/I18n repository and the status of various reviews. 2. Discussion on the OpenStack/I18n repository structure: This included plans to embrace the use of Weblate - wlc library and add tox environment and corresponding requirements.txt. 3. Pilot work progress on governance translation support: A demonstration was provided on setting up a new project with API and CLI. 4. Feasibility discussion on migrating from translate.openstack.org earlier than [1]. Deliberation on target languages and next steps for user survey translation. 5. User survey translation discussion: Target languages and next steps were deliberated upon. In sum, I18n will continue our effort to finalize the migration from Zanata to Weblate to emphasize the importance of I18n as a fundamental component for global OpenStack accessibility. Thank you for your continuation of the I18n SIG. If you have any questions or would like further information on any of the discussed topics, please don't hesitate to reach out. Best regards, /Ian [1] https://lists.osci.io/hyperkitty/list/zanata-sunset@lists.osci.io/thread/6F… [2] I18n PTG Etherpad: https://etherpad.opendev.org/p/apr2024-ptg-i18n [3] I18n PTG Team Photo 1: https://1drv.ms/i/s!AgSCQctkWshsgb8ZvM-l7Ol1UOxNjA?e=5tdLpb [3] I18n PTG Team Photo 2: https://cdn.discordapp.com/attachments/1192271703057911888/1228373792162840…

1 0

Compute Resources
by Gk Gk 25 Apr '24

25 Apr '24

Hi, Is there a way to find out the available ram, disk and vcpus on a compute node for vm creation using any placement APIs or any other way ?

3 3

[cinder][dev][ptl] NVMe/FC
by yian.zong＠dell.com 25 Apr '24

25 Apr '24

Hi cinder team, I'd like to know if cinder supports NVMe/FC. From nvmeof connector [1], it seems only RoCE(RDMA) and TCP. [1] https://opendev.org/openstack/os-brick/src/branch/master/os_brick/initiator… Thank you! Yian

5 5

[cinder][PTG] 2024.2 Dalmatian PTG summary
by Jon Bernard 25 Apr '24

25 Apr '24

Hello everyone, thanks for a very productive PTG for the Dalmatian cycle. Below is a brief summary of the highlights. The raw etherpad notes are here[1] and both the summary and transcribed etherpad notes are captured in our wiki here[2]. # Improve driver documentation When proposing new or updating existing drivers, our interface can be confusing. We agreed on an effort to migrate class documentation to the interface definitions, make clear the mandatory and optional methods for drivers, and maintain this documentation going forward. # User visible information in volume types Volume type metadata and extra specs are not visible to users, making it difficult to ascertain whether a volume type will lead to encryption or replication. Agreement was reached on metadata fields similar to Glance's metadefs, allowing drivers to report capabilities in a standard way and allowing that metadata to become visible to admins and users. # Optional backup driver dependencies Although volume driver dependencies are optional, those of our backup drivers are listed in requirements and are therefore always installed irrespective of deployment configuration. Agreement was reached to move these dependencies to driver-requirements. This should simplify efforts of both deployers and packagers. # Simplify deployments A few ideas were proposed to improve our deployment: * When cinder-volume is deployed in an active-active configuration, our `backend_host` parameter must be updated on every backend to have the same value, we would like to remove this additional step. * Use of predictable names to define tenants, instead of unique IDs. * Have dedicated quote section in our configuration for quote-related options. # Response schema validation A spec to add response schema validation in addition to our existing request validation was proposed. With adequate coverage, clients in various languages could be autogenerated (in theory). No significant objects were raised, agreement to review related patches this cycle. # Documentation of Ceph auth requirements We do not provide comprehensive and easy-to-find documentation on exactly what authentication/permission expectations there are between different services, leading deployers troubleshoot themselves and not be able to rely on upstream best practices. Agreement to improve this situation in the current cycle. # Cinder backup improvements An accumulation of bug fixes and performance improvements have stalled in the review queue. We went through the major ones as a team to attempt to bring awareness and unblock the remaining review requirements. See WIKI notes for specific details. # Migrating backups between multiple backends There is desire to support multiple backup backends where new backups go to a new backend while backups in an old backend remain readable. We want to avoid needing to create a full backup in the new backend to support incremental snapshots (and the associated charge). A spec will be proposed for review and work towards this goal will proceed during this cycle. # Cross-project with Glance In a cross-project collaboration with the Glance team, an improved method for image migration was proposed. Agreement to introduce a new migration operation in Glance. Cinder context was provided and a consensus on path forward was reached. # Cross-project with Nova In a cross-project collaboration with both Nova and Glance, the topic of image encryption was discussed. Dan Smith from the Nova team provided input from the Nova side. Cinder and Nova expect LUKS formatted images, but Glance currently supports GPG encrypted images - requiring re-encryption prior to use. It was noted that LUKS encrypted images can be created without root permission and the Glance team is now looking to drop GPG support and consolidate around LUKS as our unified format. # Active-Active support for NetApp A NetApp engineer raised questions about adding active-active support to the driver. Questions were answered and that work should proceed in this cycle. # Performance of parallel clone operations For the clone operation in cinder we're using a single distributed lock to prevent the source volume from being deleted mid-operation. This causes multiple concurrent clone operations to block. Under the right conditions, this can cause a significant performance degradation. Multiple possible solutions were discussed (read-write locks) and a consensus to use the DB was reached. Some details are unclear, awaiting a spec before moving forward. # Volume encryption with user defined keys Cinder does not currently support encryption with key provided by the user. Users could both manage their own keys and data could be recovered even if keys are lost at the deployment. There are several technical challenges to support this. Several of these hurdles were raised, more thought and research is needed before we have a spec that could be reviewed. [1] https://etherpad.opendev.org/p/dalmatian-ptg-cinder [2] https://wiki.openstack.org/wiki/CinderDalmatianPTGSummary -- Jon

2 1

[ironic][neutron] Another networking path for Ironic?
by Julia Kreger 25 Apr '24

25 Apr '24

Greetings folks, During the Ironic PTG last week, Ironic had our busiest PTG session on the topic of networking, and what to do in order to move things forward. I think the best way to frame how we reached the discussion is to keep in mind that projects in our community have been built upon boundaries of delineation. For example, Nova for is virtualization. Ironic’s area has been bare metal machine deployment and lifecycle management. Neutron’s area has been networking. Ironic has always fit a little more awkwardly into this model due to the nature of bare metal – as evidenced by the networking related (networking-generic-switch, networking-baremetal) projects living under Ironic’s governance driven by the need to be able to toggle physical switch ports to ensure a secure provisioning process. Now it's getting even more awkward as the lines between a server and a switch start to blur. Ironic is one of the few OpenStack projects that has significant use cases outside of a fully integrated OpenStack cluster. Additionally, even in the fully integrated case, bare metal is often not the primary use case considered -- quite understandable since virtualized networking is not a trivial problem. This combination of two factors: physical networking being a secondary use case for Neutron, and operators wanting to get physical network automation even without a fully integrated OpenStack, leads to difficulties both on the development side and the operational side. This creates a situation where Ironic’s answer to just basic network automation of “use Neutron and an ML2 plugin” is really not tenable for many infrastructure operators. The underlying challenge is that infrastructure operators need something for just basic management actions like attaching or detaching hosts from physical networks which also works in a model of respecting separation of duties. This is further complicated with DPUs and the changing landscape DPUs are creating by forcing a much more complex interaction when it comes to just basic networking needs for supporting the deployment of a bare metal host. To attach a network to a host, it is no longer just toggle a switchport configuration, it is potentially toggle a switchport *and* toggle configuration on a DPU device. And in this weeks’ Ironic PTG session, “Future of networking”[0], discussion of DPUs helped us reach a tipping point for the discussion. The idea of a separate network interface (for Ironic to use) which was not neutron, reached a point of being a chorus of contributors. So to put it in different words, Ironic is considering implementing functionality for Switch and DPU device network configuration management in terms of device attachment to networks which would likely leverage the existing ML2 plugin model such that Ironic can trigger port attachment and detachment directly. We’re not talking about doing anything beyond attachment and detachment. This means aspects like IPAM, Security Groups, Routing, and so on and so forth are entirely off the table for us. Our answer for such will continue to be “use neutron.” The discussion thus far has focused on not replacing existing plugins, but to enable their use. To use the plugins today, Neutron and the involvement of other OpenStack services are required – which is not viable for approximately half of Ironic’s usage base. For example, a Metal3 user is only using Ironic as an embedded tool, and if their environment requires VXLAN networks to be terminated on a DPU then they would need to create/invent tooling to facilitate that, or we can solve that with Ironic and account for the overall physical machine lifecycle at the same time. We also see a path where we can better integrate with Neutron and help operator’s meet more restrictive security requirements by delineating part of the functionality into Ironic’s scope when leveraging upstream solutions. We realize there are many unknowns, and welcome Neutron contributors to collaborate[1] with us, as this could ultimately impact project scope. Thoughts? Thanks, Julia [0]: https://etherpad.opendev.org/p/ironic-ptg-april-2024#L609 [1]: https://review.opendev.org/c/openstack/ironic-specs/+/916126/

2 2