opendevreview | melanie witt proposed openstack/nova master: DNM test ephemeral encryption + resize: qcow2, raw, rbd https://review.opendev.org/c/openstack/nova/+/862416 | 02:01 |
---|---|---|
opendevreview | OpenStack Proposal Bot proposed openstack/nova master: Imported Translations from Zanata https://review.opendev.org/c/openstack/nova/+/891648 | 03:28 |
*** efried1 is now known as efried | 05:22 | |
dvo-plv | Hello Nova folks. maybe you will have a chance to review https://review.opendev.org/c/openstack/nova/+/876075 | 08:27 |
opendevreview | Danylo Vodopianov proposed openstack/nova master: Napatech SmartNIC support https://review.opendev.org/c/openstack/nova/+/859577 | 09:29 |
opendevreview | Danylo Vodopianov proposed openstack/nova master: Napatech SmartNIC support https://review.opendev.org/c/openstack/nova/+/859577 | 09:34 |
auniyal | hi dvo-plv, I am a newbie in Nova and have tried to review your patch some times, but it's seems complex. Will it be possible (if you consider) to break or segregate it into different relation patches? It might be helpful for others too. | 09:39 |
opendevreview | Danylo Vodopianov proposed openstack/os-vif master: Openvswitch driver was extended https://review.opendev.org/c/openstack/os-vif/+/859574 | 09:40 |
sean-k-mooney | auniyal: i dont really sea how you would split up dvo-plv's patches there are pretty small as is | 11:24 |
dvo-plv | I can move tests coverage into another patch and maybe some other features of it will be useful | 11:27 |
dvo-plv | if it will be useful* | 11:28 |
sean-k-mooney | test coverage should not be in diffent patches | 11:39 |
auniyal | sean-k-mooney ack | 11:45 |
opendevreview | Pierre Riteau proposed openstack/nova master: Fix a couple of typos https://review.opendev.org/c/openstack/nova/+/892300 | 11:54 |
opendevreview | sean mooney proposed openstack/nova master: introduce global greenpool https://review.opendev.org/c/openstack/nova/+/873061 | 12:28 |
opendevreview | sean mooney proposed openstack/nova master: introduce global greenpool https://review.opendev.org/c/openstack/nova/+/873061 | 12:51 |
*** d34dh0r5- is now known as d34dh0r53 | 13:09 | |
dansmith | gibi: can you re-+2 this? I forgot to update the log level in the test since you last saw: https://review.opendev.org/c/openstack/nova/+/891340 | 13:34 |
gibi | dansmith: done | 13:43 |
dansmith | thanks | 13:43 |
sean-k-mooney | hum interesting https://review.opendev.org/c/openstack/nova/+/873061?tab=change-view-tab-header-zuul-results-summary | 15:12 |
sean-k-mooney | so the devstack jobs all passed | 15:12 |
sean-k-mooney | all the leaked greentrheads are in 3 moudles nova.tests.unit.virt.libvirt nova.tests.unit.test_service.TestWSGIService and nova.tests.unit.test_wsgi.TestWSGIServer | 15:14 |
sean-k-mooney | the functionaltests are similar so its proably that the relevent code that is leakign the greenthreads is shared. | 15:15 |
gibi | nova weekly meeting will start here in 10 minutes. I will be your host today and I try to do a quick meeting. | 15:50 |
gibi | #startmeeting nova | 16:00 |
opendevmeet | Meeting started Tue Aug 22 16:00:59 2023 UTC and is due to finish in 60 minutes. The chair is gibi. Information about MeetBot at http://wiki.debian.org/MeetBot. | 16:00 |
opendevmeet | Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. | 16:00 |
opendevmeet | The meeting name has been set to 'nova' | 16:00 |
auniyal | \o | 16:01 |
gibi | o/ | 16:01 |
sean-k-mooney | o/ | 16:01 |
dansmith | o/ | 16:01 |
gmann | o/ | 16:01 |
dansmith | when does bauzas get back? 2024? | 16:01 |
sean-k-mooney | i think monday | 16:01 |
sean-k-mooney | but i didnt check whcih year | 16:01 |
dansmith | "Monday, 2024" | 16:01 |
gibi | yepp 28th of Aug he is back | 16:02 |
gibi | so you will get rid of me being the chair after this meeting :) | 16:02 |
gibi | lets start | 16:03 |
gibi | #topic Bugs (stuck/critical) | 16:03 |
gibi | I don't see any critical bug | 16:03 |
gibi | #link https://bugs.launchpad.net/nova/+bugs?search=Search&field.status=New 43 new untriaged bugs (+3 since the last meeting) | 16:03 |
gibi | #info bug baton is on PTO (bauzas please pass it forward after the summer period) | 16:03 |
gibi | is there any bugs we need to discuss? | 16:04 |
andrewbonney | If anyone could assess https://bugs.launchpad.net/nova/+bug/2023035 it would be appreciated as it's blocking us upgrading to 2023.1 without using old config workarounds | 16:04 |
opendevreview | Merged openstack/nova master: Log excessive lazy-loading behavior https://review.opendev.org/c/openstack/nova/+/891340 | 16:05 |
dansmith | \o/ | 16:05 |
gibi | andrewbonney: I see you know about the workaround | 16:06 |
andrewbonney | Yeah, just doesn't feel ideal if it's easily patchable | 16:07 |
gibi | andrewbonney: I did not look deeper but it seems the one of the recent comment shows what is the difference between the two host cpus | 16:07 |
dansmith | isn't this a libvirt thing anyway? | 16:07 |
gibi | could be | 16:08 |
dansmith | I guess it says libvirt version is the same on both ends, so hmm | 16:08 |
gibi | `cpu_mode = host-model` so I guess it is difference between the model | 16:08 |
dansmith | maybe we could get kashyap to look at this | 16:09 |
andrewbonney | We'd be happy to provide any other debug if it's useful | 16:09 |
sean-k-mooney | there are many factor that can cause it to fail | 16:09 |
sean-k-mooney | do you have diffent kernel version on the diffent hosts | 16:10 |
sean-k-mooney | this kid of sound like perhaps some of the mitigations that are enabeld are not the same on both | 16:10 |
andrewbonney | The testing we did found that the running XML for a guest failed in the virsh hypervisor-cpu-compare on the same host it was running on | 16:10 |
andrewbonney | Where cpu-compare worked | 16:11 |
sean-k-mooney | and do you have the patchs that we mreged recently to update how we did the cpu compatiblity checks | 16:11 |
andrewbonney | This was using b9089ac from 2023.1 | 16:12 |
sean-k-mooney | namely https://review.opendev.org/c/openstack/nova/+/869950 | 16:12 |
andrewbonney | Yes, we think that caused it | 16:12 |
sean-k-mooney | ok that should be in that then | 16:12 |
gibi | OK. I will ask kashyap to look at it when he is back | 16:13 |
sean-k-mooney | well that is usign the new api | 16:13 |
sean-k-mooney | that the libvirt folks told use to use | 16:13 |
dansmith | andrewbonney: is it simple to just revert that patch from what you have to see? | 16:13 |
andrewbonney | Yes I could do that tomorrow and update the bug, but given what we tested with virsh command line I think it proves it already | 16:14 |
dansmith | but yeah, we probably need to dig deeper if this is the new api we're supposed to be using and it's not doing what we want.. not sure if that means we need to do something different or not | 16:14 |
andrewbonney | It felt like the guest XML that was being put into the new API was wrong, but I don't know libvirt enough to be sure | 16:14 |
dansmith | but kashyap would probably be a good person to chase that down | 16:14 |
andrewbonney | Thanks. Don't want to take up all your meeting time :) | 16:14 |
gibi | OK, moving on | 16:15 |
gibi | any other bug to discuss? | 16:15 |
gibi | #topic Gate status | 16:16 |
dansmith | definitely improving | 16:16 |
gibi | glad to hear that | 16:16 |
dansmith | one of my patches merged today with a single +W and no rechecks | 16:16 |
dansmith | which was pretty shocking :) | 16:16 |
gibi | we also merged one functional improvement https://review.opendev.org/c/openstack/nova/+/892126 | 16:17 |
gibi | hopefully that will help too | 16:17 |
dansmith | yeah, which sounds like may have more impact than it appears, which is cool | 16:17 |
dansmith | I'll be looking for functional failures in the gate queue once that has soaked for a while | 16:18 |
gibi | I will check the functional results later this week to see if the common issues are disappeared or not | 16:18 |
gibi | yeah | 16:18 |
gmann | yeah, hopefully it does not go worst during release time, current gate stability is much better | 16:18 |
dansmith | yep, and if we can get some +Ws on these, they'll further reduce some of our runtime loading: https://review.opendev.org/q/topic:reduce-lazy-loads | 16:18 |
dansmith | during periods of high load, it can take a bit to execute a lazy load, and it's all unnecessary | 16:19 |
dansmith | but yeah, summary is we're in a much better place than we were.. not enough to consider it done, but enough to not be very fearful of release time I think :) | 16:20 |
gibi | yepp, those are easy wins | 16:20 |
gibi | #info Please look at the gate failures and file a bug report with the gate-failure tag. | 16:20 |
sean-k-mooney | i can try and take a look at them | 16:20 |
gibi | moving on | 16:21 |
gibi | #topic Release Planning | 16:21 |
gibi | we have 2 weeks before Feature Freeze | 16:21 |
gibi | I expect bauzas will start a feature tracking pad as soon as he is back | 16:22 |
gibi | any features we need to discuss here? | 16:22 |
gibi | then moving on | 16:24 |
gibi | #topic Stable Branches | 16:24 |
gibi | elodilles_pto is off | 16:24 |
gibi | is there any stable topic to discuss? | 16:25 |
gibi | #topic Open discussion | 16:26 |
gibi | nothing on the agenda | 16:26 |
opendevreview | Spencer Harmon proposed openstack/nova master: libvirt tsc_frequency https://review.opendev.org/c/openstack/nova/+/891924 | 16:26 |
gibi | any other topics to bring up? | 16:26 |
kgube | Yes | 16:27 |
gibi | go ahead | 16:27 |
kgube | I sould have mentioned this with the features maybe | 16:27 |
gibi | no worries | 16:27 |
kgube | I'm still working on the NFS online resize feature | 16:27 |
sean-k-mooney | didnt we say no to exposing the tsc_frequency in the past... | 16:28 |
spencerh` | Sorry for noise; didn't mean to interrupt. Trying to get tests working. Maybe a topic for next week? | 16:28 |
kgube | And there is a change for nova that has open dependencies in Cinder: https://review.opendev.org/c/openstack/nova/+/873560 | 16:29 |
kgube | So bauzas listed it as "Action from owner required" in the feature tracking pad | 16:30 |
sean-k-mooney | kgube: so that likely will have to be next cycle | 16:30 |
dansmith | kgube: is tere a nova spec for that side? | 16:30 |
kgube | yes | 16:30 |
sean-k-mooney | it was not approved this cycle i think | 16:30 |
kgube | the spec has been merged | 16:30 |
sean-k-mooney | maybe last cyle | 16:30 |
dansmith | okay I can't find it | 16:30 |
sean-k-mooney | oh it was | 16:31 |
kgube | https://review.opendev.org/c/openstack/nova-specs/+/877233 | 16:31 |
sean-k-mooney | https://specs.openstack.org/openstack/nova-specs/specs/2023.2/approved/use-extend-volume-completion-action.html | 16:31 |
gibi | https://review.opendev.org/c/openstack/nova-specs/+/877233 | 16:31 |
dansmith | got it, wrong topic | 16:31 |
kgube | Anyway, the Cinder team has been slow with reviews | 16:32 |
gibi | does the nova side of this breaks anything without the cinder dependency? | 16:32 |
sean-k-mooney | ok well we can review what is the status of the cinder side | 16:32 |
sean-k-mooney | i dont belive so | 16:32 |
kgube | The is a +1, but not from the core | 16:32 |
dansmith | if the cinder side isn't going to be merged ASAP, I think we probably need to punt | 16:32 |
dansmith | and not waste time reviewing the nova side in the last two weeks | 16:32 |
kgube | hm, okay | 16:32 |
gibi | I agree | 16:33 |
sean-k-mooney | so if we merged the nova code the cinder volume would never be in extending so it would not break anything but i also dont like ahvign dead code espeicly when it has an api microverion | 16:34 |
sean-k-mooney | so ya i think we would likely want to merge both in the same release | 16:35 |
sean-k-mooney | strictly speaking old nova and new cinder or old cinder and new nova shoudl work with each other | 16:35 |
dansmith | yeah, but since it requires an api change, | 16:36 |
dansmith | I think we should not presumptively merge this because cinder might change their definition of what the event means, when it comes, etc and then we end up with a thing we have to technically support for no reason | 16:36 |
sean-k-mooney | + compute service change and min version check | 16:36 |
kgube | It's a bit frustrating because the Cinder change has been ready for review for weeks, and even on top of their feature tracking etherpad: https://etherpad.opendev.org/p/cinder-2023.2-bobcat-features | 16:36 |
dansmith | I think we've always expected these to merge in the dependent service first | 16:36 |
kgube | but I guess they have been very busy | 16:37 |
dansmith | sean-k-mooney: right, there are REST API changes, implicit RPC ones, service versions, etc | 16:37 |
sean-k-mooney | certenly with neutron we have | 16:37 |
dansmith | kgube: yeah, I definitely understand your frustration | 16:37 |
gibi | kgube: yes, this is frustrating | 16:37 |
sean-k-mooney | kgube: do you have depends on or tempest/devestack covergae to show this working by any chance | 16:37 |
sean-k-mooney | this is feeling more like an early pre milestone 1 type of change then the next two weeks | 16:38 |
sean-k-mooney | but if you have already staged the patches with depends on and can show this working in ci then that more compleing | 16:39 |
kgube | sean-k-mooney: It is covered by the existing online volume extend tests if you run them on an affected driver | 16:39 |
dansmith | no devstack change that I see | 16:39 |
sean-k-mooney | we do not have a cinder nfs job in novas gate | 16:40 |
dansmith | kgube: right, but we need to see them running against the proper driver and this change | 16:40 |
sean-k-mooney | the depend on relation ship si not quite right althoguh its close | 16:40 |
dansmith | I guess the nfs job on this patch maybe? https://review.opendev.org/c/openstack/cinder/+/873889/7?tab=change-view-tab-header-zuul-results-summary | 16:40 |
kgube | There is a devstack-nfs job | 16:40 |
sean-k-mooney | https://review.opendev.org/c/openstack/cinder/+/873686/9 woudl be the patch to make the nfs driver work | 16:40 |
dansmith | that patch has depends-on relationships to cinder itself, which is weird | 16:41 |
sean-k-mooney | ya so that patch should depend on either the nova patch | 16:41 |
sean-k-mooney | ro the nova patch should ideally depend on it | 16:41 |
dansmith | well, not reall,y | 16:41 |
dansmith | because you need to run a cinder patch to see that job | 16:42 |
sean-k-mooney | the nova patch depens on the cinder client patch which depends on https://review.opendev.org/c/openstack/cinder/+/873557/8 | 16:42 |
dansmith | it looks like every patch in the stack depends on the thing below it or something? | 16:42 |
dansmith | confusing | 16:42 |
dansmith | this one depends on the nova patch: https://review.opendev.org/c/openstack/nova/+/873560 | 16:42 |
sean-k-mooney | ya that will work but its not how its ment to be used | 16:42 |
dansmith | and the top cinder one depends on that one | 16:42 |
dansmith | so it's a bit convoluted | 16:42 |
sean-k-mooney | oh the netapp one | 16:42 |
dansmith | anyway kgube disconnected | 16:42 |
sean-k-mooney | ya so the issue is that the api change patch is first | 16:42 |
dansmith | so we can probably end it here and discuss later | 16:43 |
sean-k-mooney | and then the driver patches ar after that | 16:43 |
sean-k-mooney | sure | 16:43 |
gibi | OK | 16:43 |
gibi | is the any other topic before we close? | 16:43 |
kgube | sorry, I got disconnected | 16:44 |
dansmith | kgube: we were just deciphering the patch dependency network to figure out how to see a job running the whole stack | 16:44 |
dansmith | which I think is there, but it's convoluted | 16:44 |
dansmith | either way I think the answer is the same :/ | 16:44 |
kgube | yeah, I was afraid of that | 16:45 |
kgube | but I can understand it | 16:45 |
sean-k-mooney | i dont know if cinder has the same policy as nova | 16:45 |
sean-k-mooney | but for nova we merge the api change last in a series | 16:46 |
sean-k-mooney | so the fact that is first in the cidner one is also a little odd | 16:46 |
gibi | I don't see any other topic being raised. So I will close the meeting and you can continue untangling the dep tree on the channel | 16:47 |
kgube | Well the nova change needs the new volume action | 16:47 |
gibi | #endmeeting | 16:47 |
opendevmeet | Meeting ended Tue Aug 22 16:47:15 2023 UTC. Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4) | 16:47 |
opendevmeet | Minutes: https://meetings.opendev.org/meetings/nova/2023/nova.2023-08-22-16.00.html | 16:47 |
opendevmeet | Minutes (text): https://meetings.opendev.org/meetings/nova/2023/nova.2023-08-22-16.00.txt | 16:47 |
opendevmeet | Log: https://meetings.opendev.org/meetings/nova/2023/nova.2023-08-22-16.00.log.html | 16:47 |
kgube | and everything else is dependent on the support in nova | 16:47 |
sean-k-mooney | also an fyi every time you use depends on it makes zuul clone an addtional copy of the relevent repo then it does a merge of all repos with the same name | 16:47 |
sean-k-mooney | so while you can use a depend on in the same repo in some cases its generally not a good idea as it causes a much more complex git merge to be done | 16:48 |
kgube | oh, okay, so I don't need them if the changes are already ordered in a branch | 16:49 |
kgube | ? | 16:49 |
dansmith | kgube: right, a single stack of patches are necessarily dependent and ordered | 16:49 |
dansmith | kgube: you do need them cross-repo (i.e. cinder->nova) but not within a single branch in cinder | 16:50 |
kgube | dansmith: alright, thanks! | 16:50 |
dansmith | also, the newer way to depends-on is to use a URL to the actual change, which also makes it easier for us to see "this is the nova dependency" | 16:50 |
dansmith | I thought zuul actually stopped supporting the change-id way, but I guess it still works (or at least the tagging does) | 16:50 |
kgube | that is also good to know. I kinda just copied it from other changes that I saw | 16:51 |
sean-k-mooney | the reason i mentioned the depend on mechanics is i have seen it cause merge conflict in the ci jobs that done repoduce locally | 16:52 |
sean-k-mooney | which can be very hard to debug | 16:52 |
dansmith | kgube: here's an example of how it should work these days: https://review.opendev.org/c/openstack/nova/+/650172 | 16:52 |
sean-k-mooney | i.e. using depend on in the same repo | 16:52 |
kgube | dansmith: thanks! | 16:53 |
spencerh` | sean-k-mooney: I am curious about the history with nova and libvirt tsc frequency. Is there a link to a discussion or is it possible to summarize concerns? Not expecting to get this in this cycle, but this patch has been critical for us. | 16:59 |
sean-k-mooney | kgube: the VolumesExtendAttachedTest test in tempest in the nfs job is skiped by hte way | 16:59 |
sean-k-mooney | kgube: so its not actully being tested by that job | 16:59 |
sean-k-mooney | spencerh`: bascially it comes done to the fact it will break live migration | 17:00 |
sean-k-mooney | we do not have the ablity to schdule based on the clock rate fo the hsot cpus | 17:00 |
sean-k-mooney | and if we allwo you to set the tsc_frequency via a host config option then we need rpc change to check comaptiablity | 17:01 |
spencerh` | The tsc frequency doesn't have to match the host capabilities on our cpus. Maybe that's vendor specific? | 17:01 |
sean-k-mooney | this is also not somethign that should chagne over the life time of the vm so it should not be a host level opation but rather an image property | 17:01 |
spencerh` | In my experience, it's the opposite: when invtsc is enabled, not setting tsc frequency will break live migration. | 17:01 |
sean-k-mooney | as far as ia am aware it cant exceed the host frequency on intel | 17:02 |
sean-k-mooney | a requicemnet if invtsc is that live migration is only supproted between hosts with the same frequesncy yes | 17:02 |
sean-k-mooney | and seting it in the xml is the workaroudn for aht | 17:02 |
sean-k-mooney | https://blueprints.launchpad.net/nova/+spec/config-tsc-freq | 17:02 |
sean-k-mooney | that is the blueprint that was propsed for adding invTSC orginally | 17:03 |
dansmith | spencerh`: I imagine anything like this will need a spec and discussion where we can make sure the experts in a given area have time to opine about such a change | 17:03 |
dansmith | spencerh`: so that's a good place to document the how and why, the impacts and other considerations | 17:04 |
spencerh` | Sounds good! Sorry, I'm not familiar with the spec process, but I'll be happy to talk about our environment and why we need this. Thanks for the background! | 17:04 |
kgube | sean-k-mooney, yeah, I will try to make a change that enables it in the job and make this dependent on the NFS driver support change. | 17:05 |
dansmith | spencerh`: https://specs.openstack.org/openstack/nova-specs/ | 17:05 |
spencerh` | dansmith: ty! | 17:06 |
sean-k-mooney | spencerh`: i started reviewing your code change by the way. you have a lot of random formatingin changes in it that should be remvoed | 17:06 |
spencerh` | Oh no. Probably because I enabled autopep8. I will fix | 17:06 |
sean-k-mooney | autopep8 shoudl not make these changes | 17:07 |
sean-k-mooney | we have it enabeld in ci | 17:07 |
spencerh` | Strange. Maybe my local instance is using different settings. There were fewer lines of diff before I messed it up this morning. I'll get that fixed. | 17:08 |
opendevreview | Spencer Harmon proposed openstack/nova master: libvirt tsc_frequency https://review.opendev.org/c/openstack/nova/+/891924 | 17:21 |
spencerh` | Looks better now. Sorry about that. (But no rush to review) | 17:23 |
sean-k-mooney | spencerh`: what is your usecase for enabeling the invtsc by the way | 18:35 |
sean-k-mooney | im just wonderign if the hpet provided by https://review.opendev.org/c/openstack/nova/+/605902 is enouch for your usecase of if you really need the tsc time source | 18:36 |
spencerh` | Haha it is very similar. I work at blizzard and we're running game servers on that have invtsc as a requirement (for lower latency/better performance). It's not windows specific, though. We're running various flavors of linux for the guests. | 18:38 |
spencerh` | Oh sorry. I conflated what you said with the spec. | 18:39 |
spencerh` | No, I don't think this will provide what's required for libvirt to live migrate with invtsc enabled. | 18:40 |
sean-k-mooney | yes we added invtsc and htpe for blizzard specicifcally in the past | 18:40 |
sean-k-mooney | right it does not i was asking can invtsc be disabled and use the hpet instead | 18:40 |
sean-k-mooney | the invtsc flag tells the guest tha tthe TSC is stable and wont change frequency | 18:41 |
spencerh` | I'll have to benchmark that to see if it solves the same issues that invtsc does. AFAIK, these are not fungible as far as the workload is concerned. | 18:41 |
sean-k-mooney | they gerneally shoudl be if the workload is not direfctly calling the TSC | 18:42 |
spencerh` | The workload does directly call the tsc. | 18:42 |
sean-k-mooney | the tsc is often used because its really fast to read | 18:42 |
sean-k-mooney | but its also generally not the most stable time source espcially in a vm | 18:42 |
sean-k-mooney | ack | 18:42 |
sean-k-mooney | dansmith: the lazy load serise all looks good overal. i had one of two nits inlien but they are all approved now | 19:34 |
sean-k-mooney | do you know off the top of your head what "trusted_certs" is used for in the instance. is that related to trusted boot? | 19:35 |
melwitt | sean-k-mooney: it's for this https://specs.openstack.org/openstack/nova-specs/specs/rocky/implemented/nova-validate-certificates.html | 19:51 |
sean-k-mooney | possibly but why would nova have the certs | 19:52 |
sean-k-mooney | i would expect that to be a propry of the image and there for in the instnace_system_metadata rather then the instance table | 19:53 |
sean-k-mooney | oh its form a join | 19:54 |
sean-k-mooney | ya its that | 19:54 |
sean-k-mooney | """This change will update the InstanceExtra schema to support a trusted_certs column, """ | 19:54 |
opendevreview | sean mooney proposed openstack/nova master: introduce global greenpool https://review.opendev.org/c/openstack/nova/+/873061 | 20:04 |
sean-k-mooney | i have 7 failing funcitonal tests i need to update but i think that is passing everythign else | 20:05 |
dansmith | sean-k-mooney: ack thanks | 20:11 |
opendevreview | Spencer Harmon proposed openstack/nova master: libvirt tsc_frequency https://review.opendev.org/c/openstack/nova/+/891924 | 22:45 |
opendevreview | Merged openstack/nova master: Avoid lazy-loading in resize and rebuild/evacuate https://review.opendev.org/c/openstack/nova/+/891336 | 22:54 |
opendevreview | melanie witt proposed openstack/nova master: Enable use of native threads in scatter_gather_cells https://review.opendev.org/c/openstack/nova/+/650172 | 23:53 |
Generated by irclog2html.py 2.17.3 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!