Friday, 2021-11-12

opendevreviewBrin Zhang proposed openstack/nova master: Replaces tenant_id with project_id from List SG API  https://review.opendev.org/c/openstack/nova/+/76672601:26
opendevreviewBrin Zhang proposed openstack/nova master: Replaces tenant_id with project_id from Flavor Access APIs  https://review.opendev.org/c/openstack/nova/+/76770401:47
opendevreviewBrin Zhang proposed openstack/nova master: Replaces tenant_id with project_id from List/Show usage APIs  https://review.opendev.org/c/openstack/nova/+/76850903:02
opendevreviewBrin Zhang proposed openstack/nova master: Replace tenants* with projects* of policies  https://review.opendev.org/c/openstack/nova/+/76531503:14
*** gouthamr_ is now known as gouthamr06:19
opendevreviewBrin Zhang proposed openstack/nova master: Replace os-simple-tenant-usage with os-simple-project-usage  https://review.opendev.org/c/openstack/nova/+/76885206:35
opendevreviewBrin Zhang proposed openstack/nova master: Replace tenant_id with project_id in os-quota-sets path  https://review.opendev.org/c/openstack/nova/+/76885106:47
opendevreviewBrin Zhang proposed openstack/nova master: Replace tenant_id with project_id in Limits API  https://review.opendev.org/c/openstack/nova/+/76886206:47
opendevreviewBrin Zhang proposed openstack/nova master: Replace tenant* with project* in codes  https://review.opendev.org/c/openstack/nova/+/76932906:47
opendevreviewBrin Zhang proposed openstack/nova master: Replaces tenant_id with project_id from Flavor Access APIs  https://review.opendev.org/c/openstack/nova/+/76770407:09
opendevreviewBrin Zhang proposed openstack/nova master: Replaces tenant_id with project_id from List/Show usage APIs  https://review.opendev.org/c/openstack/nova/+/76850907:09
opendevreviewBrin Zhang proposed openstack/nova master: Replace tenants* with projects* of policies  https://review.opendev.org/c/openstack/nova/+/76531507:09
opendevreviewBrin Zhang proposed openstack/nova master: Replace os-simple-tenant-usage with os-simple-project-usage  https://review.opendev.org/c/openstack/nova/+/76885207:09
opendevreviewBrin Zhang proposed openstack/nova master: Replace tenant_id with project_id in os-quota-sets path  https://review.opendev.org/c/openstack/nova/+/76885107:09
opendevreviewBrin Zhang proposed openstack/nova master: Replace tenant_id with project_id in Limits API  https://review.opendev.org/c/openstack/nova/+/76886207:09
opendevreviewBrin Zhang proposed openstack/nova master: Replace tenant* with project* in codes  https://review.opendev.org/c/openstack/nova/+/76932907:09
brinzhanghi team, the series of remove tenant_id patches have been updated, please review them while you are free, thanks07:11
gibistephenfin: nice catch07:19
bauzasgood morning fokls08:14
lyarwoodMorning08:21
gibibauzas, lyarwood: happy Friday!08:22
*** gibi is now known as giblet08:22
bauzasoh, the Friday dress code is back ?08:22
*** bauzas is now known as bauwser08:22
gibletmy neighbor decided to renovate his flat and the workers demolishing his bathroom at the moment which has a common wall with my flat. there is a constant noise so I feel like giblet already08:23
giblethence the name08:23
bauwserhah, the likes of remote working08:24
lyarwoodurgh that's awful giblet 08:26
gibletI will survive08:29
bauwserevery last Thurday of the month, I appreciate my neighbor08:30
bauwserjust because then he gets 5 people for mowing his lawn08:31
gibleta lot of lawn I assume08:32
bauwseryeah, around ~2500sqm08:32
bauwserbut they are not having mowers08:32
bauwserrather lawn tractors...08:32
bauwseryou can imagine the noise08:33
giblet:/08:39
opendevreviewBalazs Gibizer proposed openstack/nova stable/pike: Add a WA flag waiting for vif-plugged event during reboot  https://review.opendev.org/c/openstack/nova/+/81343709:06
opendevreviewBrin Zhang proposed openstack/nova master: Replace os-simple-tenant-usage with os-simple-project-usage  https://review.opendev.org/c/openstack/nova/+/76885209:46
opendevreviewBrin Zhang proposed openstack/nova master: Replace tenant_id with project_id in os-quota-sets path  https://review.opendev.org/c/openstack/nova/+/76885109:46
opendevreviewBrin Zhang proposed openstack/nova master: Replace tenant_id with project_id in Limits API  https://review.opendev.org/c/openstack/nova/+/76886209:46
opendevreviewMerged openstack/nova master: tests: Restore - don't reset - warning filters  https://review.opendev.org/c/openstack/nova/+/81764109:52
bauwsergibi: thanks for reviewing https://review.opendev.org/c/openstack/nova/+/816861 09:56
bauwserah, giblet ^09:57
bauwsergiblet: your comment looks good to me, I'll provide a new revision09:57
gibletbauwser: how do you feel about my top level comment there that I'm supportive to allows non-cores to state priority but not for patch owners to self +1?10:02
bauwsergiblet: honestly, I don't have any opinion10:03
bauwsergiblet: maybe we should not use this label for asking folks to look at our change10:03
opendevreviewBrin Zhang proposed openstack/nova master: Replace tenant* with project* in codes  https://review.opendev.org/c/openstack/nova/+/76932910:03
bauwsergiblet: but we should try to find some way to help contributors to ask for reviews without needing to go in IRC10:04
bauwserso I'll provide 2 different points10:04
bauwserand we'll discuss this in the change10:04
giblethm10:17
gibletwhy people cannot come to IRC?10:17
gibletis the problem that it is real time and therefore time zone dependent?10:18
gibletthen they can use the ML 10:18
giblet(but also I keep my client up and read scrollback so I can be reached from other timezones via IRC too)10:19
opendevreviewSylvain Bauza proposed openstack/nova master: WIP: [doc] propose Review-Priority label for contribs  https://review.opendev.org/c/openstack/nova/+/81686110:34
bauwsergiblet: we provided a way to async ask for reviews previously with the etherpad10:36
bauwsernow, you need to ping people, ideally synchronously10:36
bauwserand I don't want the ML to be used for begging reviews or other non-nova contributors will yell at us :)10:37
bauwserbut I need to go to gym10:38
bauwserI'm starting to look at https://gerrit-review.googlesource.com/Documentation/user-attention-set.html 10:38
bauwserwe could use it10:38
*** lbragstad0 is now known as lbragstad11:06
gibletbauwser: attentions set is built on people added in CC and in Review field of a patch11:18
gibletbtw, why don't we say, add me in the review if you need me to look at the patch11:19
gibletthat is async and gerrit based11:19
opendevreviewStephen Finucane proposed openstack/nova master: tests: Enable SQLAlchemy 2.0 deprecation warnings  https://review.opendev.org/c/openstack/nova/+/80470911:27
opendevreviewStephen Finucane proposed openstack/nova master: db: Replace use of Executable.scalar(), Executable.execute()  https://review.opendev.org/c/openstack/nova/+/80487811:27
opendevreviewStephen Finucane proposed openstack/nova master: db: Replace use of 'autoload' parameter  https://review.opendev.org/c/openstack/nova/+/80573411:27
opendevreviewStephen Finucane proposed openstack/nova master: db: Replace use of legacy select() calling style  https://review.opendev.org/c/openstack/nova/+/80573511:27
opendevreviewStephen Finucane proposed openstack/nova master: db: Replace 'insert.inline' parameter with 'Insert.inline()' method  https://review.opendev.org/c/openstack/nova/+/80573611:27
opendevreviewStephen Finucane proposed openstack/nova master: db: Don't pass strings to 'Connection.execute'  https://review.opendev.org/c/openstack/nova/+/80573711:27
opendevreviewStephen Finucane proposed openstack/nova master: db: Don't use legacy 'Row()' methods  https://review.opendev.org/c/openstack/nova/+/81774611:27
opendevreviewStephen Finucane proposed openstack/nova master: db: Remove use of 'bind' arguments  https://review.opendev.org/c/openstack/nova/+/81774711:27
opendevreviewStephen Finucane proposed openstack/nova master: db: Remove unnecessary warning filters  https://review.opendev.org/c/openstack/nova/+/81774811:27
gibletlyarwood, sean-k-mooney: so the patch with the sleep before detach now reproduced the kernel panic https://review.opendev.org/c/openstack/nova/+/817564/3#message-8ef45ae21f54b427ae2c88bbc19a4c926ce0088313:17
gibletfrom the consol log it is clear that the kernel panic happened _before_ we trigger detach13:18
sean-k-mooneyis it possible the panic was tirggered by the attach13:18
gibletor by the live migration13:18
gibletor by the initial boot13:18
gibletall possible13:18
gibletso I will add more console printing step to the test case13:19
gibletto see when the panic happens13:19
sean-k-mooneylooks liek it happend 19 seocnd after boot13:20
giblettrue, we can try to correlate that to the action in the test13:20
sean-k-mooneythe vm went active ~ 12:04:29 13:21
sean-k-mooneywe did the attach at  12:04:40 13:21
sean-k-mooneyactully no maybe i misread that13:22
giblet2021-11-12 12:04:30,036 99321 INFO     [tempest.common.waiters] State transition "BUILD/spawning" ==> "ACTIVE/None" after 7 second wait13:23
giblet2021-11-12 12:04:38,573 99321 INFO     [tempest.common.waiters] volume 0f307fda-dbef-408c-a029-97401db15945 reached in-use after waiting for 0.573394 seconds13:23
sean-k-mooneylooks liek we were just finsihing the mightation when the panic happend13:24
sean-k-mooneyit went active at 2021 12:04:5213:24
giblet2021-11-12 12:04:40,615 <- trigger the live migration13:25
giblet2021-11-12 12:04:52,693 99321 INFO     [tempest.common.waiters] State transition "MIGRATING/migrating" ==> "ACTIVE/None" after 12 second wait13:25
gibletyeah so the panic is somehow related to the live migration13:26
sean-k-mooneyyep13:26
sean-k-mooneyit woudl have been i gues at :49 ish13:26
sean-k-mooneygiblet: just looking at the panic13:27
sean-k-mooneyits realted to ipv6 adress configuraiton13:28
gibletI saw at least 3 different kernel panic13:28
gibletthat test can produce13:28
gibletthis is the 4th one :)13:28
sean-k-mooneywell its specifclay failing in _raw_spin_lock_bh13:29
lyarwoodsorry have various trades people in my house today trying to sort something out13:30
lyarwoodreally hard to focus on anything13:30
sean-k-mooneylyarwood: tl;dr the panic happen during the migration in an interupt handel form _raw_spin_lock_bh at least in this insntace13:31
lyarwoodgiblet: remind me again, when did thi start failing?13:32
sean-k-mooneyso its before the detach in the cleanup phase if the time stames are correct13:32
lyarwoodthis*13:32
giblettehre is lot of different RIP codes in the reproductions https://paste.ubuntu.com/p/QGrtv2nZWz/13:32
gibletlyarwood: on it ...13:32
gibletlyarwood: the first panic was 2021-11-08T12:59:1613:33
sean-k-mooneygiblet: yes altoh galoto of them look like they are related to lcoking/interupt handeling in general13:33
gibletthis one https://zuul.opendev.org/t/openstack/build/c445dc25cb2c4567b223f05d95134c4713:34
lyarwoodgiblet: kk it's not related to https://review.opendev.org/c/openstack/devstack/+/812928 then13:34
gibletlyarwood: there is big gaps between nova-live-migration job run before 11.08.13:36
giblethttps://zuul.opendev.org/t/openstack/builds?job_name=nova-live-migration&project=openstack%2Fnova&branch=stable%2Fvictoria13:36
gibletonly 2 runs in october13:36
gibletthe newer october run still has the logs the older is already lost13:38
sean-k-mooneylooking at https://zuul.opendev.org/t/openstack/build/c445dc25cb2c4567b223f05d95134c47 that panic happend even eairlier in the test after 15 seconds13:39
sean-k-mooneyi have not check if that is during th migration or not but i suspect its also before the detach13:39
sean-k-mooney2021-11-08 12:41:10,502 99684 INFO     [tempest.common.waiters] State transition "BUILD/spawning" ==> "ACTIVE/None" after 6 second wait13:40
sean-k-mooneyvolume was attached at 13:41
sean-k-mooney2021-11-08 12:41:18,780 99684 INFO     [tempest.common.waiters] volume fb8d4e1c-5dae-41b4-a1d9-6ef20937997b reached in-use after waiting for 0.780033 seconds13:41
sean-k-mooneyand the migration finished at 2021-11-08 12:41:32,756 99684 INFO     [tempest.common.waiters] State transition "MIGRATING/migrating" ==> "ACTIVE/None" after 12 second wait13:42
sean-k-mooneyso the panic was also during the live migration13:42
sean-k-mooneyso the detach is failing because the vm was dead after the migration13:43
gibletI checked the oct 29 green run has the same qemu / libvirt version as the later failed runs13:43
gibletqemu-system-x86 amd64 1:4.2-3ubuntu6.18 and libvirt0 amd64 6.0.0-0ubuntu8.1413:43
sean-k-mooneyim just checking dowstram if we have an closed bugs with live migration or painc in ther enames13:47
sean-k-mooney1113:47
sean-k-mooneythere are 3 nested virt issue that lok somewhat related but thos where this is happenign are not using that correct13:52
gibletwe have virt_type=qemu in the config13:55
gibletso they are not nested guests13:55
sean-k-mooneyyes but im wonderign if nested virt is avaiabel and if the host are intel do they have  kvm_intel.pml=113:59
sean-k-mooneyits not nested kvm but its still a nested qemu instnace13:59
sean-k-mooneyactully the pml issue seams to be more related to live migrating the l1 vm not the l2 vm14:00
sean-k-mooneyso ya i dont see anything downstram that imidiatly screams this is a fixed qemu/kernel bug14:09
gibletI did a summary in the bug and linket do this chat 14:13
belmoreirahi, I remember that in the past there were some discussions to have live migrations between cells.14:44
belmoreirais there any progress on this?14:45
gibletbelmoreira: I think the cross cell migration work was stopped when mriedem left14:45
sean-k-mooneywe have not implemeted it14:45
sean-k-mooneywe have cross cell cold migratiohn/resize14:46
sean-k-mooneybelmoreira: there is no assumtion that hyperviors can talk to each other directly between cells14:46
sean-k-mooneybelmoreira: they might be abel too but we decied we could not assuem that14:46
belmoreirayeah... is what I recall. And I think he was only working in cold migration as a starting point14:46
sean-k-mooneygiblet: the cross cell migration work is completed14:47
sean-k-mooneygiblet: that works but only cold migration14:47
sean-k-mooneyvia effectivly a shelve14:47
gibletyepp14:47
sean-k-mooneyand then unshelve to the new cell14:47
belmoreirahumm... I missed that in the release notes.14:48
dansmithbelmoreira: it's been like a couple years at this point.. :P14:48
dansmithI dunno how reliable it is because I think it's very infrequently used, if that :/14:49
sean-k-mooneyi think its in train14:49
sean-k-mooneybut ya i don tknow if any of our downstream custoemr use it14:50
sean-k-mooneymost of them are not multi cell14:50
belmoreirahonestly, I was searching for it just few minutes ago... in all releases after Rocky because I recall that mriedem was working on it14:50
belmoreirabut anyway... what I'm looking at is a way to live migrate not cold migrate14:51
sean-k-mooneyoh its ussuri https://specs.openstack.org/openstack/nova-specs/specs/ussuri/implemented/cross-cell-resize.html14:51
sean-k-mooneybelmoreira: right we basically agree to not implemnte live migration 14:51
sean-k-mooneyeffectivly ever14:51
dansmithsean-k-mooney: did we?14:51
belmoreira:)14:51
sean-k-mooneywe could but it would reuiqre assumeing conenctivty betwenn the hyperviors in diffenet cells14:51
dansmithIIRC it was going to be more complicated, very little audience, and so had no plans14:52
sean-k-mooneydansmith: well  i thinke the connectivty was the main blocker14:52
dansmithsure, but live migration already assumes connectivity between hosts that not everyone allows, even in one cel14:52
sean-k-mooneyi gues that is true14:52
belmoreiramy use case is a one off... I'm trying to get rid of nova-network14:52
dansmithmy recollection was "if there's large uptake of cells and this becomes a thing lots of people want, we can consider, but no plans until then" 14:53
sean-k-mooneybelmoreira: if you have a need for it and or people to work on it i would be happy to review a spec14:53
dansmithand so far, no such demand that I know of14:53
sean-k-mooneydansmith: yep i think that is a fiar summary14:53
belmoreirathe hypothetical plan would be to live migrate the instances from a nova-network cell to a neutron cell14:53
dansmithbelmoreira: well, unlikely that would work anyway I think, without very special planning on our part,14:54
dansmithwhich we obviously can't and won't do without the code being in master :)14:54
belmoreirayeah... honestly I'm not asking for it... but it would be great if we can discuss the blockers... in case I need to deal with them14:55
belmoreirathe main problem in my view would be to make both source and dest talk (different conductors) and populate the DB14:55
*** efried1 is now known as efried14:56
dansmithbelmoreira: it would need to work the same way the cross-cell cold migration works,14:56
dansmithwhich is the superconductor does that bridging from the nova perspective14:56
dansmithi.e. it's the thing that creates the instance in the target cell and deletes it from the old cell when the time comes14:56
sean-k-mooneydansmith: we might also need to proxy the conntion between the hypervirous via the the super condctor host or some other host if we coudl not asusme direct conenctivity14:57
belmoreirain my case I can have direct connectivity14:57
sean-k-mooneythere are also complcaiton when volumes or ceph gets invovled14:57
sean-k-mooneybelmoreira: is your cinder/ceph storage shared accross cells14:58
belmoreirayes, it is14:58
dansmithsean-k-mooney: well, or we have to redesign the live migration flow to go through (super)conductor in a more push-pull sort of way14:58
sean-k-mooneywell i ment makign it so qemu on one host could talke to qemu on another via proxign the coneection.15:00
dansmithoh, I dunno, I think you'd just make it a requirement that they can talk direct,15:01
dansmitheven if for a short time15:01
dansmithimplementing a well-performing proxy at the superconductor (which is likely just a container on a host) seems like more work than necessary15:01
sean-k-mooneyya it does15:02
belmoreirathose are not limitations for me...15:02
sean-k-mooneybelmoreira: yep the were just limiation in general15:02
sean-k-mooneye.g. if you map cells to edge sites15:02
sean-k-mooneycross cell migration get a lot harder if its over the wan15:03
belmoreirait looks like it's a lot of work... because its a live migration the instance entries need to be created in the dest cell DB, domain XML needs to be created, take care of the network logic, and possible ceph volumes attached... qemu starts the migration and it needs to be removed from the source DB, placement updated15:04
sean-k-mooneyi dont link config driven api behavior but i kind of feel like we woudl need a way to enabel/disabel this perhapes via the sschuler config in soem way15:04
sean-k-mooneybelmoreira: we would have to also update the instnace cell mapping in the api db15:05
belmoreiratrue15:05
sean-k-mooneywhich is parly why this need to be driven by the super conductor15:05
dansmithsean-k-mooney: we disabled it via policy now15:05
sean-k-mooneydansmith: cross cell live migration15:06
sean-k-mooneyhow does the policy rule know its corsscell15:06
sean-k-mooneyare we actully doign a lookup of the host if we force the destionaion?15:07
belmoreiraCross cell resize was added in Ussuri (i was searching for migration, that's why I missed it)15:07
dansmithsean-k-mooney: we have a flag to the api that says "can cross cell boundaries" I think, and only allow that if policy passes15:08
sean-k-mooneybelmoreira: ah ya same code path internelly15:09
belmoreiragreat... looks like I will be the oldest nova-network user around :)15:12
belmoreiradansmith sean-k-mooney thanks a lot for the comments and insights15:12
dansmithsean-k-mooney: well, I thought we expressed intent to the api that we wanted to cross, but apparently it's only the config flag, but yeah we check the policy deeper in compute/api to decide if the user is allowed15:15
sean-k-mooneyya that would work. i dont think we modify the request body to request cross cell either, so ya it woudl have to be checked later in the compute api15:18
gibletsean-k-mooney: Am I correct that nova uses the physnet of the neutron network in two cases 1) matching it with the physical_network property of the PciDevice (coming from the whitelist) during scheduling if there is InstancePciRequest 2) if numa aware vswitches are configured then matching against novas configuration 15:35
giblethttps://specs.openstack.org/openstack/nova-specs/specs/rocky/implemented/numa-aware-vswitches.html#id33 ? 15:35
opendevreviewArtom Lifshitz proposed openstack/nova master: DNM: Test token expiration during live migration  https://review.opendev.org/c/openstack/nova/+/81777815:36
elodillesbauwser: sorry, I forgot to ping you earlier about the ussuri release patch (as today is the Ussuri Transition Day o:)) if you could approve this that would be great :) https://review.opendev.org/c/openstack/releases/+/81722615:48
bauwserelodilles: done :)15:50
elodillesbauwser: cool, thanks! \o/ I'll update the nova ussuri-em patch after this has merged15:52
bauwser;)15:52
opendevreviewArtom Lifshitz proposed openstack/nova master: DNM: Test token expiration during live migration  https://review.opendev.org/c/openstack/nova/+/81777816:50
opendevreviewArtom Lifshitz proposed openstack/nova master: DNM: Test token expiration during live migration  https://review.opendev.org/c/openstack/nova/+/81777816:52
elodillesbauwser if you are still here: ussuri relese patch has merged and the ussuri-em patch is updated: https://review.opendev.org/c/openstack/releases/+/81760616:55
bauwserelodilles: last call, indeed.16:55
elodillesbauwser: uh, didn't want to leave it to end of the day, but somehow forgot to ping you earlier :S sorry :/16:56
bauwsernp :)16:57
artomdansmith, hey, if we do an instance.save() for example, but no fields have changed, we don't actually do the DB update, correct?17:08
* bauwser goes off for the day17:15
bauwserelodilles: I could be wrong but I said 'no' to https://review.opendev.org/c/openstack/releases/+/81760617:16
dansmithartom: https://github.com/openstack/nova/blob/171138146a648d22474b7021ac730e26f03455f8/nova/objects/instance.py#L810-L81117:16
artomdansmith, oh, it's only in instance, not provided by base ovo?17:17
* artom checks base ovo save()17:17
dansmithartom: not all objects even have a save17:17
artomDoh, right17:18
dansmithartom: base ovo provides dirty tracking for the fields, but what you do with it is up to you17:18
*** amodi_ is now known as amodi17:19
artomdansmith, yeah, makes sense17:20
sean-k-mooneygiblet: yes those are the two cases it uses it17:58
opendevreviewArtom Lifshitz proposed openstack/nova master: DNM: Test token expiration during live migration  https://review.opendev.org/c/openstack/nova/+/81777818:01
elodillesbauwser: sorry, yes, so those patches are not relevant from release perspective :)18:12
elodillesbauwser: why would we force customers to upgrade those packages on production systems because of some TOX and zuul and gerrit related changes? o:)18:14
sean-k-mooney[m]which packages18:15
elodillesosc-placement and python-novaclient18:15
elodillessean-k-mooney[m]: see this patch: https://review.opendev.org/c/openstack/releases/+/81760618:15
sean-k-mooney[m]the oscp placment tox changes wont alter what is installed18:18
sean-k-mooney[m]it just uses the ussuri upper-constratings instead of master18:19
elodillesyepp, exactly :)18:22
sean-k-mooney[m]elodilles i would personally update the shas to the latest if we are doing a release anyway but i dont see any issues that would need a release to be packaged18:23
sean-k-mooney[m]there is a fix for one func test in novaclient18:23
sean-k-mooney[m]but again wont affect end users18:23
elodillessean-k-mooney[m]: the *-em tag is not a "release" it is a tag against the latest release. and releases should be meaningful for end users as far as i know18:24
*** Guest5508 is now known as melwitt19:26
*** melwitt is now known as Guest571619:27
*** Guest5716 is now known as melwitt19:32
*** melwitt is now known as jgwentworth19:34
opendevreviewArtom Lifshitz proposed openstack/nova master: DNM: Test token expiration during live migration  https://review.opendev.org/c/openstack/nova/+/81777820:25
opendevreviewArtom Lifshitz proposed openstack/nova master: DNM: Test token expiration during live migration  https://review.opendev.org/c/openstack/nova/+/81777820:26
opendevreviewArtom Lifshitz proposed openstack/nova master: DNM: Test token expiration during live migration  https://review.opendev.org/c/openstack/nova/+/81777821:53
opendevreviewDavid Hill proposed openstack/nova stable/ussuri: Ensure MAC addresses characters are in the same case  https://review.opendev.org/c/openstack/nova/+/81768923:00
opendevreviewDavid Hill proposed openstack/nova stable/train: Ensure MAC addresses characters are in the same case  https://review.opendev.org/c/openstack/nova/+/81783023:00

Generated by irclog2html.py 2.17.2 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!