- openstack-discuss - lists.openstack.org

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

05 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 05 Jan '23

05 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 韩光宇 05 Jan '23

05 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

Re: openstack-discuss Digest, Vol 51, Issue 6
by Kerem Çeliker 04 Jan '23

04 Jan '23

Hello Stephen, Yes, OpenStack does support USB passthrough. You can pass through USB devices to instances running in OpenStack by using the nova.virt.libvirt.vif.LibvirtGenericVIFDriver driver and the qemu:commandline option in the nova.conf file. Best, Kerem Çeliker keremceliker.medium.com Sent from my iPhone > On 4 Jan 2023, at 02:25, openstack-discuss-request(a)lists.openstack.org wrote: > > Send openstack-discuss mailing list submissions to > openstack-discuss(a)lists.openstack.org > > To subscribe or unsubscribe via the World Wide Web, visit > https://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-discuss > > or, via email, send a message with subject or body 'help' to > openstack-discuss-request(a)lists.openstack.org > > You can reach the person managing the list at > openstack-discuss-owner(a)lists.openstack.org > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of openstack-discuss digest..." > > > Today's Topics: > > 1. Re: [nova] Do openstack support USB passthrough (Sean Mooney) > 2. Re: [ops] QOS on flavor breaking live migration from CentOS 7 > to 8 (Sean Mooney) > 3. Re: [cloudkitty] Instances billing based on tags (Satish Patel) > 4. [nova][keystone] workload identity? (Mohammed Naser) > 5. Re: [cloudkitty] Instances billing based on tags > (Rafael Weing?rtner) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Tue, 03 Jan 2023 19:03:23 +0000 > From: Sean Mooney <smooney(a)redhat.com> > To: Stephen Finucane <stephenfin(a)redhat.com>, ??? > <hanguangyu2(a)gmail.com>, openstack-discuss > <openstack-discuss(a)lists.openstack.org> > Subject: Re: [nova] Do openstack support USB passthrough > Message-ID: > <765850d1c170a510d34dafb4253ab97528829351.camel(a)redhat.com> > Content-Type: text/plain; charset="UTF-8" > >> On Tue, 2023-01-03 at 14:54 +0000, Stephen Finucane wrote: >>> On Mon, 2022-12-26 at 10:04 +0000, ??? wrote: >>> 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 >> >> This isn't supported in nova and probably never will be. The closest you can get >> is to passthrough an entire USB controller as suggested by this blog [1], but >> that's really a hack and I 100% would not use it in production. > > ya so we have discussed usb passthough supprot a few times and its somethign nova could add but there has > neither been the demand or desire to add it stongly enough in the core team to actully do it. > > the shorted path to enableing usb passthoug would likely be to add support to cyborg and then add support for that ot nova. > i am perhaps the most open of the nova cores to supporting usb passthough since i have wanted to add it in the past but > if we were to support it it would have to be similar to howe we support pci passhtough. static provisioning and likely only of > stateless devices which rules out usb falsh drives. > > usb gps recivers for precision time stamping was one of the usecause raised in the past which we were somewhat open too > the other was usb programmers/debuggers forh cases when vms where used in industral test and automation workflows. > > as stephen said the only way to do it today is to piggyback on pci passthough and passhtough a usb contoller not a single device. > > if we were to ever support this in nova directly i would proably extend the pci tracker or support other buses like usb or use the generic > resouce table created for persistent memory to model the devices. in eitehr case we would want this capablity to be placement native from the > start if we added this capablity so it would be more and less work then you might imagine to do this right. > less work if we maintain the requirement for statless devices only (ie no usb flash drives) more if you also need to handel multi tenancy and > move operation include data copying, erasure and or encypetion. > > i would not expect this to change in the next few release unless multiple operators provide feedback that this is a broadly deired capablity. > with out a top level generic device api for mutple type of devices (vgpu, usb, pci) that was decoupled form the flaovr or an abstraction like > the cyborg device-profile or pci alias it is hard to see a clean way to model this in our api. that is why enabling it in cyborg and then extneding > nova ot support device profiles with a device type of usb is the simplar solution form a nova perspecitve but that is non trivial from an operational > perspective as you requrie cyborg to utilise the feature. doing it via a usb_alias in the flavor has all the draw backs of the pci_alias, static > configuration that must match on all compute nodes and futher proliferation of flavor explostion. this is one of the reasons we have not added this in > the past. the work to do it in the libvirt driver would not be hard but the maintaince and operational overhead of using it for operators is non > trivial. > >> >> Stephen >> >> [1] https://egallen.com/openstack-usb-passthrough/ >> >> > > > > > ------------------------------ > > Message: 2 > Date: Tue, 03 Jan 2023 19:20:50 +0000 > From: Sean Mooney <smooney(a)redhat.com> > To: Jahson Babel <jahson.babel(a)cc.in2p3.fr>, > openstack-discuss(a)lists.openstack.org > Subject: Re: [ops] QOS on flavor breaking live migration from CentOS 7 > to 8 > Message-ID: > <b0f13cde177cd8b5f7e6e5b20445decab7dbc8b8.camel(a)redhat.com> > Content-Type: text/plain; charset="UTF-8" > > hi yes this is a know issue. > > so the simple answer is resize all affected vms instead of live migrating them > the longer answer is we have been dissing this internally at redhat on and off for > some time now. > https://bugs.launchpad.net/nova/+bug/1960840 is one example where this happens. > > there is another case for the cpu based quotas that happens when going form rhel/centos 8->9 > basically in the 8->9 change the cgroups implemantion changes form v1 to v2 > https://bugzilla.redhat.com/show_bug.cgi?id=2035518 > > when adressing that we did not have a good universal solution for instnace that hardcoded a value that > was incompatible with the cgroups_v2 api in the kernel except resize. > > in https://review.opendev.org/c/openstack/nova/+/824048/ we removed automatically adding the > cpu_shares cgroup option to enable booting vms with more then 8 cpus > > we did not come up with any option other then resize for the other quotas that were in a similar situation. > the one option that we considerd possibel to do was extend nova-mange to allow the embeded flaour to be updated > this would be similar to what we did to enable the image property to be modifed for chaing machine types. > > https://docs.openstack.org/nova/latest/cli/nova-manage.html#image-property-… > > we didcussed at the time that while we did not want to allow falvor extra specs to be modifed we might recondier that > if the quota issue forced our hand or we had a similar need due to foces beyond our contol. i.e. we needed to provide a way beyond > resize e.g. due ot operating system changes. what make image properties and flavor extra spec different is that image proerties can > only be updated by rebuild which is a destructive operation. extra specs are upsted by resize which is not a destructive operation. > that is one of the reasons we have special considertion to image properties and did not do the same for extra specs. > > if we allow the same for flavor extra specs you would still have to stop the instance, make the change and then migrate the instnace > resize automates that so it is generall a better fit. we were also conceren that adding it to nova manage would result in it being abused > to modify instnace in ways that were either invalid for the host(changing the numa toplogy, adding traits/resouce request not trackedcxd in placemnt) > or otherwise break the instnace in weird ways. that could happen via image properites too but its less likely. > > > >> On Tue, 2023-01-03 at 17:25 +0100, Jahson Babel wrote: >> 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 > > > > > ------------------------------ > > Message: 3 > Date: Tue, 3 Jan 2023 15:23:19 -0500 > From: Satish Patel <satish.txt(a)gmail.com> > To: Rafael Weing?rtner <rafaelweingartner(a)gmail.com> > Cc: OpenStack Discuss <openstack-discuss(a)lists.openstack.org> > Subject: Re: [cloudkitty] Instances billing based on tags > Message-ID: > <CAPgF-fpGyO-Z8bt7KMdP7CAhi9kne3136ptoE+8coURyFwi7yw(a)mail.gmail.com> > Content-Type: text/plain; charset="utf-8" > > Wow! very interesting, I will poke around and see how it's feasible. Very > curious how it will represent that data in horizon UI. Currently I am > seeing rates based on project_id so assuming it will show based on > customer_id. correct? > > > On Tue, Jan 3, 2023 at 8:13 AM Rafael Weing?rtner < > rafaelweingartner(a)gmail.com> wrote: > >> You can do that. Basically, you can start collecting those attributes you >> want for billing (e.g. tags) via Ceilometer dynamic pollster (that is the >> easiest way to achieve this). Then, you need to configure the resource type >> in Gnocchi to store this extra attribute, and of course, configure >> CloudKitty to collect/use it. Both in the metrics.yml and then in the >> hashmap or Pyscript rules. >> >>> On Mon, Jan 2, 2023 at 11:01 PM Satish Patel <satish.txt(a)gmail.com> wrote: >>> >>> Folks, >>> >>> We have an AWS project and in a single project we run multiple customers >>> so for billing we use tags. In short every vm instance has a tag (customer >>> name) and that way we can produce bills for each customer. >>> >>> Recently I am playing with openstack cloudkitty and it works with >>> standard cases like project based billing. But does it support tags based >>> billing just similar to what i have explained in the above aws example? >>> >>> >>> >> >> -- >> Rafael Weing?rtner >> >

1 0

[cinder] Bug Report from 01-04-2023
by Sofia Enriquez 04 Jan '23

04 Jan '23

This is a bug report from 12-21-2022 to 01-04-2023. Agenda: https://etherpad.opendev.org/p/cinder-bug-squad-meeting ----------------------------------------------------------------------------------------- High - https://bugs.launchpad.net/cinder/+bug/2000436 "250 unit test failures under Python 3.11." Unassigned. - https://bugs.launchpad.net/cinder/+bug/2000489 "Dell Powerstore won't delete volume when storage migrate." Unassigned. Medium - https://bugs.launchpad.net/cinder/+bug/2000724 "cinder should not send external events when extending online is called by glance." In Progress. Cheers, -- Sofía Enriquez she/her Software Engineer Red Hat PnT <https://www.redhat.com> IRC: @enriquetaso @RedHat <https://twitter.com/redhat> Red Hat <https://www.linkedin.com/company/red-hat> Red Hat <https://www.facebook.com/RedHatInc> <https://www.redhat.com>

1 0

2023 PTGs + Virtual Team Signup
by Kendall Nelson 04 Jan '23

04 Jan '23

Hello Everyone! The next PTG on the calendar will be our usual virtual format and it will take place March 27 -31 right after the 2023.1 release. The project signup survey is already ready to go! If your team is interested in participating, sign them up here[1]! Registration is also open now[2] We have also heard many requests from the contributor community to bring back in person events and also heard that with global travel reduction, it would be better travel wise for the community at large to combine it with the OpenInfra Summit[3]. So, an in-person PTG will take place Wednesday and Thursday! June 14 -15th. OpenInfra Summit registration will be required to participate, and contributor pricing and travel support[4] will be available. We will also be planning another virtual PTG in the latter half of the year. The exact date is still being finalized. This will give you three opportunities to get your team together in 2023: two virtual and one in-person. - Virtual: March 27-31 - In- Person: June 14-15 collocated with the OpenInfra Summit - Virtual: TBD, but second half of the year As any project in our community, you are free to take advantage of all or some of the PTGs this coming year. I, for one, hope to see you and your project at as many as make sense for your team! To make sure we are as inclusive as possible I will continue to encourage team moderators to write summaries of their discussions to gather and promote after the events as well. Stay tuned for more info as we get closer, but the team signup survey[1] has opened for the first virtual PTG and is ready for you! -Kendall (diablo_rojo) [1] https://openinfrafoundation.formstack.com/forms/march2023_vptg_survey [2] https://openinfra-ptg.eventbrite.com [3]https://openinfra.dev/summit/vancouver-2023 [4] https://openinfrafoundation.formstack.com/forms/openinfra_tsp

1 1

[all][tc] Technical Committee next weekly meeting on 2023 Jan 4 at 1600 UTC
by Ghanshyam Mann 04 Jan '23

04 Jan '23

Hello Everyone, The technical Committee's next weekly meeting is scheduled for 2023 Jan 4, at 1600 UTC. If you would like to add topics for discussion, please add them to the below wiki page by Tuesday, Jan 3 at 2100 UTC. https://wiki.openstack.org/wiki/Meetings/TechnicalCommittee#Next_Meeting -gmann

1 1