November 2023 - openstack-discuss

[kolla-ansible] Not to install openvswitch on sriov_agent compute nodes
by Satish Patel 09 Nov '23

09 Nov '23

Folks, I have pure sriov compute nodes where I don't want to deploy openvswitch because SRIOV agents do pass through PCI bugs to VM directly. Currently all my SRIOV compute nodes have two agents running. neutron_openvswitch_agent neutron_sriov_agent I don't think "neutron_openvswitch_agent" has any role on sriov compute nodes. If I want to tell kolla-ansible not to deploy neutron_openvswitch_agent on X compute node then how do I tell. Are there any easy ways to turn it off? ~S

1 0

hi
by Tecstim 09 Nov '23

09 Nov '23

1 0

[kolla-ansible] sriov setup
by Satish Patel 09 Nov '23

09 Nov '23

Folks, I am following this guide to deploy sriov compute with kolla-ansible (I am not using kayobe) - https://www.stackhpc.com/sriov-kayobe.html In the above doc last section neutron sriov agent, I am using the same code but those variables are not reflecting. It just prints everything as it is. # cat /etc/kolla/host_vars/os1-bos-sriov-comp-001.yml neutron_sriov_physnet_mappings: physnet1: eno49 # cat /etc/kayobe/kolla/config/neutron/sriov_agent.ini {% raw %} [sriov_nic] physical_device_mappings = {% for dev, physnet in sriov_physnet_mappings.items() %}{{ (loop.index0 > 0)|ternary(',','') }}{{ physnet }}:{{ dev }}{% endfor %} exclude_devices = {% endraw %} After running deploy it just prints the entire file as its in sriov_agent.ini file instead of proper values of variable. Does kolla-ansible support the above code?

2 2

[ptls] [tc] 2023 OpenStack Deployment Data
by Allison Price 09 Nov '23

09 Nov '23

Hi everyone, Apologies for sending this during the PTG as I intended to send this prior, but below is a link to the anonymized data including responses to many project or TC contributed questions. I have removed a significant number of fields to preserve the anonymity of the organizations, but if there is a particular data point that would help your team, please let me know. Cheers, Allison https://docs.google.com/spreadsheets/d/1ehlabuqOnNK4M7xtN1GXvhLoeHn4JBaISih…

2 1

[ironic] Hold approvals for various gate breakages
by Jay Faulkner 08 Nov '23

08 Nov '23

Hey Ironicers, We have a couple of gate unhappinesses: - bifrost gate is busted until this lands: https://review.opendev.org/c/openstack/bifrost/+/900487 - Ironic gate is busted until the new oslo.utils is released and added to requirements (we vote on a sqlalchemy 2x job) -- https://review.opendev.org/c/openstack/releases/+/900382 appears to be the next change in that chain. Just ensuring folks know what's going on! Please avoid approving changes to these repos until the issues are resolved. Thanks, Jay Faulkner Ironic PTL

1 0

[ironic] 2024.1 vPTG Notes & Work Items
by Jay Faulkner 08 Nov '23

08 Nov '23

Hi all, In typical Ironic tradition, we've documented the outcome of the PTG in a spec: https://specs.openstack.org/openstack/ironic-specs/priorities/2024-1-workit… -- please review it for information on work we plan on at least trying to start this cycle :). For full notes, please see the etherpad: https://etherpad.opendev.org/p/ironic-ptg-october-2023. Thanks, Jay Faulkner Ironic PTL

1 0

[FOSDEM] Call for participation: Virtualization and Cloud infrastructure Room at FOSDEM 2024
by Piotr Kliczewski 08 Nov '23

08 Nov '23

We are excited to announce that the call for proposals is now open for the Virtualization and Cloud infrastructure devroom at the upcoming FOSDEM 2024, to be hosted on February 3rd 2024. This devroom is a collaborative effort, and is organized by dedicated folks from projects such as OpenStack, Xen Project, KubeVirt, QEMU, KVM, and Foreman. We would like to invite all those who are involved in these fields to submit your proposals by December 8th, 2023. About the Devroom The Virtualization & IaaS devroom will feature session topics such as open source hypervisors or virtual machine managers such as Xen Project, KVM, bhyve and VirtualBox as well as Infrastructure-as-a-Service projects such as KubeVirt, Apache CloudStack, OpenStack, QEMU and OpenNebula. This devroom will host presentations that focus on topics of shared interest, such as KVM; libvirt; shared storage; virtualized networking; cloud security; clustering and high availability; interfacing with multiple hypervisors; hyperconverged deployments; and scaling across hundreds or thousands of servers. Presentations in this devroom will be aimed at developers working on these platforms who are looking to collaborate and improve shared infrastructure or solve common problems. We seek topics that encourage dialog between projects and continued work post-FOSDEM. Important Dates Submission deadline: 8th December 2023 Acceptance notifications: 10th December 2023 Final schedule announcement: 15th December 2023 Devroom: 3rd February 2024 Submit Your Proposal All submissions must be made via the Pretalx event planning site[1]. It is a new submission system so you will need to create an account. If you submitted proposals for FOSDEM in previous years, you won’t be able to use your existing account. During submission please make sure to select Virtualization and Cloud infrastructure from the Track list. Please fill out all the required fields, and provide a meaningful abstract and description of your proposed session. Submission Guidelines We expect more proposals than we can possibly accept, so it is vitally important that you submit your proposal on or before the deadline. Late submissions are unlikely to be considered. All presentation slots are 30 minutes, with 20 minutes planned for presentations, and 10 minutes for Q&A. All presentations will be recorded and made available under Creative Commons licenses. In the Submission notes field, please indicate that you agree that your presentation will be licensed under the CC-By-SA-4.0 or CC-By-4.0 license and that you agree to have your presentation recorded. For example: "If my presentation is accepted for FOSDEM, I hereby agree to license all recordings, slides, and other associated materials under the Creative Commons Attribution Share-Alike 4.0 International License. Sincerely, <NAME>." In the Submission notes field, please also confirm that if your talk is accepted, you will be able to attend FOSDEM and deliver your presentation. We will not consider proposals from prospective speakers who are unsure whether they will be able to secure funds for travel and lodging to attend FOSDEM. (Sadly, we are not able to offer travel funding for prospective speakers.) Code of Conduct Following the release of the updated code of conduct for FOSDEM, we'd like to remind all speakers and attendees that all of the presentations and discussions in our devroom are held under the guidelines set in the CoC and we expect attendees, speakers, and volunteers to follow the CoC at all times. If you submit a proposal and it is accepted, you will be required to confirm that you accept the FOSDEM CoC. If you have any questions about the CoC or wish to have one of the devroom organizers review your presentation slides or any other content for CoC compliance, please email us and we will do our best to assist you. Questions? If you have any questions about this devroom, please send your questions to our devroom mailing list. You can also subscribe to the list to receive updates about important dates, session announcements, and to connect with other attendees. See you all at FOSDEM! [1] <https://penta.fosdem.org/submission/FOSDEM17> https://pretalx.fosdem.org/fosdem-2024/cfp [2] virtualization-devroom-manager at fosdem.org

1 0

The difference between kolla-ansible deploy and kolla-ansible upgrade
by bryansoong21＠gmail.com 08 Nov '23

08 Nov '23

Hello team, I have noticed this for the kolla operation documentation: https://docs.openstack.org/kolla-ansible/zed/user/operating-kolla.html This procedure is for upgrading from series to series, not for doing updates within a series. Inside a series, it is usually sufficient to just update the kolla-ansible package, rebuild (if needed) and pull the images, and run kolla-ansible deploy again. Please follow release notes to check if there are any issues to be aware of. We have two different kolla images and the OpenStack version are all Zed, while one container base image si Rocky 9.2 and another is CentOS 9. Based on kolla documentation, we should use kolla-ansible deploy if we want to switch different kolla images. We also tried to run kolla-ansible upgrade and all VMs have been stopped, just wondering what's the difference when running these two commands and why the upgrade shutdown all the VMs? Thanks

1 0

[ironic][nova] A few notes about the Ironic<>Nova driver
by Jay Faulkner 08 Nov '23

08 Nov '23

Hey all, Julia Kreger, John Garbutt, and myself met today in a trio-coding session to review the Ironic virt driver in Nova, as a follow-up to some of the concerns we developed when sharding support was reverted in Bobcat. I wanted to ensure both communities knew about what we discussed. Notes were taken in the Ironic PTG etherpad starting at line 654. *Fix a Bug in list_instances/list_instance_uuids* We found a bug around list_instances and list_instance_uuids in the Ironic driver, and tracked that its main impact was performance. The bug has been documented in https://bugs.launchpad.net/nova/+bug/2043036 and we will work to ensure it's resolved this cycle. *Completing the Partially completed ironicclient -> SDK migration* The Ironic virt driver in Nova began migrating to openstacksdk, but this migration was not completed. This left the driver in a strange, in-between state which made it much easier to misunderstand microversion interactions. Even more unfortunately, we even have places where we're checking the available microversion using ironicclient, then making the actual call with openstacksdk (which may negotiate another microversion altogether). Completing this migration will be a priority; and we will attempt to complete it, barring unforeseen technical issues, before re-proposing the sharding changes. *Sharding re-proposal and testing* For sharding's re-proposal in Caracal, we discussed some details around validation and testing. Primarily, we want to ensure Ironic's sharding API has tempest test coverage, and that we have more complex testing coverage around the integrated Nova/Ironic sharding case, for when it's reproposed. As sharding will be the primary scaling method for integrated Ironic<>Nova users, it's important it's exercised well in our CI. *Pass more metadata to Ironic at provisioning* Ironic implemented several features around RBAC recently, but those have not been available for users of Nova-integrated Ironic installations. We want to change that. John proposed a blueprint, https://blueprints.launchpad.net/nova/+spec/ironic-guest-metadata , which we hope to be approved as specless, which would make the metadata set in Ironic's instance_info more consistent with what is set on a libvirt guest. With that metadata, Ironic developers could make the "automatic_lessee" feature work with Nova and unlock RBAC-goodness for users of fully integrated Ironic<>Nova clouds and Ironic deployers have a new tool they can use to troubleshoot failures using instance_info from Ironic's API. Thanks for reading. This is just a summary of our discussion and links to some artifacts from it; obviously none of this is going to happen until the blueprints are approved, code is written and lands -- but we thought the community might appreciate hearing about what we're thinking about ahead of time. Thanks, Jay Faulkner Ironic PTL

1 1

Cinder Bug Report 2023-11-08
by Jon Bernard 08 Nov '23

08 Nov '23

Hello Argonauts, Cinder Bug Meeting Etherpad <https://etherpad.opendev.org/p/cinder-bug-squad-meeting> Undecided - NetApp doesn't update the backend LUN name during generic migration <https://bugs.launchpad.net/cinder/+bug/2042662> - Status: New Thanks, -- Jon

1 0