January 2023 - openstack-discuss - lists.openstack.org

Nova libvirt/kvm sound device
by Zakhar Kirpichenko 06 Jan '23

06 Jan '23

Hi! I'd like to have the following configuration added to every guest on a specific host managed by Nova and libvirt/kvm: <sound model='bla'> <address type='pci' domain='0x0000' bus='0x00' slot='0x1b' function='0x0'/> </sound> When I add the device manually to instance xml, it works as intended but the instance configuration gets overwritten on instance stop/start or hard reboot via Nova. What is the currently supported / proper way to add a virtual sound device without having to modify libvirt or Nova code? I would appreciate any advice. Best regards, Zakhar

2 2

[designate] Implemeting PTR record restrictions
by Thomas Goirand 05 Jan '23

05 Jan '23

Hi, We implemented this scenario for our public cloud: https://docs.openstack.org/neutron/latest/admin/config-dns-int-ext-serv.htm… This is currently in production in beta-mode at Infomaniak's public cloud. We did that, because we want our customers to be able to set any domain name or PTR for the IPs they own. However, we discovered that there's no restriction on what zone customers can set. For example, if customer A owns the IP 203.0.113.9, customer B can do "openstack zone create 9.113.0.203.in-addr.arpa.", preventing customer A to set their PTR record. Is there currently a way to fix this? Or maybe a spec to implement the correct restrictions? What is the way to fix this problem in a public cloud env? Cheers, Thomas Goirand (zigo)

2 1

[designate] New project: designate-tlds
by Thomas Goirand 05 Jan '23

05 Jan '23

Hi, We wrote this: https://salsa.debian.org/openstack-team/services/designate-tlds The interesting code bits are in: https://salsa.debian.org/openstack-team/services/designate-tlds/-/blob/debi… What it does is download the TLD list from https://publicsuffix.org/list/public_suffix_list.dat using requests (with an optional proxy), compare it to the list of TLDs in Designate, and fix the difference. It's by default setup in a cron every week. Basically, it's just apt-get install designate-tlds, configure keystone_authtoken in /etc/designate-tlds/designate-tlds.conf and set dry_run=false, and you're done! Note I also wrote a patch for puppet-designate [1] to support it. Moving forward I see 2 solutions: 1- we continue to maintain this separately from Designate 2- our code gets integrated into Designate itself. Designate team: are you interested for option 2? Cheers, Thomas Goirand (zigo) [1] https://salsa.debian.org/openstack-team/puppet/puppet-module-designate/-/bl…

2 1

[nova][neutron][openstacksdk] Any API way to tell the difference for openstack ports created manually or automatically?
by hai wu 05 Jan '23

05 Jan '23

I could not find any API way to tell the difference between openstack ports created automatically when a new instance got created, and openstack ports manually created for port reservation purposes. There's 'preserve_on_delete' attribute in the openstack database for each vm instance, and if it is set to 'true', then the port was manually created, if not, then it was automatically created. But there's no API to retrieve this. Am I missing something? Hai

3 4

The Next OpenStack Release Name Is...
by Erin Disney 04 Jan '23

04 Jan '23

Hey everyone- Voting for the upcoming OpenStack B release name has ended and we have a winner... BOBCAT! Thanks to everyone who voted and helped us pick the next name. Thanks, Erin Erin Disney Event Marketing OpenInfra Foundation

1 0

[cinder][drivers] third-party CI for os-brick changes
by Brian Rosmaita 04 Jan '23

04 Jan '23

To all third-party CI maintainers, As you are aware, cinder third-party CI systems are required to run on all cinder changes. However, the os-brick library used in cinder CI testing is the latest appropriate *released* version of os-brick. Thus, it is possible for changes to be happening in os-brick development that might impact the functionality of your driver. If you aren't testing os-brick changes, you won't find out about these until *after* the next os-brick release, which is bad news all around. Therefore, at last week's cinder midcycle [0], the cinder project team agreed to require that cinder third-party CI systems run on all os-brick changes in addition to all cinder changes. This is a nice-to-have for the current (Zed) development cycle, but will be required in order for a driver to be considered 'supported' in the 2023.1 (Antelope) release [1]. If you have comments or concerns about this policy, please reply on the list to this email or put an item on the agenda [2] for the cinder weekly meeting. [0] https://etherpad.opendev.org/p/cinder-zed-midcycles [1] https://wiki.openstack.org/wiki/Cinder/tested-3rdParty-drivers#What_changes… [2] https://etherpad.opendev.org/p/cinder-zed-meetings

2 1

[nova] Do openstack support USB passthrough
by 韩光宇 04 Jan '23

04 Jan '23

Hi, all I want to ask if openstack support USB passthrough now? Or if I want the instance to recognize the USB flash drive on the host, do you have any suggestions? Thanks, Han

6 5

[TripleO] Tripleo-ci-centos-9-content-provider jobs are failing in check line
by Amol Kahat 04 Jan '23

04 Jan '23

Hello All, Centos-9 content provider jobs are failing in the check line. We are investigating failures related to build-containers[1]. Please hold your recheck until the issue[2] is fixed. [1] https://zuul.opendev.org/t/openstack/builds?job_name=tripleo-ci-centos-9-co… [2] https://bugs.launchpad.net/tripleo/+bug/2001626 Thanks -- *Amol Kahat* Software Engineer *Red Hat India Pvt. Ltd. Pune, India.* akahat(a)redhat.com B764 E6F8 F4C1 A1AF 816C 6840 FDD3 BA6C 832D 7715

1 0

Don't set 'py_modules=[]' unless you know what you're doing
by Stephen Finucane 04 Jan '23

04 Jan '23

Bit of PSA. I've a seen a number of tox4 fixup-related patches where people are adding the following to the 'setup.py' file: py_modules=[] If you're thinking about doing this, please stop. If you recently did this, consider proposing a patch to it again [*]. It's not doing what you think it is. This value should only be set for projects that do not actually distribute any Python code as part of their sdist (for example: puppet modules). Assuming you're not in this category, what you're actually seeing is a bug [1] which requires a fix in pbr [2]. This is a fix for pbr that means the pbr machinery will correctly function under tox4. This should be released very soon. Stephen [*] This obviously can't merge until the pbr fix is released. [1] https://github.com/tox-dev/tox/issues/2712 [2] https://review.opendev.org/c/openstack/pbr/+/869082

1 0

[ops] QOS on flavor breaking live migration from CentOS 7 to 8
by Jahson Babel 04 Jan '23

04 Jan '23

Hello, I'm trying to live migrate some VMs from CentOS 7 to Rocky 8. Everything run smoothly when there is no extra specs on flavors but things getting more complicated when those are fixed. Especially when using quota:vif_burst for QOS. I know that we aren't supposed to use this for QOS now but it's an old cluster and it was done that way at the time. So VMs kinda have all those specs tied to them. When live migrate a VM this show up in the nova's logs : driver.py _live_migration_operation nova.virt.libvirt.driver Live Migration failure: internal error: Child process (tc class add dev tapxxxxxxxx-xx parent 1: classid 1:1 htb rate 250000kbps ceil 2000000kbps burst 60000000kb quantum 21333) unexpected exit status 1: Illegal "burst" This bug cover the problem : https://bugs.launchpad.net/nova/+bug/1960840 So it's seems to be a normal behavior. Plus I forgot to mention that I'm on OpenStack Train version and the file mentioned in the launchpad is not present for this version. By using Rocky 8 I have to use an updated libvirt that won't accept the burst parameter we used to set. All available versions of libvirt on Rocky 8 have changed behavior concerning the burst parameter. I've done some testing to make things works including removing the extra_specs on flavors and in the DB, removing it through libvirt and trying to modify tc rules used by a VM but it didn't worked. I have not tried yet to patch Nova or Libvirt but I don't really know where to look for. The only thing that did work was to resize the VM to an identical flavor without the extra_specs. But this induce a complete reboot of the VM. I would like, if possible, to be able to live migrate the VMs which is quite easier. Is it possible to remove the extra_specs on the VMs and then live migrate ? Or should I just plan to resize/reboot all VMs without those extra_specs ? Any advise will be appreciated. Thank you for any help, Best regards. Jahson

2 2