| opendevreview | Artom Lifshitz proposed openstack/nova master: Update PCI requests in request spec on resize https://review.opendev.org/c/openstack/nova/+/806049 | 00:39 |
|---|---|---|
| *** dasm|bbl is now known as dasm | 03:06 | |
| *** dasm is now known as dasm|off | 04:08 | |
| *** abhishekk is now known as akekane|home | 04:56 | |
| *** akekane|home is now known as abhishekk | 04:56 | |
| elodilles | melwitt: thanks! :) | 05:50 |
| opendevreview | Jorhson Deng proposed openstack/nova master: remove some redundant parameters in migrate_server https://review.opendev.org/c/openstack/nova/+/808143 | 07:12 |
| opendevreview | Jorhson Deng proposed openstack/nova master: remove some redundant parameters in migrate_server https://review.opendev.org/c/openstack/nova/+/808143 | 07:14 |
| EugenMayer | Hello, out of a 'sudden' when deploying a series of VMs ussing terraform on openstack (spawning a k8s cluster of 4 nodes) some of them (usually 1) stucks in 'spawning' mode in openstack. We did this about 50 times already before, so it was working flawlessly - but suddenly it broke. What tools would i have to understand why they are in the | 07:22 |
| EugenMayer | 'spawning' state and what hinders the VM to actually spawn? | 07:22 |
| gibi | bauzas: hi! prelude looks good to me. do we still wait for other +2s or should I just approve it | 08:17 |
| gibi | ? | 08:17 |
| gibi | EugenMayer: you have to track down what step that VM failed. I would first look at the conductor logs for error and the log of the nova-compute where the VM is scheduled to. | 08:19 |
| opendevreview | OpenStack Release Bot proposed openstack/placement stable/yoga: Update .gitreview for stable/yoga https://review.opendev.org/c/openstack/placement/+/832979 | 08:21 |
| opendevreview | OpenStack Release Bot proposed openstack/placement stable/yoga: Update TOX_CONSTRAINTS_FILE for stable/yoga https://review.opendev.org/c/openstack/placement/+/832981 | 08:21 |
| opendevreview | OpenStack Release Bot proposed openstack/placement master: Update master for stable/yoga https://review.opendev.org/c/openstack/placement/+/832983 | 08:21 |
| opendevreview | OpenStack Release Bot proposed openstack/placement master: Add Python3 zed unit tests https://review.opendev.org/c/openstack/placement/+/832985 | 08:21 |
| bauzas | gibi: hey, maybe we can hold it until noon | 08:25 |
| kashyap | Completely aside, TIL: with Py 3.7, "breakpoint()" is now an alternative to "import pdb ; pdb.set_trace()" | 08:25 |
| gibi | bauzas: OK | 08:28 |
| gibi | kashyap: ohh, nice. then I TIl that today too :) | 08:28 |
| bauzas | gibi: do you know if someone already provided a nova change for using the new grenade-skip-level job ? | 08:29 |
| bauzas | gibi: if no, I'll do it | 08:29 |
| kashyap | gibi: https://peps.python.org/pep-0553/ :) | 08:29 |
| kashyap | See the 4 points in the Rationale section | 08:30 |
| gibi | bauzas: I only see this https://review.opendev.org/q/topic:test-grenade-skip-level | 08:30 |
| gibi | that adds the job the check queue | 08:31 |
| EugenMayer | gibi thank you. Which logs would you look for on the conductor? | 08:31 |
| EugenMayer | gibi i think the candidate is https://gist.github.com/EugenMayer/db07bf3ecc8bad464afb0040700d644d | 08:33 |
| bauzas | gibi: oh right, I forgot about it | 08:36 |
| bauzas | https://review.opendev.org/c/openstack/tempest/+/830670/1/zuul.d/integrated-gate.yaml we test it for the whole integrated gate | 08:36 |
| gibi | EugenMayer: yeah that means that service could not communicate with keystone | 08:36 |
| EugenMayer | gibi are there somewhat rate limits or not? I guess it uses the LB to do that and it might be somewhat saturated. I could not understand why this suddently (but consistently) happens | 08:37 |
| gibi | EugenMayer: [Errno 113] EHOSTUNREACH seems to be a network connection error to me | 08:38 |
| EugenMayer | Seems so, but how could that happen out of a sudden, that's odd. Running xena with OVN here. | 08:39 |
| gibi | kashyap: I could have been the author of this PEP :) | 08:40 |
| kashyap | gibi: Haha, I'll believe you | 08:40 |
| gibi | forgetting the semicolon | 08:40 |
| gibi | that is typical :) | 08:41 |
| gibi | EugenMayer: I have not furter ideas what can cause that. I suggest you to troubleshoot your network infra. | 08:44 |
| EugenMayer | gibi well the entire infra is based on OVN / openstack .. that's my issue here. You assume asking over in neutron what could cause this, right? | 08:47 |
| EugenMayer | (or how to track it down) | 08:48 |
| gibi | EugenMayer: yeah you can try over there too | 08:48 |
| EugenMayer | Thank you! | 08:49 |
| EugenMayer | gibi isn't it odd alltogether that this happens, since the conductor is running on the controller itself? | 08:49 |
| EugenMayer | gibi even the load-balancer that it is offered via is running on the controller, the host where actually the conductor uns on | 08:50 |
| gibi | yeah it is definetly odd | 08:50 |
| bauzas | damn, we're playing against Zuul by now | 09:56 |
| bauzas | sean-k-mooney: we have 2 open bug reports for RC1 https://bugs.launchpad.net/nova/+bugs?field.tag=yoga-rc-potential that relate to https://review.opendev.org/c/openstack/nova/+/828570 | 09:58 |
| bauzas | sean-k-mooney: given I don't see your +2 for the main change, can we punt https://bugs.launchpad.net/nova/+bug/1949808 and https://bugs.launchpad.net/nova/+bug/1960412 off the RC1 ? | 09:59 |
| bauzas | humpf, this looks sad we no longer have translations https://review.opendev.org/q/topic:zanata%252Ftranslations | 10:07 |
| bauzas | last one we had was in ussuri https://review.opendev.org/c/openstack/nova/+/723160 | 10:07 |
| bauzas | my bad, xena | 10:08 |
| opendevreview | kiran pawar proposed openstack/nova master: VMware: Split out VMwareAPISession https://review.opendev.org/c/openstack/nova/+/832156 | 10:41 |
| opendevreview | kiran pawar proposed openstack/nova master: VMware: StableMoRefProxy for moref recovery https://review.opendev.org/c/openstack/nova/+/832164 | 10:41 |
| noonedeadpunk | hey there! I have issue that is kind of related to https://bugs.launchpad.net/nova/+bug/1778563 | 10:48 |
| noonedeadpunk | so mdev get re-crearted and allocated during migration. But I guess nothing has been done when compute host got rebooted? | 10:49 |
| noonedeadpunk | So with compute reboot mdev device are gone, so nova-compute jsut refuse to start | 10:50 |
| noonedeadpunk | with https://paste.openstack.org/show/b5m5sW2194PRjd2hLGtg/ | 10:50 |
| noonedeadpunk | so basically on nova-compute start we need to ensure that devices exist same way we do during migration I guess? | 10:51 |
| noonedeadpunk | it's on V just in case, so not sure maybe it's already fixed on later branches | 10:52 |
| gibi | noonedeadpunk: I think it is an open bug https://bugs.launchpad.net/nova/+bug/1900800 | 11:08 |
| noonedeadpunk | oh, mdevctl define, nice, thanks! | 11:10 |
| gibi | noonedeadpunk: happy to help :) | 11:11 |
| noonedeadpunk | gibi: I wonder if it's worth to mention it on https://docs.openstack.org/nova/latest/admin/virtual-gpu.html#caveats ? | 11:18 |
| gibi | noonedeadpunk: good point. I think it would be good to list it there. If you have time please push a small doc patch. | 11:19 |
| sean-k-mooney[m] | we dont currenlty use mdevctl and if we wer too we would have to basically re write how we do mdev management | 11:23 |
| sean-k-mooney[m] | today we expect nova to creat the medevs after a host reboot | 11:24 |
| sean-k-mooney[m] | when it recreates the vms | 11:24 |
| sean-k-mooney[m] | if we want to use mdev ctl in the future we need to strart tacking mdevs like pci devices or pmem | 11:24 |
| noonedeadpunk | but it doesn't? | 11:24 |
| noonedeadpunk | I mean - nova jsut crash | 11:25 |
| sean-k-mooney[m] | it should when you start the vm | 11:25 |
| sean-k-mooney[m] | the current bug is just that a bug | 11:26 |
| noonedeadpunk | hm... maybe it's result of resume_guests_state_on_host_boot then... | 11:26 |
| sean-k-mooney[m] | maybe | 11:26 |
| noonedeadpunk | As what I see when trying to start nova-compute - crash with https://paste.openstack.org/show/b5m5sW2194PRjd2hLGtg/ | 11:26 |
| noonedeadpunk | So to start nova compute I need mdev to be created | 11:26 |
| noonedeadpunk | Need to try dropping resume_guests_state_on_host_boot indeed | 11:27 |
| sean-k-mooney[m] | bauzas: wasnt there someone already working on a fix for that ^ by the way | 11:31 |
| sean-k-mooney[m] | i remember talking to you about fixing it a few months ago but dont recall if you strated to impelent it but wasnt someone else looking at fixing the issue | 11:31 |
| sean-k-mooney[m] | @noon | 11:32 |
| sean-k-mooney[m] | noonedeadpunk: the issue i have with mdevctl is that nova expect that the mdevs do not exist in the normal code path | 11:32 |
| sean-k-mooney[m] | so if you just precreate arbitary mdevs it will break the ablity to create vms | 11:33 |
| sean-k-mooney[m] | and as a a tool it has little other utility if all you are doing is rectateing the mdevs used by the existing vms | 11:33 |
| sean-k-mooney[m] | creating an mdev is just echoing a uuid into a file in /sys | 11:34 |
| sean-k-mooney[m] | mdevctl also used to not be pakaged on anything other then fedora https://repology.org/project/mdevctl/versions its a little better now as tis actull in debian and ubuntu too but its not a tool that you could previously rely being in your distro package | 11:37 |
| noonedeadpunk | well, I had other issue, but maybe because in the region we run V | 11:37 |
| dmitriis | gibi: o/ Apologies for an extra ping, just wanted to ask if you're good with https://review.opendev.org/c/openstack/nova/+/829974 since you've reviewed it before. | 11:38 |
| dmitriis | Not sure if it's appropriate to land it at this point or not but that's more of a fix + test change rather than a new feature. | 11:38 |
| noonedeadpunk | So to start nova-compute we indeed had to echo uuid to /sys | 11:38 |
| sean-k-mooney[m] | ya that is the workaround for now | 11:39 |
| noonedeadpunk | but it's hard as you need to get resource from placement to understand mapping of uuid to mdev pci device | 11:39 |
| sean-k-mooney[m] | i prefer recommendign that as its safer then mdevctl | 11:39 |
| sean-k-mooney[m] | yes as i siad i tought someone had wirtten that up | 11:39 |
| noonedeadpunk | yeah, I see | 11:40 |
| sean-k-mooney[m] | i know bauzas started at one point | 11:40 |
| sean-k-mooney[m] | i remember discussing the algrothim with them and how they would have to use placement to find the parent pci device to know whic device to create the mdev on since that is not in the xml | 11:41 |
| noonedeadpunk | well another weird thing is that mdev uuid is just random thing, while tbh I'd expect it to be resource uuid. Which would make things easier... | 11:42 |
| noonedeadpunk | As we have resource uuid and then mdev uuid is just another thing that is stored _only_ in xml | 11:44 |
| noonedeadpunk | (in case I'm not missing anything | 11:44 |
| sean-k-mooney[m] | its randome because we do not track them in the db | 11:44 |
| gibi | dmitriis, sean-k-mooney[m], bauzas: I'm generally OK with https://review.opendev.org/c/openstack/nova/+/829974 I do noted that this patch is now wide the gap we need to close later as part of https://bugs.launchpad.net/nova/+bug/1961587 as it adds more sysfs calls to our neutron code. | 11:45 |
| sean-k-mooney[m] | i have been trying to change that since before we actully added the mdev feature | 11:45 |
| sean-k-mooney[m] | noonedeadpunk: what i would like use to evolve to is have operators precreat the mdevs and we would track them in the resouces table in the db | 11:46 |
| sean-k-mooney[m] | then claim and allocate them to instances | 11:46 |
| sean-k-mooney[m] | or tack them in the pcidevice table | 11:47 |
| sean-k-mooney[m] | part of the reason i want to do that is i want to get rid of the persitnt libvirt domain xml | 11:47 |
| sean-k-mooney[m] | right now vgpus are the only thing that need to the persitent domain xml | 11:47 |
| dmitriis | gibi: ack, I am going to look at changing this to use extra info instead in a follow-up | 11:48 |
| noonedeadpunk | well, I wasn't having much fun with plain qemu without libvirt, as if you don't need config you can jsut operate qemu directly? | 11:48 |
| noonedeadpunk | tbh for me from operator prespective is preferable that nova manage mdev creation. as otherwise there will be tons of nasty hooks which everybody do. This can be handled by deployment tools ofc, but considering devices are not persistant and drop on reboot... dunno. | 11:50 |
| noonedeadpunk | and if uuid for mdev will be taken as placement resource id - wouldn't it solve issue with persistant libvirt config? | 11:51 |
| noonedeadpunk | as at time mdev is created, I guess allocation should be already claimed and resource provided where to create it? | 11:52 |
| gibi | dmitriis: ack, thanks | 11:52 |
| sean-k-mooney[m] | noonedeadpunk: you can have multiple mdevs attached to a vm so we cant use placemnt ids for the uuid | 11:57 |
| sean-k-mooney[m] | also they have to be gloally unique | 11:58 |
| noonedeadpunk | ah, indeed, if it's not Nvidia Ampere that would be the case... | 11:58 |
| noonedeadpunk | (as there you have resource per vGPU) | 11:58 |
| sean-k-mooney[m] | removing the persitent domain is not the same as raw qemu | 11:58 |
| sean-k-mooney[m] | libvirt has 2 domains for each insthace | 11:59 |
| sean-k-mooney[m] | the running one in memory and an xml file on disk | 11:59 |
| sean-k-mooney[m] | on ocation they get out of sync and cause issues in managing the vm | 11:59 |
| sean-k-mooney[m] | so i would like to get rid of the file on disk and just use the in memory one which is the acurrate one | 12:00 |
| noonedeadpunk | yeah, I do agree herem that makes sense | 12:00 |
| noonedeadpunk | just sugested that it could be first step to raw qemu, as had to deal with such solution on some cloud platform | 12:01 |
| sean-k-mooney[m] | if you have a patch or code to recreate the mdevs on boot using placement we would be happy to include it | 12:01 |
| sean-k-mooney[m] | are you in favor of raw qemu or against? | 12:02 |
| noonedeadpunk | I'm not at the moment as just found that out during incident, but will try to allocate some resources | 12:02 |
| noonedeadpunk | I'm personally against :) | 12:02 |
| sean-k-mooney[m] | ack just checkign libvirt does some useful stuff for us | 12:02 |
| sean-k-mooney[m] | so we are not currently plannig to remove it | 12:02 |
| noonedeadpunk | s/just suggested/just assumed/ | 12:02 |
| sean-k-mooney[m] | we dont really want to have to manage cgroups directly for example | 12:03 |
| noonedeadpunk | I guess it prings in selinux/apparmour rules as well | 12:03 |
| noonedeadpunk | *brings | 12:03 |
| sean-k-mooney[m] | yes | 12:03 |
| sean-k-mooney[m] | it deals with selinux lables and a bunch of other things which we dont want to have to implement in nova | 12:04 |
| noonedeadpunk | and some live migration features iirc | 12:04 |
| sean-k-mooney[m] | yes libvirt does the cpu compatiblity check for us | 12:04 |
| sean-k-mooney[m] | so removing the xml on disk simple. removign libvirt is basicaly a full rewrite of the dirver | 12:05 |
| sean-k-mooney[m] | which is not something we have time for or really want to do | 12:05 |
| noonedeadpunk | exeprience with raw qemu was quite painful | 12:05 |
| sean-k-mooney[m] | the only real advantage to raw qemu would be if libvirt did not have support for feature x yet | 12:06 |
| sean-k-mooney[m] | and at this point nova does not move fast enough for that to be an issue | 12:06 |
| noonedeadpunk | just wanted to say the same:) | 12:07 |
| noonedeadpunk | virtiofs great example of feature ppl love to get but nobody has capacity to help on with... | 12:07 |
| sean-k-mooney[m] | actully that is on our radar | 12:08 |
| sean-k-mooney[m] | it should hopefully get added in z | 12:08 |
| sean-k-mooney[m] | for manilla shares | 12:09 |
| sean-k-mooney[m] | but if you have other usecases for it let us know | 12:09 |
| sean-k-mooney[m] | once we have the basic support in the libvirt driver we can extend it simply if cyborg or anything else wants to use it | 12:10 |
| sean-k-mooney[m] | brb | 12:10 |
| gibi | bauzas and others: I think we have a functional test instability https://paste.opendev.org/show/btHI7ErFfhKYFGdfoujl/ | 12:12 |
| gibi | e.g.: https://6779a19d629122a2ad74-09e4be48fe62aca6e4b03d954e19defe.ssl.cf1.rackcdn.com/828570/8/check/nova-tox-functional-py38/99a1e4f/testr_results.html | 12:12 |
| gibi | recently I saw this pretty frequently but It happened in the past too (I saw matches from mid february) | 12:13 |
| gibi | Im filing a bug... | 12:14 |
| gibi | https://bugs.launchpad.net/nova/+bug/1964472 | 12:20 |
| gibi | ohh the failing testcase was added here https://review.opendev.org/c/openstack/nova/+/821840 | 12:33 |
| gibi | this is one of the bug with rc1 tag, where the fix is still open | 12:33 |
| gibi | so I guess the regression test added here is not stable and needs some tuning | 12:34 |
| gibi | bauzas, sean-k-mooney[m] should we pull https://review.opendev.org/c/openstack/nova/+/815324/10 from the gate? | 12:35 |
| gibi | or we expect a followup to stabilize the functional test in that? | 12:35 |
| sean-k-mooney | is it unstable | 12:41 |
| sean-k-mooney | oh the regerssion | 12:41 |
| gibi | the test case is unstable | 12:42 |
| sean-k-mooney | i see is it still unsable with the followup | 12:42 |
| gibi | we only have data about it being unstable without the fix for the origina bug | 12:43 |
| gibi | that bugfix is on the gate | 12:43 |
| gibi | I tried to reproduce it locally but failed so far | 12:43 |
| sean-k-mooney | In the last 7 days from 8 failed functional test run 6 was due to this in nova. But this happened as far back as 14th of February. | 12:43 |
| sean-k-mooney | so the test has only merged yesterday | 12:43 |
| sean-k-mooney | so those other failures would have been on the path itself | 12:44 |
| sean-k-mooney | as in https://review.opendev.org/c/openstack/nova/+/821840/5 merged yesterday | 12:44 |
| gibi | the test case merged on the 5th | 12:44 |
| gibi | oh no | 12:44 |
| gibi | it is 9th | 12:44 |
| gibi | you are correct | 12:45 |
| gibi | sorry | 12:45 |
| gibi | and you are correct before yesterday it is only failed on 821840/5 | 12:45 |
| gibi | after the merge it is failed on 3 other pathes | 12:45 |
| gibi | see https://paste.opendev.org/show/btHI7ErFfhKYFGdfoujl/ | 12:45 |
| sean-k-mooney | then ya we shoudl either revert or disable i guess | 12:46 |
| opendevreview | Merged openstack/nova master: Add functional tests to reproduce bug #1960412 https://review.opendev.org/c/openstack/nova/+/830010 | 12:46 |
| gibi | yeah, no point yanking the bugfix from the gate as that does not break anyithing, the patch that added the test case was already merged | 12:47 |
| gibi | I can push a patch skipping the test case | 12:48 |
| opendevreview | Balazs Gibizer proposed openstack/nova master: Skip TestRollbackWithHWOffloadedOVS.test_rollback_pre_live_migration https://review.opendev.org/c/openstack/nova/+/833079 | 12:52 |
| gibi | bauzas, sean-k-mooney: ^^ | 12:52 |
| sean-k-mooney | gibi: sorry was making coffee did you determin why its unstable by the way? i did not fully read your bug report | 13:01 |
| gibi | sean-k-mooney: no, I had not time to actually look deeply into it. I has not been able to reproduce it locally yet. | 13:01 |
| gibi | *was not able | 13:02 |
| sean-k-mooney | ok its odd the test is pretty simple | 13:03 |
| sean-k-mooney | i mean for a live migration test | 13:03 |
| sean-k-mooney | gibi: did you mean to put that patch on top of master rather then the fix | 13:05 |
| sean-k-mooney | actully i guess that makes sense too | 13:05 |
| sean-k-mooney | if noone else reviews the skip by the end of the day ill fast approve to make sure its included in rc1 | 13:07 |
| gibi | sean-k-mooney: thanks | 13:07 |
| sean-k-mooney | the followup failed grenade by the way | 13:08 |
| gibi | I have some calls this afternoon, so I'm not sure I will have time to figure out today why it fails | 13:08 |
| bauzas | gibi: sean-k-mooney: sorry was afk, a tl;dr ? | 13:11 |
| bauzas | gibi: I see your comment on https://review.opendev.org/c/openstack/nova/+/815324/10 | 13:12 |
| gibi | bauzas: the functional test added here https://review.opendev.org/c/openstack/nova/+/821840 is unsatble | 13:12 |
| gibi | so I pushed https://review.opendev.org/c/openstack/nova/+/833079 | 13:12 |
| gibi | the we can figure out the stability issue | 13:12 |
| gibi | *then | 13:12 |
| bauzas | gibi: maybe we should revert the functional test then | 13:12 |
| bauzas | gibi: hah | 13:13 |
| gibi | bauzas: we can do that as well, revert the func test and the revert the fix | 13:13 |
| bauzas | gibi: yeah I think it's better | 13:13 |
| bauzas | gibi: can you revert it ? | 13:13 |
| bauzas | erlon is not around | 13:13 |
| gibi | I can | 13:13 |
| bauzas | thanks | 13:13 |
| opendevreview | Balazs Gibizer proposed openstack/nova master: Revert "Adds regression test for bug LP#1944619" https://review.opendev.org/c/openstack/nova/+/832902 | 13:14 |
| gibi | bauzas, sean-k-mooney: ^^ revert then | 13:14 |
| sean-k-mooney | ok that works for me too | 13:15 |
| sean-k-mooney | although it would still be nice to fix this this cycle but i guess we can backport | 13:16 |
| sean-k-mooney | i assuem we dont want to pull this into an RC2 right | 13:16 |
| sean-k-mooney | since tis not really a regression form this cycle | 13:16 |
| sean-k-mooney | its just a bug in the orginal sriov live migration feature | 13:17 |
| sean-k-mooney | so it can wait and be backported as normla | 13:17 |
| bauzas | sean-k-mooney: given the issue is not a regression it can't be a RC2 one | 13:18 |
| bauzas | sean-k-mooney: but I'm OK to backport it to 25.0.1 once we open it | 13:18 |
| bauzas | this is just, we're close to RC1 deadline and erlon isn't around | 13:18 |
| sean-k-mooney | yep that is what i was thinking too | 13:19 |
| bauzas | gib: iI can't find the nova doc where we agree on having a quick and single +2/+W for reverts | 13:20 |
| sean-k-mooney | i can get it but i +w it | 13:20 |
| sean-k-mooney | so there is https://github.com/openstack/nova/blob/master/doc/source/contributor/policies.rst#reverts-for-retrospective-vetos | 13:21 |
| sean-k-mooney | but i tought we had something else too | 13:22 |
| sean-k-mooney | ya i dont see anything else relevent | 13:24 |
| sean-k-mooney | in anycase i think we can agree that reverting a regression test that is unstable is ok given the followup fix has not merged yet | 13:25 |
| gibi | I agree that fixing the gate is enough reason to quick approve a revert | 13:35 |
| gibi | (or a test skip patch) | 13:35 |
| bauzas | gibi: anyway, sean found the doc but also +Wd it | 13:36 |
| sean-k-mooney | three cores walk into a bar, first core submits a patch to fix it, second core approves, third core say ouch how put this bar here | 13:39 |
| gibi | :D | 13:39 |
| * sean-k-mooney is just sad that its been soo long since three cores actully did walk into a bar at a ptg or otherwise | 13:42 | |
| gibi | yeah | 13:43 |
| opendevreview | Merged openstack/nova master: Fix migration with remote-managed ports & add FT https://review.opendev.org/c/openstack/nova/+/829974 | 13:50 |
| bauzas | sean-k-mooney: indeed, I missed bars, I'm so foo | 13:59 |
| sean-k-mooney | lol :) | 13:59 |
| *** dasm|off is now known as dasm | 14:00 | |
| opendevreview | ribaudr proposed openstack/nova master: [WIP] Attach Manila shares via virtiofs(db+object) https://review.opendev.org/c/openstack/nova/+/831193 | 14:00 |
| opendevreview | ribaudr proposed openstack/nova master: [WIP] Attach Manila shares via virtiofs(manila abstraction) https://review.opendev.org/c/openstack/nova/+/831194 | 14:00 |
| opendevreview | ribaudr proposed openstack/nova master: [WIP] Enable and use COMPUTE_STORAGE_VIRTIO_FS and COMPUTE_MEM_BACKING_FILE traits. https://review.opendev.org/c/openstack/nova/+/833090 | 14:00 |
| sean-k-mooney | noonedeadpunk: ^ see virtio-fs work | 14:01 |
| bauzas | sean-k-mooney: are you ok with me removing the yoga-rc-potential flag ? https://bugs.launchpad.net/nova/+bug/1960412 and https://bugs.launchpad.net/nova/+bug/1949808 ? | 14:01 |
| sean-k-mooney | yes although the fix should hopefully merge shortly | 14:02 |
| bauzas | oh wait indeed | 14:03 |
| bauzas | haven't seen gibi voting | 14:03 |
| noonedeadpunk | oh, wow | 14:03 |
| bauzas | we can hold | 14:03 |
| sean-k-mooney | it failed on the flaky func test | 14:03 |
| gibi | yeah I found out about the flaky test by reviewing that other bugfix :) | 14:04 |
| gibi | ohh it failed again :/ | 14:04 |
| gibi | then we need the revert first | 14:05 |
| sean-k-mooney | ath least this time its looking ok https://zuul.openstack.org/status#828570 | 14:05 |
| sean-k-mooney | not that im watching it on my other monitor right now or anything | 14:05 |
| sean-k-mooney | tottally not | 14:05 |
| gibi | :) | 14:06 |
| opendevreview | Merged openstack/nova master: Revert "Adds regression test for bug LP#1944619" https://review.opendev.org/c/openstack/nova/+/832902 | 14:16 |
| bauzas | gibi: I guess we can +W https://review.opendev.org/c/openstack/nova/+/832292 | 15:04 |
| bauzas | sean-k-mooney: ^ | 15:04 |
| bauzas | we need it for the RC1 | 15:05 |
| gibi | done | 15:05 |
| bauzas | thanks | 15:05 |
| sean-k-mooney | hehe i was about to say looks like gibi already has | 15:05 |
| bauzas | let's wait then for both https://review.opendev.org/c/openstack/nova/+/832292 and https://review.opendev.org/c/openstack/nova/+/828570 be merged | 15:05 |
| bauzas | elodilles: ^ | 15:05 |
| bauzas | elodilles: once both are merged, we could modify the RC1 nova change | 15:05 |
| bauzas | and then we'll be done :) | 15:06 |
| dansmith | chateaulav: did you ever float a patch to run the emulation job less? | 15:10 |
| elodilles | bauzas: ack :] | 15:16 |
| chateaulav | dansmith: no, i can | 15:22 |
| dansmith | chateaulav: cool, thanks | 15:48 |
| opendevreview | Artom Lifshitz proposed openstack/nova master: Explicitly set OS_DEBUG=0 when running default logging test https://review.opendev.org/c/openstack/nova/+/833115 | 15:54 |
| opendevreview | Merged openstack/nova master: Clean up when queued live migration aborted https://review.opendev.org/c/openstack/nova/+/828570 | 16:07 |
| opendevreview | Merged openstack/nova master: Add the Yoga prelude section https://review.opendev.org/c/openstack/nova/+/832292 | 16:07 |
| gibi | we are done \o/ :D | 16:08 |
| *** gmann is now known as gmann_afk | 16:13 | |
| sean-k-mooney | :) | 16:14 |
| bauzas | cool | 16:15 |
| *** gmann_afk is now known as gmann | 16:29 | |
| opendevreview | ribaudr proposed openstack/nova master: Fix unit tests when they are run we OS_DEBUG=True https://review.opendev.org/c/openstack/nova/+/833115 | 16:33 |
| elodilles | bauzas: should we wait for something else, or may I update the nova RC1 patch? | 16:47 |
| bauzas | elodilles: I was about to do it but I'm in some brainstrorming internal meeting that tramples my brain | 16:47 |
| bauzas | elodilles: so, shoot | 16:47 |
| elodilles | bauzas: no problem, doing it in a sec! o/ | 16:48 |
| bauzas | SHA1 to use : 60094e663c30fd11bb0b1c6923de9e5056adf8be | 16:48 |
| bauzas | elodilles: ^ | 16:48 |
| elodilles | yepp, added that | 16:50 |
| elodilles | bauzas: there you go: https://review.opendev.org/c/openstack/releases/+/832412 | 16:50 |
| chateaulav | dansmith: just for clarification, after removing from check do i place it under experimental, or is there somewhere else to define it as a weekly periodic? | 18:12 |
| sean-k-mooney | you can put it in experimental or periodic-weekly like we do in placment https://github.com/openstack/placement/blob/master/.zuul.yaml#L64-L73 | 18:13 |
| chateaulav | sean-k-mooney: thanks | 18:14 |
| chateaulav | ok, so then since nova zuul doesnt have periodic weekly specified my patch would be the one to introduce it | 18:15 |
| sean-k-mooney | yes just add that section and move the job into it | 18:16 |
| sean-k-mooney | there is also a periodic: pipeline that runs nightly i think but weekly shoudl be enough | 18:16 |
| sean-k-mooney | we can check the status in the team meeting | 18:17 |
| chateaulav | thanks | 18:21 |
| opendevreview | Jonathan Race proposed openstack/nova master: Changes Emulation CI to weekly-periodic https://review.opendev.org/c/openstack/nova/+/833163 | 18:25 |
| opendevreview | Ghanshyam proposed openstack/nova-specs master: Re-propose server boot on specific hypervisor with new RBAC https://review.opendev.org/c/openstack/nova-specs/+/833165 | 18:42 |
| erlon | sean-k-mooney: bauzas: gibi: hey, Im looking at the test_rollback_pre_live_migration test. I'm really puzzled. I have run 10 times or so, and just now I was able to reproduce it locally. Test is still looping. Running all suite 5 or 6 times also didnt break it. | 18:47 |
| erlon | do you guys have any ideia on what could cause this kind of bug? | 18:48 |
| opendevreview | Erlon R. Cruz proposed openstack/nova master: DNM: Adds regression test for bug LP#1944619 https://review.opendev.org/c/openstack/nova/+/833166 | 18:54 |
| opendevreview | Merged openstack/placement stable/yoga: Update .gitreview for stable/yoga https://review.opendev.org/c/openstack/placement/+/832979 | 19:19 |
| opendevreview | Merged openstack/placement stable/yoga: Update TOX_CONSTRAINTS_FILE for stable/yoga https://review.opendev.org/c/openstack/placement/+/832981 | 19:37 |
| sean-k-mooney | erlon: not initaly no. we have seen this type of bug in the past if the test did not wait for async operation to finish or where we were incorrectly sharing global state | 23:08 |
| sean-k-mooney | erlon: but that test did not appear to be doing that | 23:08 |
| *** dasm is now known as dasm|off | 23:58 | |
Generated by irclog2html.py 2.17.3 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!