February 2023 - openstack-discuss

[ironic] Is there a ramdisk image of aarch64 architecture available for download
by 韩光宇 14 Feb '23

14 Feb '23

Hello, I saw that we can get ramdisk image from tarballs.openstack.org[1] in ironic doc[2]. I would like to ask whether all the above are of amd64 architecture. Where can I download the ramdisk image of aarch64 architecture？ When I built aarch64 image locally, It's always failed. ```shell # export ARCH=aarch64 # ironic-python-agent-builder fedora ... mount: /tmp/tmp.1yEQhatS1X/mnt: wrong fs type, bad option, bad superblock on /dev/mapper/loop0p5, missing codepage or helper program, or other error. # ironic-python-agent-builder centos ... 2023-02-12 14:15:02.361 | dib-run-parts Running /tmp/in_target.d/pre-install.d/01-00-centos-python3 2023-02-12 14:15:05.204 | CentOS Linux 8 - AppStream 17 B/s | 38 B 00:02 2023-02-12 14:15:05.209 | Error: Failed to download metadata for repo 'appstream': Cannot prepare internal mirrorlist: No URLs in mirrorlist # ironic-python-agent-builder ubuntu ... 2023-02-12 14:15:31.623 | Fetching Base Image 2023-02-12 14:15:31.657 | % Total % Received % Xferd Average Speed Time Time Time Current 2023-02-12 14:15:31.657 | Dload Upload Total Spent Left Speed 0 0 0 0 0 0 0 0 --:--:-- --:--:-- --:--:-- 0 2023-02-12 14:15:32.388 | Server copy has not changed. Using locally cached https://cloud-images.ubuntu.com/focal/current/SHA256SUMS 2023-02-12 14:15:32.422 | % Total % Received % Xferd Average Speed Time Time Time Current 2023-02-12 14:15:32.422 | Dload Upload Total Spent Left Speed 100 286 100 286 0 0 418 0 --:--:-- --:--:-- --:--:-- 418 2023-02-12 14:15:33.110 | Server returned an unexpected response code. [404] ``` [1]: https://tarballs.opendev.org/openstack/ironic-python-agent/dib/files/ [2]: https://docs.openstack.org/ironic/latest/install/deploy-ramdisk.html

5 5

Issues with virsh XML changing disk type after Nova live migration
by Budden, Robert M. (GSFC-606.2)[InuTeq, LLC] 14 Feb '23

14 Feb '23

Hello Community, We’ve hit a rather pesky bug that I’m hoping someone else has seen before. We have an issue with Nova where a set of Cinder backed VMs are having their XML definitions modified after a live migration. Specifically, the destination host ends up having the disk type changed from ‘qcow2’ to ‘raw’. This ends up with the VM becoming unbootable upon the next hard reboot (or nova stop/start is issued). The required fix ATM is for us to destroy the VM and recreate from the persistent Cinder volume. Clearly this isn’t a maintainable solution as we rely on live migration for patching infrastructure. Any thoughts, ideas, would be most welcome. Gory details are below. Here’s the key details we have: * Nova boot an instance from the existing volume works as expected. * After live migration the ‘type’ field in the virsh XML is changed from ‘qcow2’ -> ‘raw’ and we get a ‘No bootable device’ from the VM (rightly so) * After reverting this field automatically (scripted solution), a ‘nova stop’ followed by a ‘nova start’ yet again rewrites the XML with the bad type=’raw’. * It should be noted that before a live migration is performed ‘nova stop/start’ functions as expected, no XML changes are written to the virsh definition. * Injecting additional logs into the python on these two hosts I’ve narrowed it down to ‘bdm_info.connection_info’ on the destination end is choosing the ‘raw’ parameter somehow (I’ve only got so far through the code at this time). The etree.XMLParser of the source hypervisors XML definition is properly parsing out ‘qcow2’ type. Some background info: * We’re currently running the Wallaby release with the latest patches. * Hybrid OS (Stream8 /Rocky 8) on underlying hardware with the majority of the Control Plane Stream aside from our Neutron Network Nodes. Computes are roughly split 50/50 Stream/Rocky. * The Cinder volumes that experience this were copied in from a previous OpenStack cloud (Pike/Queens) on the backend. I.e. NetApp snapmirror, new bootable Cinder volume created on the backend, and an internal NetApp operation for a zero copy operation over the backing Cinder file. * Other Cinder volumes that don’t exhibit this to mostly be in ‘raw’ format already (we haven’t vetted every single bootable Cinder volume yet). * We’ve noticed these Cinder volumes lack some metadata fields that other Cinder volumes create by Glance have (more details below). Ideas we’ve tried: * Adjusting settings on both computes for ‘use_cow_images’ and ‘force_raw_images’ seem to have zero effect. * Manually setting the Cinder metadata parameters to no avail (i.e. openstack volume set --image-property disk_format=qcow2). Thanks! -Robert

3 5

[TripleO] Integrating external Graylog with openstack TripleO wallaby
by Kushagra Gupta 14 Feb '23

14 Feb '23

Hi Team, We have a tripleO environment. Our tripleO environment consists of 2 compute nodes, 3 controller nodes, and 1 undercloud node. TripleO Release: Wallaby We want to integrate the Graylog server with the tripleO openstack. Does tripleO support this integration? If so, could anyone please share some sources from where we can do the same? Thanks and Regards, Kushagra Gupta DISCLAIMER: This electronic message and all of its contents, contains information which is privileged, confidential or otherwise protected from disclosure. The information contained in this electronic mail transmission is intended for use only by the individual or entity to which it is addressed. If you are not the intended recipient or may have received this electronic mail transmission in error, please notify the sender immediately and delete / destroy all copies of this electronic mail transmission without disclosing, copying, distributing, forwarding, printing or retaining any part of it. Hughes Systique accepts no responsibility for loss or damage arising from the use of the information transmitted by this email including damage from virus.

1 0

[election][ptl][Kuryr] Candidacy for 2023.2 Bobcat
by Roman Dobosz 14 Feb '23

14 Feb '23

Hello, I would like to announce my candidacy to be the Kuryr PTL for the next Bobcat cycle. I've been Kuryr contributor since the Ussuri release and became core reviewers member at the end of Victoria cycle. I'm also the PTL since Antelope cycle. In the upcoming Bobcat cycle, I'd like to focus on Kuryr maintanance, stability and compatibility with upcoming Kubernetes release. Thanks, Roman Dobosz (gryf)

1 0

Replaying pcap captured network traffic into OpenStack Victoria
by Felipe Mogollon 13 Feb '23

13 Feb '23

Hello, I have an OpenStack Victoria with a controller+network+compute node plus a compute node. Both nodes are working fine and I have no problem with network traffic. If I try to replay some previously captured traffic from a tcpdump pcap file no traffic at all comes through qrouters. I have tried replaying network traffic from external machine to OpenStack and from OpenStack to external and internal machines and I have the same negative results in all cases. When I replay traffic from an external computer to an instance insde OpenStack I noticed that incoming packets go to the external interface of the qrouter but don't go passthrough to the internal interface from the qrouter. I have tried replaying traffic with scapy and tcpreplay and I get the same results in both cases. Any ideas? Thanks -- <https://www.vicomtech.org> Juan Felipe Mogollón Rodríguez Researcher | Investigador fmogollon(a)vicomtech.org +[34] 943 30 92 30 Digital Media <https://www.linkedin.com/company/vicomtech> <https://www.youtube.com/user/VICOMTech> <https://twitter.com/@Vicomtech> member of: <https://graphicsvision.ai/> La información que contiene este mensaje y sus adjuntos son confidenciales y están dirigidos exclusivamente a sus destinatarios. Si recibe este mensaje por error, se ruega nos lo comunique y proceda a su borrado. The information contained in this electronic message is intended only for the personal and confidential use of the recipients designated in the original message. If you have received this communication in error, please notify us immediately by replying to the message and deleting it from your computer.

1 0

[election][ptl][Octavia] Candidacy for 2023.2 Bobcat
by Gregory Thiemonge 13 Feb '23

13 Feb '23

Hi, I would like to announce my candidacy for Octavia PTL for the Bobcat release. I have been PTL since the Xena cycle and I want to continue to contribute to this role. For the Bobcat release I would like to focus on important internal tasks, such as completing the SQLAlchemy 2 migration and moving from python-neutronclient to openstacksdk. I would like also to improve the amphorav2 driver by analyzing and optimizing the SQL queries (we know we're doing many DB calls). Thanks for your consideration, Gregory Thiemonge (gthiemonge)

1 0

Live migration to host with advanced cpu results in instance inheriting incorrect cpu_model, even when overridden in nova.conf
by Andy Speagle 13 Feb '23

13 Feb '23

Hey Folks, We have a number of nodes in our openstack cluster who have the same family CPU (IvyBridge-IBRS) ... and one advanced CPU (Broadwell-IBRS). We have set the cpu_mode to custom and overridden the cpu_model to IvyBridge-IBRS so that all of the hosts would be compatible. This seems to work for instances started on the advanced host... we can live migrate off of the host. But... when we live migrate instances TO the advanced host... they seem to inherit the wrong CPU type. Example: If I live migrated onto the advanced host and then try to live migrate off of it... nova-compute logs on the older host throw: Error: Migration pre-check error: Unacceptable CPU info: CPU doesn't have compatibility. And the output clearly shows that it thinks it was launched on the Broadwell CPU: Instance launched has CPU info: {"arch": "x86_64", "model": "Broadwell- IBRS", "vendor": "Intel" ... With that instance on the advanced host, if I restart it... magically it comes up with the correct cpu_model and can be live migrated off... We're running ussuri ... does anyone know if this is known behavior? Could I have a misconfiguration somewhere? Thanks. -- Andy Speagle

1 0

[election][tc] TC candidacy for 2023
by Brian Rosmaita 13 Feb '23

13 Feb '23

Hello OpenStack Community, I am declaring my candidacy for a second term on the Technical Committee. I've been working on OpenStack since Folsom and currently serve as a core reviewer for the Glance and Cinder projects. In the past, I've been PTL of Glance and Cinder, and I am just now completing my first term on the Technical Committee. As I said last time, I don't have an agenda other than to represent active technical contributors to OpenStack and to participate in the TC in a manner consistent with its charter. Additionally, during my first term, I have been working with the OpenStack i18n SIG to refresh the translations infrastructure, and I would like to continue that work into the Bobcat development cycle. Thank you for considering my candidacy for the OpenStack Technical Committee. - Brian Rosmaita (rosmaita)

1 0

[publiccloud-sig] Reminder - next meeting Feb 15th - 0800 UTC
by Felix Kronlage-Dammers 13 Feb '23

13 Feb '23

Hi everyone, The next meeting of the Public Cloud SIG is on February 15th (this wednesday) at 0800 UTC. We meet on IRC in #openstack-operators. See also here for all other details: https://wiki.openstack.org/wiki/PublicCloudSIG read you on wednesday! felix

1 0

[election][ptl][openstack-ansible] Candidacy for 2023.2 Bobcat
by Dmitriy Rabotyagov 13 Feb '23

13 Feb '23

Hello everyone! I would like to announce my candidacy for the role of PTL of OpenStack-Ansible during the Bobcat/2023.2 cycle. I have been serving as the OpenStack PTL for quite a while now so with announcing my candidacy I also want to encourage other active contributors to participate in elections for keeping a healthy community and plurality of opinions in the project leadership. For the next cycle I would like to focus project development on: * Implementing SLURP upgrades both in terms of CI testing and upgrade script adjustment * Continue integration and improvement of PKI role with services * Keep up with latest supported versions of infrastructure software, like MariaDB, RabbitMQ and Ansible * Have progress on better functional testing of different scenarios for roles * Improve timing for our releases by decreasing the gap between OpenStack coordinated release and OSA trailing one. Thank you for your consideration!

1 0