June 2023 - openstack-discuss - lists.openstack.org

[neutron][ptg] PTG summary
by Rodolfo Alonso Hernandez 20 Jun '23

20 Jun '23

Hello all: Thank you for joining us during the Forum session and the PTG slots. It was very productive and we were able to check the pulse of OpenStack and Neutron in particular. This time both the Forum session and the PTG were attended mainly by operators and users; the number of developers was reduced and this is something we need to improve. A healthy community is nourished by the active participation of their members, not only pushing new code but reviewing and helping fixing the new bugs. === Forum session === That was a good surprise for me to find so many people in the room. I wasn't expecting that after checking the etherpad link provided before the meeting. During this short session, focused on issues/pain points of Neutron, we could find out that: * The ML2/OVN backend is increasing its adoption rate. * Most users have deployments between Wallaby and Antelope. * Hardware offload is increasing its demand due to the network BW increasing requirements. * BGP/eVPN is deployed in most of the environments. >From this session I would highlight some lessons learned for next events: * If the Forum session time slot is reduced (30 mins), the attendant interventions should be limited to 2-3 minutes, enough to describe the issue. Any further discussion should be taken in the PTG sessions. * Request attendance "checkin" in the etherpad, to be prepared for the event. * Request people to add their questions in the etherpad in advance. === PTG === We didn't have technical sessions but many questions about issues and possible bugs. These are the most relevant ones: *** OVN L3 scheduler issue *** This issue has been reproduced in an environment with more than 5 chassis with gateway ports. The router GW ports are assigned to the GW chassis using a manual scheduler implemented in Neutron (the default one is ``OVNGatewayLeastLoadedScheduler``). If one of the chassis is stopped, the GW ports should be re-assigned to the other GW chassis. This is happening but all ports fall under the same one; this re-scheduling should share the ports among the other active chassis. * Action item: I'll open a LP bug and investigate this issue. *** Size of the OVN SB "HA_Chassis_Group" table *** The OVN SB "HA_Chassis_Group" increases its size indefinitely with each operation creating a router and assigning a new external gateway (external network). This table never decreases, * Action item: I'll open a LP bug, investigate this issue and if this is a core OVN issue, report it. *** Live migration with ML2/OVN *** This is a common topic and not only for ML2/OVN. The migration time has many factors (memory size, applications running, network BW, etc) that could slow down the migration time and trigger a communication gap during this process. * Action item: to create better documentation, both in Nova and Neutron, about the migration process, what has been done to improve it (for example, the OVN multiple port binding) and what factors will affect the migration. *** ML2/OVN IPv6 DVR *** This spec was approved during the last cycle [1]. The implementation [2] is under review. * Action item: to review the patch (for Neutron reviewers) * Action item: to implement the necessary tempest tests (for the feature developers) *** BGP with ML2/OVS, exposing address blocks *** This user has successfully deployed Neutron with ML2/OVS and n-d-r. This user is currently making public a certain set of FIPs. However, for other VMs without FIPs, the goal is to make the router GW port IP address public, using the address blocks functionality; this is not working according to the user. * Action item: (for this user) to create a LP bug describing the architecture of the deployment, the configuration used and the API commands used to reproduce this issue. *** Metadata service (any backend) *** Neutron is in charge of deploying the Metadata service on the compute nodes. Each time the metadata HTTP server is called, it requests from the Neutron API the instance and tenant ID [3]. This method implies a RPC call. In "busy" compute nodes, where the VMs are created and destroyed very fast, this RPC communication is a bottleneck. * Action item: open a LP bug to implement the same ``CacheBackedPluginApi`` used in the OVS agent. This RPC cached class creates a set of subscriptions to the needed resources ("ports" in this case). The Neutron API will send the port updated info and cached locally; that makes unnecessary the RPC request if the resources are stored locally. *** ML2/OVN + Ironic nodes *** This user has deployed ML2/OVN with Ironic nodes, and is using ovn-bgp-agent with the eVPN driver to make public the private ports (IP and MACs) to the Ironic node ports. More information in [4]. *** BGP acceleration in ML2/OVN *** Many questions related to this topic, both with DPDK and HW offload. I would refer (once the link is available) to the talk "Enabling multi-cluster connectivity using dynamic routing via BGP in Openstack" given by Christophe Fontaine during this PTG. You'll find it very interesting how this new implementation moves all the packet processing to the OVS datapath (removing any Linux Bridge / iptables processing). The example provided in the talk refers to the use of DPDK. I hope this PTG was interesting for you! Don't hesitate to use the usual channels that are the mailing list and IRC. Remember we have the weekly Neutron meeting every Tuesday at 1400UTC. Regards. [1] https://specs.openstack.org/openstack/neutron-specs/specs/2023.1/ovn-ipv6-d… [2]https://review.opendev.org/c/openstack/neutron/+/867513 [3] https://github.com/openstack/neutron/blob/cbb89fdb1414a1b3a8e8b3a9a4154ef62… [4]https://ltomasbo.wordpress.com/2021/06/25/openstack-networking-with-evpn/

3 6

Help Needed: Configuring OpenStack Glance with VMware
by Anupam Panta 20 Jun '23

20 Jun '23

Dear OpenStack Community, I hope this email finds you well. I am reaching out to seek assistance and guidance regarding the configuration of OpenStack integration with VMware. I have encountered some difficulties while trying to configure Glance, and I would greatly appreciate any help or insights you can provide. Here is a brief overview of the issue I am facing: * Configuration Challenge: I am currently working on integrating OpenStack with VMware as the backend infrastructure for image storage and management. * Specific Problem: While configuring Glance, I am stuck with an error message stating "Store for identifier vmware not found". * Configuration Attempts: I have reviewed the relevant documentation and followed the recommended steps, tried changing parameters to configure the VMware store backend in Glance. However, despite my efforts, the error persists. I kindly request your guidance and expertise to help me troubleshoot and resolve this issue. Any advice, best practices, or configuration examples related to Glance integration with VMware would be highly appreciated. To provide you with more context, here are some relevant details of my environment: I am using kolla installation for openstack deployment. My global.yml file consists of: ``` #### GLANCE CONFIG glance_backend_vmware: "yes" glance_backend_insecure: "yes" #### VMWARE CONFIG vmware_vcenter_host_ip: <my-vcenter-ip-address> vmware_vcenter_host_username: <my-vcenter-admin-username> vmware_vcenter_host_password: <my-vcenter-admin-password> vmware_datastore_name: glance-datastore vmware_vcenter_name: <my-vcenter-domain-name> vmware_vcenter_cluster_name: "openstack" vmware_vcenter_datacenter_name: <my-vcenter-datacenter-name> vmware_vcenter_insecure: "True" ``` After running reconfigure command, my glance-api container stuck in restart loop, with error message "Store for identifier vmware not found". I also tried changing parameters in glance-api.conf file, specific parameters `default_backend= vsphere`, `stores= file, http, swift, vmware`. Your assistance will not only help me but also contribute to the collective knowledge of the community. Thank you in advance for your time and support. I look forward to your valuable insights and suggestions. Regards, Anupam Panta | LinkedIn<http://www.linkedin.com/in/anupam-panta> System Engineer anupam.panta(a)f1soft.com 9802079915 Movers & Shakes Tower, Pulchowk, Nepal [cid:78d40d57-4926-472e-bbe6-ea05244f879f] <https://f1soft.com/> Disclaimer This e-mail and any attachments may contain confidential and privileged information. If you are not the intended recipient, please notify the sender immediately by return e-mail, followed by deleting this e-mail and destroying any copies thereof Any dissemination or use of this information by a person other than the intended recipient is unauthorized and may be illegal unless consented by the sender. F1soft International Private Limited or its employees are not responsible for any auto-generated spurious messages that you may receive from F1soft email addresses.

2 1

[cinder] in-use volume retype error "Expecting to find domain in project"
by Eugen Block 20 Jun '23

20 Jun '23

Hi, while trying to reproduce the issue mentioned in [1] I stumbled upon [2], I commented there but because of the "wishlist" importance I don't expect too much attention. I have a production cloud with Victoria where I see the same issue as described in [2], trying to retype an in-use volume results in a stack trace in cinder: 2023-06-20 12:45:52.900 1085571 ERROR oslo_messaging.rpc.server keystoneauth1.exceptions.http.BadRequest: Expecting to find domain in project. The server could not comply with the request since it is either malformed or otherwise incorrect. The client is assumed to be in error. (HTTP 400) (Request-ID: req-6b412e96-a735-4b94-a5e6-8252dd949297) I have also a test cloud installed the same way as the production cloud with V and upgraded to Wallaby where this stack trace does not occur, retyping an in-use volume just works there. I tried the described workaround in [1] and added a [nova] section to the cinder.conf, and that worked. There is no such section in the W cloud. I checked the Wallaby release notes and the only thing related to retype with ceph as backend is [3]. Could that make the difference here? One difference between V and W I noticed was that in V I see two volumes with the same name (but a different UUID, of course) during the retype process while in W I see only one volume at all times. So I assume that W handles the retype differently and it doesn't require a nova section. I'd appreciate any comment. Thanks, Eugen [1] https://lists.openstack.org/pipermail/openstack-discuss/2023-June/034160.ht… [2] https://bugs.launchpad.net/cinder/+bug/1941062 [3] https://bugs.launchpad.net/cinder/+bug/1886543

1 0

OpenStack (cinder) volumes retyping on Ceph back-end
by Andrea Martra 20 Jun '23

20 Jun '23

Hello, I configured different back-end storage on OpenStack (Yoga release) and using Ceph (ceph version 17.2.4) with different pools (volumes, cloud-basic, shared-hosting-os, shared-hosting-homes,...) for RBD application. I created different volume types towards each of the backends and everything works perfectly. If I perform a "change volume type" from OpenStack on volumes attached to the VMs the system successfully migrates the volume from the source pool to the destination pool and at the end of the process the volume is visible in the new pool and is removed from the old pool. The problem encountered is that when reconfiguring the VM, to specify the new pool associated with the volumes (performed through a resize of the VM, I haven't found any other method to change the information on the nova/cinder db automatically. I also did some tests shut-off of the VM and modification of the xml through virsh edit and startup the VM) the volume presented to the VM is exactly the version and content on the retype date of the volume itself. All data written and modified after the retype is lost. The VM after the retype continues to work perfectly in RW but the "new" volume created in the new pool is not used to write data and consequently when the VM is shut down all the changes are lost. Do you have any idea how to carry out a check and possibly how to proceed in order not to lose the data of the vm of which I have retyped the volume? The data is written somewhere (the IO is still going to the old pool/image although they already have been removed) because the VMs work perfectly. Thank you -- Andrea Martra +39 393 9048451

1 0

[kolla] rabbitmq failed to build image using 2023.1 release
by Satish Patel 20 Jun '23

20 Jun '23

Folks, Do you know how to solve this? I am using release 2023.1 of kolla to build images using ubuntu 22.04 root@docker-reg:/opt/kolla/etc/kolla# kolla-build --registry docker-reg:4000 --config-file kolla-build.conf --debug --threads 1 --skip-existing --push --cache --format none rabbitmq INFO:kolla.common.utils:Using engine: docker INFO:kolla.common.utils:Found the container image folder at /usr/local/share/kolla/docker INFO:kolla.common.utils:Added image rabbitmq to queue INFO:kolla.common.utils:Attempt number: 1 to run task: BuildTask(rabbitmq) DEBUG:kolla.common.utils.rabbitmq:Processing INFO:kolla.common.utils.rabbitmq:Building started at 2023-06-11 02:25:44.208880 DEBUG:kolla.common.utils.rabbitmq:Turned 0 plugins into plugins archive DEBUG:kolla.common.utils.rabbitmq:Turned 0 additions into additions archive INFO:kolla.common.utils.rabbitmq:Step 1/11 : FROM docker-reg:4000/kolla/base:2023.1 INFO:kolla.common.utils.rabbitmq: ---> 4551f4af8ddf INFO:kolla.common.utils.rabbitmq:Step 2/11 : LABEL maintainer="Kolla Project (https://launchpad.net/kolla)" name="rabbitmq" build-date="20230611" INFO:kolla.common.utils.rabbitmq: ---> Using cache INFO:kolla.common.utils.rabbitmq: ---> 6c2ef10499f7 INFO:kolla.common.utils.rabbitmq:Step 3/11 : RUN usermod --append --home /var/lib/rabbitmq --groups kolla rabbitmq && mkdir -p /var/lib/rabbitmq && chown -R 42439:42439 /var/lib/rabbitmq INFO:kolla.common.utils.rabbitmq: ---> Using cache INFO:kolla.common.utils.rabbitmq: ---> 29ef8940f40b INFO:kolla.common.utils.rabbitmq:Step 4/11 : RUN echo 'Uris: https://ppa.launchpadcontent.net/rabbitmq/rabbitmq-erlang/ubuntu' >/etc/apt/sources.list.d/erlang.sources && echo 'Components: main' >>/etc/apt/sources.list.d/erlang.sources && echo 'Types: deb' >>/etc/apt/sources.list.d/erlang.sources && echo 'Suites: jammy' >>/etc/apt/sources.list.d/erlang.sources && echo 'Signed-By: /etc/kolla/apt-keys/erlang-ppa.gpg' >>/etc/apt/sources.list.d/erlang.sources && echo 'Uris: https://dl.cloudsmith.io/public/rabbitmq/rabbitmq-server/deb/ubuntu' >/etc/apt/sources.list.d/rabbitmq.sources && echo 'Components: main' >>/etc/apt/sources.list.d/rabbitmq.sources && echo 'Types: deb' >>/etc/apt/sources.list.d/rabbitmq.sources && echo 'Suites: jammy' >>/etc/apt/sources.list.d/rabbitmq.sources && echo 'Signed-By: /etc/kolla/apt-keys/rabbitmq.gpg' >>/etc/apt/sources.list.d/rabbitmq.sources INFO:kolla.common.utils.rabbitmq: ---> Using cache INFO:kolla.common.utils.rabbitmq: ---> 6d92a7342a90 INFO:kolla.common.utils.rabbitmq:Step 5/11 : RUN apt-get --error-on=any update && apt-get -y install --no-install-recommends logrotate rabbitmq-server && apt-get clean && rm -rf /var/lib/apt/lists/* INFO:kolla.common.utils.rabbitmq: ---> Running in 0deab7961445 INFO:kolla.common.utils.rabbitmq:Get:1 http://ubuntu-cloud.archive.canonical.com/ubuntu jammy-updates/antelope InRelease [5,463 B] INFO:kolla.common.utils.rabbitmq:Get:2 http://archive.ubuntu.com/ubuntu jammy-backports InRelease [108 kB] INFO:kolla.common.utils.rabbitmq:Get:3 http://mirrors.ubuntu.com/mirrors.txt Mirrorlist [3,447 B] INFO:kolla.common.utils.rabbitmq:Get:7 http://ubuntu-cloud.archive.canonical.com/ubuntu jammy-updates/antelope/main amd64 Packages [126 kB] INFO:kolla.common.utils.rabbitmq:Get:8 https://dl.cloudsmith.io/public/rabbitmq/rabbitmq-server/deb/ubuntu jammy InRelease [5,152 B] INFO:kolla.common.utils.rabbitmq:Get:9 https://ppa.launchpadcontent.net/rabbitmq/rabbitmq-erlang/ubuntu jammy InRelease [18.1 kB] INFO:kolla.common.utils.rabbitmq:Get:5 http://mirror.siena.edu/ubuntu jammy-updates InRelease [119 kB] INFO:kolla.common.utils.rabbitmq:Get:10 https://dl.cloudsmith.io/public/rabbitmq/rabbitmq-server/deb/ubuntu jammy/main amd64 Packages [9,044 B] INFO:kolla.common.utils.rabbitmq:Get:6 http://ftp.usf.edu/pub/ubuntu jammy-security InRelease [110 kB] INFO:kolla.common.utils.rabbitmq:Get:11 http://archive.ubuntu.com/ubuntu jammy-backports/universe amd64 Packages [27.0 kB] INFO:kolla.common.utils.rabbitmq:Get:4 https://archive.linux.duke.edu/ubuntu jammy InRelease [270 kB] INFO:kolla.common.utils.rabbitmq:Get:12 http://archive.ubuntu.com/ubuntu jammy-backports/main amd64 Packages [49.4 kB] INFO:kolla.common.utils.rabbitmq:Get:14 http://ubuntu.osuosl.org/ubuntu jammy-updates/main amd64 Packages [857 kB] INFO:kolla.common.utils.rabbitmq:Get:17 https://ppa.launchpadcontent.net/rabbitmq/rabbitmq-erlang/ubuntu jammy/main amd64 Packages [8,167 B] INFO:kolla.common.utils.rabbitmq:Get:16 http://pubmirrors.dal.corespace.com/ubuntu jammy-security/universe amd64 Packages [928 kB] INFO:kolla.common.utils.rabbitmq:Get:15 https://atl.mirrors.clouvider.net/ubuntu jammy-security/main amd64 Packages [575 kB] INFO:kolla.common.utils.rabbitmq:Get:19 http://www.club.cc.cmu.edu/pub/ubuntu jammy/main amd64 Packages [1,792 kB] INFO:kolla.common.utils.rabbitmq:Get:18 http://mirror.team-cymru.com/ubuntu jammy/universe amd64 Packages [17.5 MB] INFO:kolla.common.utils.rabbitmq:Get:13 http://mirrors.syringanetworks.net/ubuntu-archive jammy-updates/universe amd64 Packages [1,176 kB] INFO:kolla.common.utils.rabbitmq:Fetched 23.7 MB in 6s (4,091 kB/s) INFO:kolla.common.utils.rabbitmq:Reading package lists... INFO:kolla.common.utils.rabbitmq:Reading package lists... INFO:kolla.common.utils.rabbitmq:Building dependency tree... INFO:kolla.common.utils.rabbitmq:Reading state information... INFO:kolla.common.utils.rabbitmq:Some packages could not be installed. This may mean that you have INFO:kolla.common.utils.rabbitmq:requested an impossible situation or if you are using the unstable INFO:kolla.common.utils.rabbitmq:distribution that some required packages have not yet been created INFO:kolla.common.utils.rabbitmq:or been moved out of Incoming. INFO:kolla.common.utils.rabbitmq:The following information may help to resolve the situation: INFO:kolla.common.utils.rabbitmq:The following packages have unmet dependencies: INFO:kolla.common.utils.rabbitmq: rabbitmq-server : Depends: erlang-base (< 1:26.0) but 1:26.0.1-1rmq1ppa1~ubuntu22.04.1 is to be installed or INFO:kolla.common.utils.rabbitmq: erlang-base-hipe (< 1:26.0) but it is not installable or INFO:kolla.common.utils.rabbitmq: esl-erlang (< 1:26.0) but it is not installable INFO:kolla.common.utils.rabbitmq: Depends: erlang-crypto (< 1:26.0) but 1:26.0.1-1rmq1ppa1~ubuntu22.04.1 is to be installed or INFO:kolla.common.utils.rabbitmq: esl-erlang (< 1:26.0) but it is not installable INFO:kolla.common.utils.rabbitmq: Depends: erlang-eldap (< 1:26.0) but 1:26.0.1-1rmq1ppa1~ubuntu22.04.1 is to be installed or INFO:kolla.common.utils.rabbitmq: esl-erlang (< 1:26.0) but it is not installable INFO:kolla.common.utils.rabbitmq: Depends: erlang-inets (< 1:26.0) but 1:26.0.1-1rmq1ppa1~ubuntu22.04.1 is to be installed or INFO:kolla.common.utils.rabbitmq: esl-erlang (< 1:26.0) but it is not installable INFO:kolla.common.utils.rabbitmq: Depends: erlang-mnesia (< 1:26.0) but 1:26.0.1-1rmq1ppa1~ubuntu22.04.1 is to be installed or INFO:kolla.common.utils.rabbitmq: esl-erlang (< 1:26.0) but it is not installable INFO:kolla.common.utils.rabbitmq: Depends: erlang-os-mon (< 1:26.0) but 1:26.0.1-1rmq1ppa1~ubuntu22.04.1 is to be installed or INFO:kolla.common.utils.rabbitmq: esl-erlang (< 1:26.0) but it is not installable INFO:kolla.common.utils.rabbitmq: Depends: erlang-parsetools (< 1:26.0) but 1:26.0.1-1rmq1ppa1~ubuntu22.04.1 is to be installed or INFO:kolla.common.utils.rabbitmq: esl-erlang (< 1:26.0) but it is not installable INFO:kolla.common.utils.rabbitmq: Depends: erlang-public-key (< 1:26.0) but 1:26.0.1-1rmq1ppa1~ubuntu22.04.1 is to be installed or INFO:kolla.common.utils.rabbitmq: esl-erlang (< 1:26.0) but it is not installable INFO:kolla.common.utils.rabbitmq: Depends: erlang-runtime-tools (< 1:26.0) but 1:26.0.1-1rmq1ppa1~ubuntu22.04.1 is to be installed or INFO:kolla.common.utils.rabbitmq: esl-erlang (< 1:26.0) but it is not installable INFO:kolla.common.utils.rabbitmq: Depends: erlang-ssl (< 1:26.0) but 1:26.0.1-1rmq1ppa1~ubuntu22.04.1 is to be installed or INFO:kolla.common.utils.rabbitmq: esl-erlang (< 1:26.0) but it is not installable INFO:kolla.common.utils.rabbitmq: Depends: erlang-syntax-tools (< 1:26.0) but 1:26.0.1-1rmq1ppa1~ubuntu22.04.1 is to be installed or INFO:kolla.common.utils.rabbitmq: esl-erlang (< 1:26.0) but it is not installable INFO:kolla.common.utils.rabbitmq: Depends: erlang-tools (< 1:26.0) but 1:26.0.1-1rmq1ppa1~ubuntu22.04.1 is to be installed or INFO:kolla.common.utils.rabbitmq: esl-erlang (< 1:26.0) but it is not installable INFO:kolla.common.utils.rabbitmq: Depends: erlang-xmerl (< 1:26.0) but 1:26.0.1-1rmq1ppa1~ubuntu22.04.1 is to be installed or INFO:kolla.common.utils.rabbitmq: esl-erlang (< 1:26.0) but it is not installable INFO:kolla.common.utils.rabbitmq:E: Unable to correct problems, you have held broken packages. INFO:kolla.common.utils.rabbitmq:

3 8

[tc] Technical Committee next weekly meeting on June 20, 2023
by Nikolla, Kristi 20 Jun '23

20 Jun '23

Hi all, This is a reminder that the next weekly Technical Committee meeting is to be held on Tuesday, June 20, 2023 at 1800 UTC on #openstack-tc on OFTC IRC. Please find below the agenda for the meeting: * Roll call * Follow up on past action items * Open Infra Summit retrospective * Gate health check * Open Discussion and Reviews ** https://review.opendev.org/q/projects:openstack/governance+is:open More information can be found and items proposed at the following link https://wiki.openstack.org/wiki/Meetings/TechnicalCommittee#Next_Meeting Thank you, Kristi Nikolla

1 0

[puppet] Summary of discussions at PTG Vancouver June 2023
by Takashi Kajinami 20 Jun '23

20 Jun '23

Hello, Thank you all for joining our PTG session ! It was really nice to meet some of the team members in person. The etherpad for the discussion can be found in the link below, but I'll share a summary of our discussions in this email. In case you have any questions/concerns then feel free to let me know. https://etherpad.opendev.org/p/vancouver-june2023-puppet-openstack - Status update - We share the status of each person. - Unfortunately all of the members attending the discussion have limited resources especially for development - *Agreement:* we focus on priorities and de-prioritize items which does not cause immediate problems/breackages - *Agreement: *we ensure we finish the prioritized items in a specific release to keep our maintenance simple - Puppet 8 support - We added unit/lint tests with Puppet 8 for early testing, but adding integration tests is currently blocked by some ruby dependencies not yet available for Ruby 3.1 which is required by Puppet 8. - All of the operating system versions do not provide Ruby 3.1 now - Puppet 7 EOL is not yet declared - *Agreement*: We leave this as non-priority for now and re-work on it once Ruby 3.1 is globally available - Adaptation to puppetlab-stdlib 9.0.0 - Some deprecated items were removed. We adapted our modules but are still waiting for update in the dependent modules - validate_legacy was deprecated and causes large warning no*w* - Functions from stdlib should be now namespace-d to avoid warnings after bump is done - *Agreement:* We prioritize replacing validate_legacy by typed parameters - *Agreement*: We pin stdlib to an older version for now but attempt to bump it early - Module modernizations - Typed parameters - Replacing validate_legacy needs to be prioritized now to adapt to puppetlab-stdlib 9.0.0 - Implementing type validations for openstack config options require further discussions. Handling of os_service_defualt would be the main topic we have to sort - We prefer consistent implementations for all openstack service modules, while we can attempt some changes early in a few "independent" modules such as extras, vswitch, qdr - *Agreement: *We de-prioritize implementing validations for config options - *Agreement: *We ensure implementations is distributed to all modules consistently in a single release - Hieradata - This is "modern" design pattern, and it's ideal to replace legacy params class by it - However we don't have urgent requirement to complete this work - We have to create the common structure for hieradata files maintained in each repositories - Some concerns have been raised mainly how we can pick up some values once this change is made - *Agreement: *We de-prioritize this work for now - *Agreement: *We can start with the flat files (pattern 1 in https://etherpad.opendev.org/p/puppet-hieradata-structure ) - *Agreement: *tkajinam will submit a few examples and we review how this impact the existing usage - *Agreement: *Similarly to typed parameters, we should coordinate this work to make the change consistently - Making distro/version specific logic selectable by parameters - This work is tightly related to the hieradata work - *Agreement: *We basically leave this work until the above hieradata work is completed, and de-prioritize this. - Branch retirements - We have multiple branches open now and aim to reduce number of branches - Red Hat is interested in keeping train open until 2023Q3 (tentative) and wallaby for some times for donwstream - Others do not have requirement to maintain old releases in EM status - *Agreement: *We aim to retire train/ussuri/branch after 2023Q3. Retiring further branches is subject to future discussions Thank you, Takashi Kajinami

2 1

[nova] Summary of discussions at Vancouver June 2023 (PTG + Forum meet&greet)
by Sylvain Bauza 19 Jun '23

19 Jun '23

Thanks folks that were joining our PTG but also our meet&greet forum session ! IT was again a productive week for us, as we were able to discuss with a lot of operators during around 4 hours (3.30' for the PTG and 30 mins for the forum session) Below you'll find the summary of all the topics we discussed during those hours but you can also look at the etherpads directly : * Nova meet&greet https://etherpad.opendev.org/p/nova-vancouver2023-meet-and-greet * Nova PTG sessions https://etherpad.opendev.org/p/vancouver-june2023-nova While there were unfortunately very few Nova maintainers and developers in both rooms, we've seen a packed room for the meet&greet and then at every hour of the PTG, we got at least one operator wanting to discuss with us. Can't tell how much I love this, hopefully we'll continue to discuss it between us afterwards. Now, let me tell you the summary : === Short survey at the meet&greet === * most of the operators (~21) in the meet&greet were either running Train or Yoga. Some of them were already running 2023.1 Antelope. Wow. * all of them were running libvirt but one running ironic driver. * using virtual GPUs/mdevs and setting flavors to define CPU usage were the two most in-use features (the next one is SR-IOV) * accordingly, the most needed missing quotas are for PCI devices, obviously. === Pain points at the meet&greet === * Availability zones : Basically, some operators use massively AZs and they want to get off some AZ (even if the instance is pinned) for maintenance reasons. We continued to discuss this usecase at the PTG (see below) * Update of userdata : we said this was coming with a proposed spec * Filtering flavors by a resource : this would require a nova spec * Hard affinity problems : we continued to discuss this at the PTG (see below) * Ceph backend for Nova compute and need for local ephemeral storage (case of GPUs) : this should be discussed in a spec * attach/detach issues with BDMs : we said this is a known issue, some bug report has to be filled for proper triaging * state of CVEs and the fact that old releases are still impacted : this is known and relates to the state of Extended Maintenance releases, which was addressed by another Forum session. === The PTG === * Affinity/Anti-affinity migration problems if hard policy : we explained the consensus we had at the Bobcat vPTG and a Bloomberg operator kindly volunteered to capture this agreement in a backlog spec (tl,dr: allow operators to violate the policy and let the servergroup API show the violation). More to come hopefully soon. * Exposing metrics : Some operator explained how the current use of Prometheus exporter is super slow since it's using the Nova APIs for gathering usage metrics. We proposed him to look into using Placement APIs for such case, he'll test and eventually come back to us if the existing Placement APIs aren't viable for him. * memfd-backed memory backing per instance : there are multiple concerns that need to be addressed in a spec. For example, we need to ensure the flavor extraspec is driver-agnostic, we need to care about the defaults and the potential upgrade concerns (like changing from anonymous to memfd) and how to interact with the existing hugepages feature in Nova. * using virtio9p instead of virtiofs for Manila shares : we discussed it intensively to eventually come up to the conclusion this wasn't worth the effort to implement it. Let's revisit this decision by the next PTG if no progress has been made on virtiofs migration feature gaps. * Manila/Nova cross-project PTG discussion on Manila share support : we discussed on the next Manila features (lock API and use of service roles). We agreed on the mandatory Nova configuration for service roles as a requirement for Manila shares usage. We also agreed on Manila storing the instance UUID as the semaphore for the lock API. FWIW, there was a packed table with 7 operators (all public clouds) *REALLY* interested in this feature [1]. That's it for Nova-related bits at Vancouver but other topics were worth being discussed. You can find the list of all discussed Forum sessions here : https://wiki.openstack.org/wiki/Forum/Vanvouver2023 I've found particular interest in the ExtendedMaintainance potential abandon discussion, OSC and SDK sessions, live-migration usecases and problems and a couple of others. I'd urge you to glance at all etherpads' contents. [1] https://photos.app.goo.gl/t1tSyk67GG6TRRW59 HTH, -Sylvain

1 0

[neutron] Bug deputy report (June-12 - June-18)
by Lajos Katona 19 Jun '23

19 Jun '23

Hey Neutrinos, I was the bug deputy last week, so I send the summary from last week. GATE ISSUES: these seems to be related to OVN version bump and https://review.opendev.org/c/openstack/neutron/+/883681: * Gate: Fuctional test_virtual_port_host_update failes recently (#link https://bugs.launchpad.net/neutron/+bug/2023634 ) ** *Unassigned* * [trunk ports] subport doesn't reach status ACTIVE (#link https://bugs.launchpad.net/neutron/+bug/2024160 ) ** *Unassigned* HIGH * n-d-r: Peering failing on mixed IPv4 + IPv6 updates (#link https://bugs.launchpad.net/neutron/+bug/2023632 ) ** Dr. Jens Harbott * [OVN] Hash Ring nodes removed when "periodic worker" is killed (#link https://bugs.launchpad.net/neutron/+bug/2024205 ) ** Lucas Alvares Gomes * Adding a static route to router returns internal server error (#link https://bugs.launchpad.net/neutron/+bug/2024251 ) ** *Unassigned* MEDIUM * [sqlalchemy-20] Remove redundant indexes of some tables (#link https://bugs.launchpad.net/neutron/+bug/2024044 ) ** Rodolfo Alonso * OVN: Removal of chassis results in unbalanced distribution of LRPs (#link https://bugs.launchpad.net/neutron/+bug/2023993 ) ** *Unassigned* * create_subnet policy allows users to create subnet in the shared networks (#link https://bugs.launchpad.net/neutron/+bug/2023679 ) ** Slawek Kaplonski Lajos Katona (lajoskatona)

1 0

[heat] Heat discussions at PTG Vancouver June 2023
by Takashi Kajinami 19 Jun '23

19 Jun '23

Hello, Thank you all who attended the PTG discussions last week at Vancouver. We were small but it was nice to meet/see you in person and discuss how we can improve our projects I'll share a summary of the PTG discussions and also a few more topics related to our projects, which were discussed during Forum sessions. Please let me know if you have any questions or concerns. PTG sessions: - We exchanged information about how we use heat downstream. Jonathan and Alan from Georgia Cyber Center explained their quite interesting usage to launch an lab environment for their end users. - There are still a number of resource properties not yet supported by Heat but we want to prioritize implementations according to actual needs. We suggested creating a storyboard story in case any user finds out any missing properties to cover their use case. - Jonathan shared a very nice demo about their visualizer of heat stacks[1], which gives more meaningful visualization based on resource types. We agreed this can replace the current implementation in heat dashboard. We agreed that we'll explore if we can integrate this and deprecate the current implementation. [1] https://gitlab.com/gacybercenter/open/openstack-top-graph Forum sessions: - In SRBAC sessions status of individual projects were shared. Heat is lagging behind now and we have to focus on completing step 1(removing system scope). - In TC/Community Leaders communication, we agreed we are setting a timeline to bump sqlalchemy to 2.0 (followup would be sent separately). We removed usage of sqlalchemy-migrate as the first step to adapt sqlalchemy 2.0 but we still need some work for full adoption. We first need to add some testing as was done in Neutron already. Thank you, Takashi Kajinami

1 0