| opendevreview | Andrew Bogott proposed openstack/nova master: libvirt: add the purge_rbd_snaps_on_delete config option https://review.opendev.org/c/openstack/nova/+/843228 | 03:25 |
|---|---|---|
| opendevreview | Andrew Bogott proposed openstack/nova master: libvirt: add the purge_rbd_snaps_on_delete config option https://review.opendev.org/c/openstack/nova/+/843228 | 03:35 |
| opendevreview | Merged openstack/nova master: libvirt: Add a workaround to skip compareCPU() on destination https://review.opendev.org/c/openstack/nova/+/838926 | 04:55 |
| gibi | stephenfin: when you are around, can we discuss the config option open questions in https://review.opendev.org/c/openstack/nova-specs/+/791047 ? | 09:01 |
| stephenfin | gibi: Sure, on the review? | 09:09 |
| gibi | we can talk here :) | 09:10 |
| gibi | that is probably quicker | 09:10 |
| gibi | so my first question is | 09:10 |
| gibi | what is the reason behind you suggest no to rename the whitelist but add a totally new conf option? | 09:11 |
| stephenfin | Oh, I thought that was what you were proposing at the beginning | 09:12 |
| stephenfin | ...of the spec | 09:12 |
| * stephenfin looks again | 09:13 | |
| stephenfin | "The ``[pci]passthrough_whitelist`` config option will be deprecated for eventual removal and replaced with the new ``[pci]device_list`` config option."! | 09:13 |
| stephenfin | ^ that threw me | 09:14 |
| gibi | OK so we want to deprecate the old name | 09:14 |
| gibi | but keep the same config opt definition | 09:14 |
| gibi | (+ extend it with resource_class and traits) | 09:14 |
| stephenfin | Okay, gotcha. I misunderstood. Please ignore that comment so | 09:15 |
| gibi | cool | 09:15 |
| gibi | the other is about the naming of the new option | 09:15 |
| gibi | If I understand correctly you would like a singular name | 09:15 |
| gibi | but probably neither singular nor plural is fully correct | 09:15 |
| gibi | as a single entry in the device_list can match to zero, one, or multiple devices | 09:16 |
| gibi | OR we could try to name the option not from the matched device(s) perspective but from the filtering / matching perspective | 09:16 |
| gibi | i.e. device_spec device_filter | 09:17 |
| stephenfin | Yeah, I forgot that it would accept a list. That's a really awful option | 09:17 |
| stephenfin | device_spec or device_filter both wfm | 09:18 |
| stephenfin | so long as it's not device_list really :) | 09:18 |
| gibi | sean-k-mooney[m]: ^^ how do you feel about naming the device_list to [pci]device_spec or [pci]device_filter ? | 09:18 |
| gibi | stephenfin: thanks. | 09:19 |
| sean-k-mooney1 | i think device_filter was what i used in an older version | 09:31 |
| sean-k-mooney1 | so im ok with either device_spec or device_filter | 09:31 |
| gibi | cool | 09:33 |
| gibi | sean-k-mooney1, bauzas: the last thing is the CUSTOM_ prefix. I will keep the normalization and prefixing in the spec as is and we can re-discuss that during code / doc review if needed. | 09:34 |
| *** sean-k-mooney1 is now known as sean-k-mooney | 09:34 | |
| sean-k-mooney | gibi: ya im ok to defer that to the code review since bauzas's main ask was to document it properly | 09:35 |
| gibi | yepp, and also bauzas is on PTO for the rest of the week :) | 09:39 |
| gibi | I will update the config naming in the spec today | 09:39 |
| gibi | and then I will ask you and stephenfin to approve it:) | 09:40 |
| sean-k-mooney | ack :) | 09:42 |
| sean-k-mooney | one question | 09:42 |
| sean-k-mooney | do we want to add the json list support to the alas | 09:42 |
| sean-k-mooney | to have partity with the device_filter | 09:42 |
| * sean-k-mooney had just build up the finger memory for device_list | 09:43 | |
| sean-k-mooney | i personally woudl really like to not have to deal with the multiopt syntax but you dont have to fix that its just on my wishlist for some day | 09:44 |
| gibi | I think it is a better direction to get rid of the multiopt | 09:44 |
| gibi | but that is definitely something that is not in scope now | 09:45 |
| sean-k-mooney | right so not suggesting geting rid of the multiopt just allowing alias=[{...},{...}] | 09:46 |
| sean-k-mooney | but ok i can propose that as a specless blueprint some time | 09:46 |
| gibi | OK, I think the list part can be a separate small thing | 09:47 |
| stephenfin | If we got rid of MultiStrOpt, IMO we should look at what we did for the NUMA network affinity spec, where we dynamically generated configuration sections/options and flattened the list | 09:48 |
| sean-k-mooney | stephenfin: no i dont really like that either | 09:49 |
| sean-k-mooney | we could | 09:49 |
| sean-k-mooney | but it woudl be non trivial to do | 09:49 |
| sean-k-mooney | we dont have a name for thses to key off | 09:49 |
| sean-k-mooney | they are already json strings | 09:50 |
| gibi | didn't we had some race condition issues with dynamic opts? | 09:50 |
| stephenfin | [pci] device_specs = foo, bar | 09:50 |
| sean-k-mooney | just supproting json lists simes simpel | 09:50 |
| stephenfin | [device_spec_foo] vendor_id = ffff product_id = ffff | 09:50 |
| sean-k-mooney | stephenfin: right we dont have the foo and bar names today | 09:50 |
| stephenfin | ah yeah, you'd invent them | 09:50 |
| sean-k-mooney | we would have to just add them for the sake fo the option | 09:50 |
| sean-k-mooney | for the alias that totally works | 09:51 |
| stephenfin | Just arbitrary identifiers. Very easy to script | 09:51 |
| stephenfin | Anyway, nothing to do with this spec | 09:51 |
| sean-k-mooney | you know it will end up being 001 002 003] | 09:51 |
| sean-k-mooney | #but ya | 09:51 |
| stephenfin | changing the topic, why does the vIOMMU model have to be configurable? | 09:51 |
| stephenfin | other than MOAR PWR!!!?! | 09:51 |
| stephenfin | :) | 09:52 |
| sean-k-mooney | its simpler then dealing with having to doublel escape them in the local.conf for sure | 09:52 |
| sean-k-mooney | stephenfin: because i think it changes the kernel driver in the guest | 09:52 |
| sean-k-mooney | the same way virtio vs e1000 does for nics or cirrus vs qxl for video_model | 09:52 |
| sean-k-mooney | if it was next year i would porbaly have said just use virtio and be done with it | 09:53 |
| stephenfin | and we're thinking someone would want to use != virtio nowadays | 09:53 |
| stephenfin | ? | 09:53 |
| sean-k-mooney | well no distro i know of ships with virtio suppoprt | 09:53 |
| stephenfin | as in libvirt version? | 09:53 |
| sean-k-mooney | as in qemu version but ya | 09:54 |
| sean-k-mooney | i would have to check 22.04 and rhel 9 | 09:54 |
| sean-k-mooney | but that is very new | 09:54 |
| stephenfin | libvirt *and* qemu version | 09:54 |
| sean-k-mooney | libvirt 8.3.0 | 09:55 |
| sean-k-mooney | not sure about the qemu version | 09:55 |
| stephenfin | pity :( | 09:55 |
| sean-k-mooney | initally i was also just hoping for hw:viommu=True|False | 09:55 |
| stephenfin | would it be crazy to at least set a sane default (i.e. virtio if libvirt >= 8.3.0)? | 09:55 |
| stephenfin | yeah, me too | 09:56 |
| sean-k-mooney | if you want we coudl add hw:viommue=True|False and have it set it automatically | 09:56 |
| stephenfin | also, do we want an extra spec for this. We don't traditionally do extra specs for hardware stuff | 09:56 |
| sean-k-mooney | but we likely need a way to override | 09:56 |
| stephenfin | I'd rather 'hw:viommu_model=auto' | 09:56 |
| sean-k-mooney | im fine with that | 09:57 |
| stephenfin | if we go that route and we are not turning on vIOMMU by default | 09:57 |
| stephenfin | (why are we not doing that too btw?) | 09:57 |
| sean-k-mooney | well ya i dont think we shoudl trun it on by default | 09:57 |
| sean-k-mooney | turning it on by defaul? | 09:57 |
| sean-k-mooney | i think it has negitive performance impact if you are using pci passthough | 09:57 |
| sean-k-mooney | and it also increase memory usagein the guest | 09:58 |
| sean-k-mooney | so it can break things | 09:58 |
| stephenfin | So not quite a free lunch. Pity. It would be good to note that in the spec | 09:58 |
| sean-k-mooney | stephenfin: to be clear our virt team told us not to bother enableing it because of the perfroamce impact of the intel viommu for sriov | 09:59 |
| stephenfin | TIL. Yeah, definitely one to note on the spec | 09:59 |
| stephenfin | Last one, do we actually want an extra spec for this? We don't traditionally do extra specs for hardware stuff | 10:00 |
| sean-k-mooney | right normlaly it hsould be image only | 10:01 |
| sean-k-mooney | we have broken that a few times now with the vtpm and vpmu extra specs | 10:01 |
| sean-k-mooney | so at this point im kind of ok with it | 10:01 |
| sean-k-mooney | if the guest does not have the driver the iommu will just not get used by the kernel in the guest i belive | 10:02 |
| sean-k-mooney | but i have not tested that | 10:02 |
| opendevreview | Balazs Gibizer proposed openstack/nova master: Accept both 1 and Y as AMD SEV KVM kernel param value https://review.opendev.org/c/openstack/nova/+/843254 | 10:04 |
| gibi | sean-k-mooney: this is a fix for what James saw the other day downstream ^^ | 10:04 |
| sean-k-mooney | ah nice | 10:09 |
| sean-k-mooney | gibi: can we not use the oslo stringutils str to bool function | 10:11 |
| sean-k-mooney | i think that woudl be better | 10:11 |
| gibi | sure, why not | 10:13 |
| sean-k-mooney | bool_from_string | 10:13 |
| sean-k-mooney | basiclaly whhen it becomes YES or true | 10:13 |
| sean-k-mooney | i dont want to have to fix it again | 10:13 |
| gibi | good point | 10:16 |
| gibi | I will respin in a sec | 10:16 |
| opendevreview | Balazs Gibizer proposed openstack/nova master: Accept both 1 and Y as AMD SEV KVM kernel param value https://review.opendev.org/c/openstack/nova/+/843254 | 10:18 |
| sean-k-mooney | by the way i noticed this change on more recent kernels | 10:18 |
| sean-k-mooney | it seam all module parmater changed form 1 to y somewhwer around 5.10 ish | 10:18 |
| gibi | I just checked mine and there it was Y | 10:18 |
| sean-k-mooney | not sure exacatly where but i noticed it for say nested_vert for example | 10:18 |
| gibi | hum in 5.4 it is still 1/0 | 10:19 |
| sean-k-mooney | yep | 10:19 |
| sean-k-mooney | so i think the kernel made this change globally at some poitn | 10:19 |
| sean-k-mooney | 1/0 still works | 10:19 |
| sean-k-mooney | it just now reports y/n | 10:19 |
| sean-k-mooney | in sysfs | 10:20 |
| sean-k-mooney | i guess libvirt is just doing a raw passthough and not normalising | 10:20 |
| gibi | hm, it is module dependent, I see modules reporting 0 on 5.17 | 10:20 |
| sean-k-mooney | oh ok | 10:20 |
| sean-k-mooney | maybe a style change | 10:20 |
| gibi | yeah | 10:20 |
| gibi | OK , switched thet patch to strutils, thanks for noticing it | 10:22 |
| sean-k-mooney | ill review it shortly just updating the iommu spec | 10:22 |
| gibi | thanks | 10:23 |
| sean-k-mooney | +2 by the way we will need to backport this to whenever we added sev support right | 10:33 |
| sean-k-mooney | stephenfin: if you want to propsoe adding auto as a model please do i have no real objection to that | 10:35 |
| stephenfin | will do | 10:35 |
| sean-k-mooney | did you have any other outstanding questions | 10:35 |
| sean-k-mooney | we are agreed on useign 48 for the bit with right | 10:36 |
| sean-k-mooney | if libvirt is knew enough | 10:36 |
| sean-k-mooney | i think that was the only other thing pending on the spec | 10:36 |
| sean-k-mooney | well the last version was updated to say we would | 10:37 |
| gibi | sean-k-mooney: sure I will do the backports | 10:37 |
| opendevreview | Rajesh Tailor proposed openstack/nova master: Fix typos https://review.opendev.org/c/openstack/nova/+/843127 | 11:27 |
| sean-k-mooney | i feel philosophically oblidged to not review ^ :) | 11:33 |
| opendevreview | Balazs Gibizer proposed openstack/nova-specs master: PCI device tracking in Placement https://review.opendev.org/c/openstack/nova-specs/+/791047 | 11:49 |
| gibi | stephenfin, sean-k-mooney, bauzas: I think all the open questions are resolved now ^^ | 11:50 |
| sean-k-mooney | ack im currntly truning some wifi setting so i might loose connectivity for a bit but ill take a look later today | 11:54 |
| sean-k-mooney | ok that might have stablised. | 11:57 |
| sean-k-mooney | it was till repovisioning | 11:57 |
| opendevreview | Ade Lee proposed openstack/nova master: Test setting the nova job to centos-9-stream https://review.opendev.org/c/openstack/nova/+/831844 | 12:59 |
| kashyap | gibi: This can be interesting: https://bugs.launchpad.net/nova/+bug/1975711. I can reproduce that too; on a fresh checkout on F36, re-run (not the first run) `tox -v pep8` is taking 3 *minutes* | 13:12 |
| sean-k-mooney | kashyap: im not sure this is really a valid nova bug | 13:14 |
| sean-k-mooney | this seams like its more a tox/pip issue | 13:15 |
| kashyap | sean-k-mooney: Apparently this can be fixed in Nova, see Miguel's comment there: | 13:15 |
| kashyap | [quote] | 13:15 |
| kashyap | [/quote] | 13:15 |
| kashyap | Doing this means slightly refactoring how requirements are defined in the project. I'm working on a draft patch to show what that would look like and will create a review soon. | 13:15 |
| kashyap | He used 'pip-compile' to sort this out | 13:15 |
| sean-k-mooney | right there fix is not really valid | 13:15 |
| sean-k-mooney | it change how we test | 13:15 |
| sean-k-mooney | and what we are testing | 13:16 |
| gibi | still I guess somewhere we have some problems in the transitive dependencies as pip get stuck, while normally pip does not get stuck on a simple pep8 setup | 13:16 |
| gibi | I agree with sean-k-mooney not to blindly alter our test process by pinning requirements. I suggest to try to find the offending dependency and try to figure out what makes it hard for pip to resolve the deps | 13:17 |
| sean-k-mooney | if we were to fix this in nova we woudl have to delete and recreate the pinned deps every time we run tox | 13:17 |
| kashyap | sean-k-mooney: I wouldn't be too quick to dismiss the fix without actually looking at the problem and properly understanding it. | 13:17 |
| sean-k-mooney | and we would have to ensure that pip-compile follows UC and test-requirement properly | 13:17 |
| kashyap | gibi: Yeah, I think I should have a trace of one of the offending deps ... lemme check | 13:18 |
| sean-k-mooney | kashyap: im not im pointing out that they probaly dont fully understand how we test and what | 13:18 |
| sean-k-mooney | we require form a pti point of view | 13:18 |
| sean-k-mooney | so we need to actully see if its pti compleint and test wat we want ti to test | 13:18 |
| kashyap | sean-k-mooney: Ah, sure. I don't deny that. (Aside, what is "pti"?) | 13:19 |
| sean-k-mooney | project testing interface | 13:19 |
| sean-k-mooney | kashyap: https://github.com/openstack/governance/blob/master/reference/pti/python.rst specificly | 13:19 |
| kashyap | gibi: E.g. for me it got stuck at this "decorator" thing: https://paste.opendev.org/show/baNIMuM5YxlBA8nwxm10/ | 13:20 |
| sean-k-mooney | defien how all offical python project must do there testing | 13:20 |
| sean-k-mooney | kashyap: it likely will not be stable in all caes | 13:20 |
| sean-k-mooney | basicaly as release happen you might see that change | 13:21 |
| gibi | kashyap: so the next step would be to compare the pip run on f35/36 with a non-stuck pip run on ubuntu 2004 | 13:21 |
| gibi | maybe with a run from our gate | 13:21 |
| sean-k-mooney | its porbaly python3.10 vs 3.9 really | 13:21 |
| kashyap | gibi: But it's also non-deterministic for me; "eventually" it went ahead and succeeded | 13:21 |
| kashyap | sean-k-mooney: You're using 3.9? | 13:21 |
| gibi | sean-k-mooney: stilly p310 not stuck on my debian | 13:21 |
| sean-k-mooney | the odd thing is im pretty sure it work for me on 3.9 and 3.10 | 13:21 |
| sean-k-mooney | ya i think 3.10 worked for me too | 13:22 |
| sean-k-mooney | kashyap: i have 3.8 3.9 and 3.10 | 13:22 |
| gibi | so this can be pip cache (need a clean VM to reproduce) already globally installed python deps | 13:22 |
| sean-k-mooney | i normlaly use 3.8 since its supported on the most set of branches | 13:22 |
| kashyap | (I'm using 3.10 too; FWIW) | 13:22 |
| sean-k-mooney | kashyap: just so you know 3.10 is not supported yet | 13:22 |
| sean-k-mooney | as in its experimental for zed | 13:23 |
| sean-k-mooney | https://github.com/openstack/governance/blob/master/reference/runtimes/zed.rst#python-runtimes-for-zed= | 13:23 |
| kashyap | gibi: sean-k-mooney: Sorry, I was lying! I was using 3.8.13, actually | 13:23 |
| sean-k-mooney | so its nice that you are using it but we do not expect it to work in all cases. | 13:24 |
| sean-k-mooney | kashyap: you are gettign that failure on 3.8 | 13:24 |
| kashyap | Yep | 13:24 |
| sean-k-mooney | hum maybe its related to the distro packages then | 13:24 |
| kashyap | It's not deterministic. So I don't want to take your time much on it. | 13:24 |
| sean-k-mooney | our your pip version | 13:24 |
| sean-k-mooney | what version of pip have you installed | 13:24 |
| kashyap | sean-k-mooney: It's in a tox env. And I'm using "pip 22.1.1" | 13:24 |
| kashyap | But for now, it's "magically resolved" after a couple of runs. I haven't even recreated 3.8 tox env. | 13:25 |
| sean-k-mooney | pip 22.0.4 from /home/sean/repos/openstack/nova/.tox/py3/lib/python3.10/site-packages/pip (python 3.10) | 13:25 |
| sean-k-mooney | it could be reelated to the version of setuptool/pip that is bundeled in vitrualenv | 13:26 |
| sean-k-mooney | that is where the version used by tox come form by default | 13:26 |
| sean-k-mooney | i belive you can specify the version when creating the tox env | 13:26 |
| opendevreview | Andrew Bogott proposed openstack/nova master: libvirt: add the purge_rbd_snaps_on_delete config option https://review.opendev.org/c/openstack/nova/+/843228 | 13:27 |
| sean-k-mooney | you might be able to pass tox -e py3 --force-dep pip\<22.1 | 13:30 |
| sean-k-mooney | kashyap: can you try ^ | 13:31 |
| sean-k-mooney | there is also a plugin for this apprently https://pypi.org/project/tox-pip-version/ but dont know if it work but it would be interesting to see if that helps | 13:31 |
| sean-k-mooney | kashyap: do you install tox form pypi by the way | 13:32 |
| kashyap | sean-k-mooney: Is that verbatim syntax correct? "\<" | 13:32 |
| sean-k-mooney | or are you using it form fedora | 13:32 |
| sean-k-mooney | \< was to escape the < | 13:32 |
| sean-k-mooney | so it shoudl be pip<22.1 | 13:32 |
| sean-k-mooney | but i think you need to escape it on a bash cli | 13:32 |
| kashyap | In this case both versions are same: 3.25. And I've used 'tox' from system in this case | 13:33 |
| sean-k-mooney | ok i always use it form pypi to normalise behavior between the distors im using | 13:33 |
| * kashyap nods | 13:33 | |
| kashyap | sean-k-mooney: Also, did you mean "py3" there? | 13:34 |
| sean-k-mooney | yes | 13:34 |
| sean-k-mooney | py3 uses your default python 3 | 13:34 |
| sean-k-mooney | so i use that to not have to care which python3 that is | 13:34 |
| kashyap | Nod; /me tries | 13:34 |
| kashyap | python-dep-hell-- | 13:36 |
| sean-k-mooney | hehe well this seams to be disto specific so not sure its entirly fair | 13:36 |
| sean-k-mooney | at least its not nodejs | 13:37 |
| sean-k-mooney | npm is just awfull | 13:37 |
| sean-k-mooney | its like javascript libs compeet to see how many other libs they can use before they create a cycle | 13:37 |
| dansmith | the js community is insane :) | 13:38 |
| dansmith | I've never had problems resolving deps with npm, but probably just haven't done it enough | 13:38 |
| kashyap | sean-k-mooney: Still, I hate this system pkgs vs PyPi interaction hell. It's been behind me for years; I keep hoping it gets better :D | 13:38 |
| kashyap | dansmith: You're a brave man; this chanel is recorded, you know that, right :D | 13:38 |
| sean-k-mooney | dansmith: depresovling is fine but packaging that as a distro is just not really possible | 13:38 |
| dansmith | kashyap: I think they know they have a problem :) | 13:38 |
| dansmith | sean-k-mooney: yeah totally | 13:39 |
| sean-k-mooney | honestly the best that disto can do is provde a way to install npm and then let it do the rest | 13:39 |
| dansmith | yup and I kinda expect that's where we're headed with python too | 13:40 |
| sean-k-mooney | ya perhaps. go too for what its worth | 13:40 |
| dansmith | I'm sure | 13:40 |
| sean-k-mooney | in the past lanauges did not have a packagem manager but now its the default for them too | 13:40 |
| sean-k-mooney | they had been always thrid party in c/c++/java | 13:41 |
| sean-k-mooney | it does make cve much harder to manage but on the other hand if you fix it in the "comunity/language" package manage you fix it for all distos that use that | 13:42 |
| dansmith | it totally makes the security landscape a disaster, | 13:42 |
| dansmith | but I think npm integrates vulnerability tagging with the package manager itself, which is probably good | 13:43 |
| sean-k-mooney | kashyap: by the way if this is blocking you crrently you might want to use a podman contianer or vm temporaly to workaround it | 13:46 |
| sean-k-mooney | you could also try the pip-compile approch | 13:46 |
| kashyap | sean-k-mooney: It's not quite blocking me; but annoying. Right, for now I'm resorting to a clean container approach. I'll check 'pip-compile' later | 13:47 |
| sean-k-mooney | and perphaps protoype a tox change | 13:47 |
| kashyap | Thakns! | 13:47 |
| kashyap | For now, I'm just not using Py3.10. I have a row of yaks to shave before I head out for the long PTO | 13:50 |
| kashyap | Thx for your debugging help. | 13:50 |
| erlon | Hi folks, can you please give a push on these 2 patches? They are clean cherry-picks and just need 1 mode +2: | 14:08 |
| erlon | https://review.opendev.org/c/openstack/nova/+/836015 | 14:08 |
| erlon | https://review.opendev.org/c/openstack/nova/+/838550/3 | 14:08 |
| sean-k-mooney | bauzas: dansmith ^ can you take a look at those or add me/gibi to the stable group wand we can. the backport is valid in my view and melwitt is +2 on both | 14:12 |
| sean-k-mooney | actully elodilles if you are about you might be abel to help with those stabel reviews | 14:15 |
| elodilles | sean-k-mooney: looking | 14:19 |
| elodilles | erlon: they look good to me, +2+W'd them | 14:28 |
| erlon | elodilles: thanks! | 14:29 |
| elodilles | erlon: thanks for proposing the backport! | 14:29 |
| opendevreview | Balazs Gibizer proposed openstack/nova master: WIP: skeleton for asserting PCI resources in Placement https://review.opendev.org/c/openstack/nova/+/843291 | 14:35 |
| opendevreview | Artom Lifshitz proposed openstack/nova stable/wallaby: DNM: Testing live migration with local attach https://review.opendev.org/c/openstack/nova/+/843146 | 14:45 |
| opendevreview | Merged openstack/nova stable/ussuri: Define new functional test tox env for placement gate to run https://review.opendev.org/c/openstack/nova/+/840771 | 15:25 |
| opendevreview | Merged openstack/nova stable/xena: Adds regression test for bug LP#1944619 https://review.opendev.org/c/openstack/nova/+/838550 | 15:25 |
| opendevreview | Ghanshyam proposed openstack/nova stable/victoria: DNM: testing Tempest pin in stable/victoria https://review.opendev.org/c/openstack/nova/+/843301 | 15:49 |
| opendevreview | Merged openstack/nova stable/xena: Fix pre_live_migration rollback https://review.opendev.org/c/openstack/nova/+/836015 | 16:14 |
| stephenfin | gibi: +2 on the PCI spec. Nice work | 16:33 |
| sean-k-mooney | melwitt: im doing a fully review fo the pci spec which is why its taking a while not just the detals | 17:15 |
| sean-k-mooney | so far all good | 17:15 |
| sean-k-mooney | but do you want me to levae the +w to you or will i send it on its way assuming im happy with it when i get to the end | 17:16 |
| melwitt | sean-k-mooney: no feel free to +W :) | 17:16 |
| sean-k-mooney | ack it shoudl be sitting in the zuul pipeline now | 17:26 |
| sean-k-mooney | ok im going to swap to my personal laptop and work on some minor patch updates so ill be off irc for the rest or the day. ill leave my client open but ill chat to people tomrrow | 17:28 |
| opendevreview | Miguel Lavalle proposed openstack/os-vif master: Delete trunk bridges to avoid race with Neutron https://review.opendev.org/c/openstack/os-vif/+/841499 | 17:32 |
| opendevreview | Erlon R. Cruz proposed openstack/nova stable/wallaby: Adds regression test for bug LP#1944619 https://review.opendev.org/c/openstack/nova/+/838332 | 17:33 |
| opendevreview | Erlon R. Cruz proposed openstack/nova stable/wallaby: Adds regression test for bug LP#1944619 https://review.opendev.org/c/openstack/nova/+/838332 | 17:36 |
| opendevreview | Merged openstack/nova-specs master: PCI device tracking in Placement https://review.opendev.org/c/openstack/nova-specs/+/791047 | 17:38 |
| opendevreview | Ghanshyam proposed openstack/nova stable/ussuri: DNM: Testing stable/ussuri with tempest fix for constraints mismatch https://review.opendev.org/c/openstack/nova/+/843046 | 18:12 |
| opendevreview | Artom Lifshitz proposed openstack/nova stable/xena: Reproduce live migration rollback w/o multi port bindings error https://review.opendev.org/c/openstack/nova/+/843336 | 18:51 |
| opendevreview | Artom Lifshitz proposed openstack/nova stable/xena: Fix LM rollback w/o multi port bindings extension https://review.opendev.org/c/openstack/nova/+/843337 | 18:52 |
| opendevreview | Artom Lifshitz proposed openstack/nova stable/wallaby: Reproduce live migration rollback w/o multi port bindings error https://review.opendev.org/c/openstack/nova/+/843338 | 18:52 |
| opendevreview | Artom Lifshitz proposed openstack/nova stable/wallaby: Fix LM rollback w/o multi port bindings extension https://review.opendev.org/c/openstack/nova/+/843339 | 18:52 |
| opendevreview | Miguel Lavalle proposed openstack/os-vif master: Delete trunk bridges to avoid race with Neutron https://review.opendev.org/c/openstack/os-vif/+/841499 | 21:33 |
| *** tosky_ is now known as tosky | 21:49 | |
Generated by irclog2html.py 2.17.3 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!