Tuesday, 2023-06-27

opendevreviewmelanie witt proposed openstack/nova-specs master: Propose tooling and docs for unified limits  https://review.opendev.org/c/openstack/nova-specs/+/88701401:52
opendevreviewGhanshyam proposed openstack/nova-specs master: Re-propose "Policy service role spec"  https://review.opendev.org/c/openstack/nova-specs/+/88188004:33
opendevreviewAmit Uniyal proposed openstack/os-vif stable/wallaby: set default qos policy  https://review.opendev.org/c/openstack/os-vif/+/88677805:39
opendevreviewAmit Uniyal proposed openstack/os-vif stable/wallaby: Move mtu update request into ovsdb transaction  https://review.opendev.org/c/openstack/os-vif/+/88701705:39
bauzashappy spec review day everyone07:13
*** elodilles_pto is now known as elodilles07:22
opendevreviewAmit Uniyal proposed openstack/os-vif stable/wallaby: set default qos policy  https://review.opendev.org/c/openstack/os-vif/+/88677807:30
*** efried1 is now known as efried07:47
zigosean-k-mooney[m]: bauzas: You guys remember I reported that some of my bullseye instances wouldn't live-migrate with an issue in virtio? It appears that the Qemu package in Bullseye has the typo described here:09:07
zigohttps://bugzilla.redhat.com/show_bug.cgi?id=1984401#c3409:07
zigoI'm currently rebuilding a new version of the Qemu package with the fix, I'll let you know if this really fixes the issue ! :)09:07
zigoGosh, all this for just one char ...09:07
bauzasok09:10
opendevreviewSylvain Bauza proposed openstack/nova-specs master: Re-propose spec for ephemeral storage encryption  https://review.opendev.org/c/openstack/nova-specs/+/88701109:15
opendevreviewMerged openstack/nova-specs master: Re-propose spec for ephemeral encryption for libvirt  https://review.opendev.org/c/openstack/nova-specs/+/88701209:29
opendevreviewJohn Garbutt proposed openstack/nova master: Add nova-manage ironic-compute-node-move  https://review.opendev.org/c/openstack/nova/+/88698909:46
sean-k-mooney1 "vitio-balloon-device/page-poison",09:49
sean-k-mooney1i see09:49
*** sean-k-mooney1 is now known as sean-k-mooney09:53
opendevreviewJohn Garbutt proposed openstack/nova master: Deprecate ironic.peer_list  https://review.opendev.org/c/openstack/nova/+/88334610:06
opendevreviewJohn Garbutt proposed openstack/nova master: Limit nodes by ironic shard key  https://review.opendev.org/c/openstack/nova/+/88698010:06
opendevreviewJohn Garbutt proposed openstack/nova master: Add nova-manage ironic-compute-node-move  https://review.opendev.org/c/openstack/nova/+/88698910:06
*** tobias-urdin is now known as tobias-urdin-pto10:43
opendevreviewAmit Uniyal proposed openstack/os-vif stable/wallaby: set default qos policy  https://review.opendev.org/c/openstack/os-vif/+/88677810:58
sahido/ qucik question guys, have we a tool to clean old deleted instances in database? some sort of housecleaning job11:55
sahidhum looks like nova-manage is the tool that i'm looking for11:59
sean-k-mooneyyep the archive-delete-rows and prune commands12:06
sean-k-mooneywe generally recommend runing those in a corn job using --before 12:06
sean-k-mooneyso arcive all delete insace ofver 30ds and pruge them after 90 days12:07
sean-k-mooneyrun that at least daily in cron12:07
sean-k-mooneywith max rows set high enogugh to ensure there is no build up over time12:07
sean-k-mooneyhttps://docs.openstack.org/nova/latest/cli/nova-manage.html#db-archive-deleted-rows and https://docs.openstack.org/nova/latest/cli/nova-manage.html#db-purge12:08
sahidi was actually scary to set a max rows too high, and falldown in a timeout, perhaps having the cron running several times a day with max rows small is better, no?12:09
sean-k-mooneyyou should not hit any time out but it will lod the db12:09
sean-k-mooneyyou can do it severlal timees a day but honestly if thise casus an issue on your cloud you have undersided your DB12:10
sahidyes that is right, we perhaps have to care of that the first time12:12
sean-k-mooneyi wourd personlaly do something like nova-manage db archive_deleted_rows --until-complete --before $(date -I -d '-1 month') --all-cells --task-log12:12
opendevreviewPierre Libeau proposed openstack/nova master: Use admin_client to allocate port for instance  https://review.opendev.org/c/openstack/nova/+/86117212:14
zigoI can confirm that the one char patch that I decribed at https://bugs.debian.org/1039567 fixes the live-migration of VMs with page_poison activated.13:06
zigo:)13:06
*** blarnath is now known as d34dh0r5313:26
sean-k-mooneyzigo: congrats sorry it took so long to figure it out but good to know that is coming to repo near by soon13:59
zigoI already upgraded the unofficial debian.net repo with my custom patched qemu, and will try to upgrade official Bullseye! :)13:59
sahidsean-k-mooney: ack thanks !14:28
opendevreviewAmit Uniyal proposed openstack/os-vif stable/yoga: set default qos policy  https://review.opendev.org/c/openstack/os-vif/+/88671014:30
opendevreviewAmit Uniyal proposed openstack/os-vif stable/yoga: set default qos policy  https://review.opendev.org/c/openstack/os-vif/+/88671014:45
opendevreviewAmit Uniyal proposed openstack/os-vif stable/xena: set default qos policy  https://review.opendev.org/c/openstack/os-vif/+/88671614:49
opendevreviewAmit Uniyal proposed openstack/os-vif stable/yoga: set default qos policy  https://review.opendev.org/c/openstack/os-vif/+/88671015:01
bauzasreminder : nova meeting in 55 mins here15:06
opendevreviewAmit Uniyal proposed openstack/os-vif stable/xena: set default qos policy  https://review.opendev.org/c/openstack/os-vif/+/88671615:10
opendevreviewAmit Uniyal proposed openstack/nova master: Added context manager for instance lock  https://review.opendev.org/c/openstack/nova/+/87364815:17
opendevreviewAmit Uniyal proposed openstack/nova master: Disconnecting volume from the compute host  https://review.opendev.org/c/openstack/nova/+/87744615:17
bauzas#startmeeting nova16:01
opendevmeetMeeting started Tue Jun 27 16:01:26 2023 UTC and is due to finish in 60 minutes.  The chair is bauzas. Information about MeetBot at http://wiki.debian.org/MeetBot.16:01
opendevmeetUseful Commands: #action #agreed #help #info #idea #link #topic #startvote.16:01
opendevmeetThe meeting name has been set to 'nova'16:01
bauzashey folks \o16:01
elodilleso/16:01
auniyalo/16:01
gibio\16:01
bauzas#link https://wiki.openstack.org/wiki/Meetings/Nova#Agenda_for_next_meeting16:01
bauzasok let's start while the folks are arriving :)16:02
bauzas#topic Bugs (stuck/critical) 16:03
bauzas#info No Critical bug16:03
bauzas#link https://bugs.launchpad.net/nova/+bugs?search=Search&field.status=New 31 new untriaged bugs (+4 since the last meeting)16:03
Uggla_o/16:03
bauzasI only had time to look at two bugs this week 16:03
bauzassorriy16:03
bauzasI can try to look at the bugs this new week16:03
bauzasokay, nobody is against16:05
bauzas#info Add yourself in the team bug roster if you want to help https://etherpad.opendev.org/p/nova-bug-triage-roster16:05
bauzas #info bug baton is being passed to bauzas16:05
gibiI would be super suprised if somebody want to stole the baton :D16:05
bauzasdo people want to discuss on bugs ?16:05
bauzasgibi: :)16:05
bauzaslooks not16:06
bauzas#topic Gate status 16:06
bauzas#link https://bugs.launchpad.net/nova/+bugs?field.tag=gate-failure Nova gate bugs 16:06
bauzasit looks to me we have a new bug :(16:07
bauzas#link https://bugs.launchpad.net/nova/+bug/202509616:07
dansmithit's been skipped for now,16:07
dansmithbut that appears to just have not been tested on ceph and something is wrong with it in that environment16:07
dansmithI'm not sure about the non-ceph assertion in the comment, I'll have to look16:08
bauzasdansmith: ack16:08
dansmithbut that's a test we should have landed a year ago16:08
dansmithand it just got merged16:08
bauzasI was looking at Zuul16:08
bauzasanyway, like you say, the job is not failed https://zuul.openstack.org/builds?job_name=nova-ceph-multistore&skip=016:09
bauzasdansmith: https://b932a1446345e101b3ef-4740624f0848c8c3257f704064a4516f.ssl.cf5.rackcdn.com/883557/2/check/nova-ceph-multistore/d7db64f/testr_results.html16:10
bauzasthe test is not skipped16:10
dansmithhttps://review.opendev.org/c/openstack/devstack-plugin-ceph/+/88700316:11
dansmithwe should be inheriting from that afaik16:11
bauzasahah16:12
bauzasok16:12
dansmithwhy do you say it's not skipped?16:12
bauzasgmann: could you add a new change for skipping test_rebuild_volume_backed_server on nova-ceph-multistore16:12
bauzas?16:12
bauzasdansmith: oh wait, verifying16:13
dansmiththe patch specifically calls out the nova job16:13
bauzasyeah, you're right, the test is now skipped16:14
bauzasgmann: nevermind what I said16:14
bauzashttps://6354f24cae23db064c15-540aa9666e0f6140cd4132fd113878d1.ssl.cf5.rackcdn.com/876075/14/check/nova-ceph-multistore/617bfe5/testr_results.html I don't see the test16:14
bauzasdansmith: sorry, I misunderstood what you said16:14
dansmith..okay16:15
bauzasdansmith: sometimes my brain doesn't run correctly16:15
bauzas:(16:16
bauzasanyway, moving on16:16
bauzas#link https://zuul.openstack.org/builds?project=openstack%2Fnova&project=openstack%2Fplacement&pipeline=periodic-weekly Nova&Placement periodic jobs status16:16
bauzasnothing to relate16:16
bauzas#info Please look at the gate failures and file a bug report with the gate-failure tag.16:16
bauzas#info STOP DOING BLIND RECHECKS aka. 'recheck' https://docs.openstack.org/project-team-guide/testing.html#how-to-handle-test-failures16:16
bauzas(I could remove this note next week)16:17
bauzasmoving on then, unless folks want to discuss on some other CI failures16:17
bauzas#topic Release Planning 16:17
bauzas#link https://releases.openstack.org/bobcat/schedule.html16:18
bauzas#info Nova deadlines are set in the above schedule16:18
bauzas#info Nova spec review day today (June 27th)16:18
bauzasI started to review a few specs16:18
bauzasI approved one16:18
bauzasI still have two other specs to look at16:18
bauzasif I don't have time to look at them today, I'll continue to review the specs tomorrow16:19
bauzasand tomorrow, I'll add an etherpad about the already merged specs and their code16:19
bauzasas an important reminder,16:19
bauzas#link https://releases.openstack.org/bobcat/schedule.html#b-nova-spec-freeze Nova Spec Freeze on July 6th !16:20
bauzaswhich is next week16:20
bauzasmost of the specs I've seen already have implementation changes16:20
bauzasso thanks folks for that16:20
bauzasanything anyone that wants to discuss on either specs or our release planning ?16:21
bauzas-16:21
bauzasmoving on then16:22
bauzas#topic Stable Branches 16:22
bauzaselodilles: wants to discuss anything ?16:22
elodillesbauzas: nope, actually16:22
bauzascool cool16:22
elodillesnot much happened recently16:22
elodillesaround stable16:22
bauzas#info stable gates should be OK (from stable/2023.1 to stable/train)16:22
bauzas#info stable branch status / gate failures tracking etherpad: https://etherpad.opendev.org/p/nova-stable-branch-ci16:22
bauzaselodilles: no news is good :)16:22
elodilles:)16:23
bauzas#info train-eol patch proposed https://review.opendev.org/c/openstack/releases/+/88536516:23
bauzaselodilles: I've seen your comment16:23
elodillesyepp, it needs an update16:23
bauzasso you're also asking to EOL placement, os-vif, os-resource-classes, and the clients ?16:23
bauzasI can work on it16:24
elodillesyes, i guess those would be good to EOL together16:24
elodilleswith nova16:24
elodillesas no reason to keep them in EM, right?16:24
elodilleswithout nova...16:24
bauzaselodilles: also, my question is, shall we abandon the changes in the stable branches, or would it be done automatically ?16:24
gibios-traits and os-resource classes should be tight to the placement eol16:24
elodillesthey need to be abandoned, there's no automation16:25
bauzaselodilles: for os-vif and novaclient, sounds ok16:25
bauzasfor placement dependencies, I'm quite torn16:25
gibibut os-traits might also be used be neutron16:25
bauzasgibi: good call, then let's stick to os-vif and novaclient 16:25
elodillesi guess if nova eol's it's train branch then maybe other projects will do the same16:26
bauzaswe could discuss about EOLing placement and its deps on another change16:26
gibibauzas: os-vif is also used by neutron for sure16:26
elodilles(and i won't insist to keep open neutron either in that case o:)16:26
bauzaselodilles: I've heard other projects that would EOL *all* their EM branches but I haven't seen yet any change :)16:26
gibipython-novaclient is used by cinder and neutron for the external events no?16:26
elodillesbauzas: yes, i only seen the cinder patch yet16:26
bauzasgibi: good point, let's then be conservative and only EOL novaclient16:27
gibialso heat probably uses nova-pythonclient16:27
bauzaselodilles: what have we done when we EOL'd Stein ?16:27
gibican we delete all the train branches at once? :D16:27
bauzasI thought nova did it in advance16:27
elodillesheat is already EOL'd up to ussuri16:27
elodillesbauzas: if you ask about the open patches: i ussually abandon the patches to be able to delete the branch :)16:28
elodillesso i can abandon them whenever there is a decision16:28
bauzaselodilles: so I need to click on *every* open patch to abandon it ?16:28
bauzasdisclaimer, my office room is 28°C now, my brain is absolutely fried.16:29
elodillesbauzas: i can do that (there aren't many open patches)16:29
bauzasso, what's the outcome of this long conversation ,16:30
bauzas?16:30
elodilleshere the temperature is quite moderate now 21°C :)16:30
bauzasI guess only nova and novaclient can be EOL now16:30
bauzaselodilles: it's 28°C *inside* my room (I don't have any A/C)16:30
gibibauzas: I'm not sure about python-novaclient16:30
bauzasokay, so let's be strict16:31
bauzasand only EOL nova16:31
sean-k-mooneyEOLign should not break others as we are just closing the branch and tagging it16:31
bauzaselodilles: fancy revisiting your comment ?16:31
sean-k-mooneyand libs like os-vif are installed form pypi by default16:31
sean-k-mooneyat most we would need a overdied-checkout for os-vif to poitn to the eol tag unless i missed something16:32
elodillesbauzas: i still think it's better to EOL all the other nova projects in the same go16:32
sean-k-mooneyya same ^16:32
bauzasgibi: agree then ?16:32
gibielodilles: sure, but then somebody need to handle the fallout16:33
elodillesgibi: by fallout you mean?16:33
gibiother project's job is failing to check out the deleted branch16:33
gibias an exmple16:34
gibiexample16:34
elodillesyeah, that probably needs to be fixed (and honestly, more like EOL'ing everything else16:34
bauzasI guess we need to work on this closely16:34
bauzasAFAIK I tried to look at the jobs to find the ones that use stable/train branch of nova16:35
elodillesbtw, was there any result of the PTG forum session about the EM story?16:35
bauzasand unfortunately, I have no crazy idea on how to get a list of such jobs16:35
elodillesi haven't seen news on ML about that16:35
bauzassince the job definitions are in the project repos, I would have to discover every single git repo in order to ensure this isn't the case :(16:36
gibielodilles: the result was to follon on the ML16:36
bauzaselodilles: about that, the conclusion is mostly that the TC will discuss this16:36
bauzasand yeah, follow on the ML16:36
elodillesbauzas: yes, looking for those jobs is a bit tricky, the "easiest" maybe to compare with ussuri's .zuul.yaml and what jobs were removed there16:37
bauzastl;dr: no agreement was there to stop the EM experience, but a clarification was needed.16:37
bauzaselodilles: you mean stein ?16:37
elodillesbauzas: OK, so we either rush forward with the train EOL patch or wait then until tc discussion happens?16:38
* bauzas is lost in translation16:38
bauzas(and again, the room temperature doesn't help)16:38
sean-k-mooneythe TC discussion is about EM as a whole and would affect everythin before ZED16:38
bauzaselodilles: not sure any conclusion would hit our EOL of train16:38
sean-k-mooneyi think we can EOL train regardless of what happens for the newer EM branchs16:38
bauzasrighjt16:39
dansmithfor sure16:39
elodillesbauzas: not stein, ussuri. the job, that is removed in ussuri probably was last used in train, thus its definition can be deleted (if it is outside of nova repo)16:39
bauzasand IIRC, EM will continue to exist in some form16:39
bauzasmaybe the M of EM carries too much context, but the idea is that we'll continue to have other branches16:40
gibiI agree to drop train regardless of the TC discussion16:40
bauzasthose branches could be somewhere else, but that's an alternative to discuss yet16:40
bauzaselodilles: again, lost in translation but I'll ping you tomorrow about it16:40
elodillesOK, anyway, i think the 'fallout' will happen regardless we EOL only nova. EM / EOL'ing would be confusing if even within a project would be mixed16:40
elodillesbauzas: sure, we can check it outside of the meeting :)16:41
bauzason a morning, with a fresh room temperature, a rested brain and a coffee, please.16:41
elodillesbauzas: ++ :)16:42
bauzasanyway, doesn't sound there is a change in direction16:42
bauzasI guess we're done on that topic anyway16:42
elodilles++16:42
bauzas#topic Open discussion 16:42
bauzasI have one thing16:42
bauzas(bauzas) Specless blueprint approval request for https://blueprints.launchpad.net/nova/+spec/num-instances-weigher16:42
bauzastl;dr: some operators said during the PTG that they were having some problems for spreading between heteregenous hardware16:43
bauzasso we found we missed a weigher16:43
bauzaswe already have a filter for making sure a host can't have more than a max number of instances16:44
gibi+1 to have this16:44
gibiit is a quick and easy win16:44
bauzasbut it doesn't spread the hosts16:44
dansmithyup16:45
bauzasthere is a current discussion on the already-provided code change https://review.opendev.org/c/openstack/nova/+/88623216:45
bauzasthe concern is that we have a negative default value for spreading16:46
sean-k-mooneywhihc is not realted to if we shoudl have the weigher. im ok wigher jsut dislike that we have to default to -1 to spread when positive multipes are normally spread since we spread by default16:46
sean-k-mooneyyep so after some other discussion i woudl just prefer you retrined the number of instance * -1.016:46
sean-k-mooneyand default to 1.016:46
bauzassean-k-mooney: yeah and I understand your concern but my point is that I don't want to have a max-instances value that would be the same for all hosts16:47
sean-k-mooneythat is a prefernce not a blocker16:47
sean-k-mooneyyep which is why i provided two suggestion orginally16:47
gibihm, how the -1 relates to the max-instance?16:47
sean-k-mooneyit does not16:48
sean-k-mooneyi provided 2 suggestsions16:48
sean-k-mooneyreturn max_instace- current 16:48
bauzassean-k-mooney: okay, so you would be okay if _weigh_object() would just do -1 * host_state.num_instances ?16:48
sean-k-mooneyor return current * -1.016:48
sean-k-mooneyyep16:48
sean-k-mooneytottaly fine with that16:48
gibiThe -1.0 one works for me. I would not complicate it with the max-instance16:48
bauzassean-k-mooney: as I said in https://review.opendev.org/c/openstack/nova/+/886232/comment/565abda0_70ab7fde/ we already have negative values for spreading16:49
bauzashttps://docs.openstack.org/nova/latest/configuration/config.html#filter_scheduler.io_ops_weight_multiplier16:49
sean-k-mooneyyep i pointed that out to you in the review16:49
sean-k-mooneyand noted that its unforturneate because its teh opisctie behavior of the cpu ram and disk weighers16:50
sean-k-mooneyand i didnt want to proliferate that by adding more useage16:50
sean-k-mooneybut as i also said its just a prefrence if other dont mind then fine16:50
bauzasokay, if really you want it to be positive, then I'll just multiply by -1.016:50
bauzasbut I'm not sure it's really a problem to have a negative value for spreadinh16:51
bauzasanyway, looks to me an implementation nit16:51
sean-k-mooneyit just makes it harder to reason about 16:51
sean-k-mooneyif it would not break peopel i would change the io_ops_weigher16:51
bauzasdo people agree on having https://blueprints.launchpad.net/nova/+spec/num-instances-weigher to be specless ?16:51
sean-k-mooneybut its really not worth it16:51
dansmithI wasn't aware we had any sort of weigher convention where one value means pack or spread16:51
dansmithbauzas: yes, specless16:51
sean-k-mooneyya specless is good with me16:51
bauzascool, then we'll revisit this conversation in gerrit16:52
sean-k-mooneyack16:52
dansmithI've heard you say that, but I've never heard that before16:52
bauzasanyone fancy to review the code itself 16:52
dansmithI guess I'll have to go look at the existing weighers and see16:52
bauzasdansmith: I can't remember it too16:52
bauzasin general our weighers have different default values16:52
gibi+1 on specless16:52
bauzaslike https://docs.openstack.org/nova/latest/configuration/config.html#filter_scheduler.build_failure_weight_multiplier16:52
dansmithbauzas: yeah I thought they were all pretty much individually contextual16:53
bauzaswhich defaults to 1000000.016:53
sean-k-mooneyin generall they all spread by default and positive measn spread. those are the two ruels of tumb i learend early on16:53
bauzasanyway16:53
sean-k-mooneyif we broke that at some poin thats unfortunet btu its what we are stuck with16:53
bauzas#agreed https://blueprints.launchpad.net/nova/+spec/num-instances-weigher is approved as a specless bp16:53
gibi\o/16:53
bauzasI guess we can continue this in gerrit :!)16:53
bauzas:)16:53
bauzasokay, so I don't see any other item16:54
bauzasanyone wanting to discuss on something ?16:54
* gibi sends the nice cool weather towards France16:55
bauzasthanks :)16:55
Uggla_:)16:55
bauzasI guess I'll need to stop sooner than later16:56
bauzasanyway16:56
bauzasthanks all16:56
bauzas#endmeeting16:56
opendevmeetMeeting ended Tue Jun 27 16:56:11 2023 UTC.  Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4)16:56
opendevmeetMinutes:        https://meetings.opendev.org/meetings/nova/2023/nova.2023-06-27-16.01.html16:56
opendevmeetMinutes (text): https://meetings.opendev.org/meetings/nova/2023/nova.2023-06-27-16.01.txt16:56
opendevmeetLog:            https://meetings.opendev.org/meetings/nova/2023/nova.2023-06-27-16.01.log.html16:56
bauzasthree machines and two screens running in a 9m2 room doesn't help with the temperature FWIW :)16:57
gmannbauzas: sean-k-mooney elodilles gibi: about EM, TC will be discussing about EM as concept and how to solve the issue of maintenance expectation. Oldest/er EM branch(es) moving to EOL as per normal process/some blocker or project decision is all good to go.  17:30
elodillesgmann: ack, thanks for the info!17:35
dansmith++17:35
gibigmann: thanks17:37
NobodyCamGood morning Nova folks, Would anyone happen to know if there is a list of status messages emitted by Nova??? I am look to see if there are events for rescue17:42
NobodyCamI found them "rescue.start" & "rescue.end"17:45
dansmithNobodyCam: this might help: https://github.com/openstack/nova/tree/master/doc/notification_samples17:48
NobodyCamThank you dan. that is very helpful!17:49
NobodyCams/d/D/17:49
opendevreviewAmit Uniyal proposed openstack/os-vif stable/wallaby: Move mtu update request into ovsdb transaction  https://review.opendev.org/c/openstack/os-vif/+/88701718:39
opendevreviewAmit Uniyal proposed openstack/os-vif stable/wallaby: set default qos policy  https://review.opendev.org/c/openstack/os-vif/+/88677818:39
opendevreviewDan Smith proposed openstack/nova master: DNM: Test reimage-timeout change  https://review.opendev.org/c/openstack/nova/+/88711219:21
dansmithbauzas:  this ^ is the end of the chain to fix that rebuild timeout issue (we think)19:22
opendevreviewMerged openstack/nova stable/xena: Reproduce live migration rollback w/o multi port bindings error  https://review.opendev.org/c/openstack/nova/+/84333619:24
opendevreviewMerged openstack/nova stable/xena: Fix LM rollback w/o multi port bindings extension  https://review.opendev.org/c/openstack/nova/+/84333721:48
opendevreviewmelanie witt proposed openstack/nova-specs master: Propose tooling and docs for unified limits  https://review.opendev.org/c/openstack/nova-specs/+/88701422:23

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