Monday, 2023-01-09

opendevreviewDavid Sedgmen proposed openstack/nova master: Nova: Add workaround to mask mpx on compareCPU()  https://review.opendev.org/c/openstack/nova/+/86953603:54
gibigmann, stephenfin: it is strange I see the periodic passed during the weekend but now I also see failing jobs with missing interpreter: here is a fresh one https://1729c20500306078d1cb-f18cd0734c7002742f0baf633d0573f2.ssl.cf2.rackcdn.com/854615/11/check/nova-tox-functional-py310/548baa7/job-output.txt08:55
*** priteau_ is now known as priteau08:58
gibiit seems that nova functional jobs are hit but unit test jobs arent09:05
songwenping_passwd09:06
*** songwenping_ is now known as swp2009:10
gibiboth job using tox 4.2.6 which supposed to contain the fix of missing interpreters09:19
bauzasgibi: sorry, this vgpu downstream reproducer vamps me 09:20
bauzasgibi: can you please explain me the current status for tox4 issues ?09:21
gibibauzas: o/\09:21
gibibauzas: so https://github.com/tox-dev/tox/pull/2828 supposed to fix the missing interpreter error that hit both unit and functional test jobs09:22
gibibauzas: it merged and released during the weekend in 4.2.509:22
bauzaskk09:22
gibibauzas: this morning I rechecked one of my patch09:22
gibibauzas: the unit test jobs passed there with tox 4.2.609:23
gibibauzas: but the functional ones are still failing with the missing interpreter error09:23
bauzasgibi: are you sure you're not pinned by a previous tox version ?09:23
gibithis is the recheck run I watch https://zuul.opendev.org/t/openstack/status#85461509:23
gibiI'm pretty sure both jobs run with 4.2.6 but feel free to double check the logs09:25
sahid22018509:26
bauzas2023-01-09 08:51:17.905173 | ubuntu-jammy |   Downloading https://mirror.bhs1.ovh.opendev.org/pypifiles/packages/6a/fd/8e1f5e6f251120f643e7e2773d9451b7669e6dfdd3c09fc6d9185b423fc9/tox-4.2.6-py3-none-any.whl (145 kB)09:27
bauzasgibi: indeed ^09:27
gibiI think I can reproduce it locally in a container with tox 4.2.609:29
gibimaybe it does not understand our generative tox env definition any more `[testenv:functional{,-py38,-py39,-py310}]`09:32
bauzashmmm09:33
gibino09:34
gibisimplifying that to `[testenv:functional-py310]` still doesnt work09:34
bauzascan you just remove the python version suffix ?09:34
bauzaswith tox, it could autocreate the right dirs IIRC09:35
gibi__my home internet went down09:42
gibi__I'm not sure what I was able to send last time09:43
gibi__so simplifying the tox target to functional-py310 does not help09:43
bauzasgibi__: can you create just a tox target without the python version ?09:43
bauzasI guess you have py39 default09:44
gibi__let me see09:44
gibi__hm, if I change the functional-py310 to functionalpy310 then it seems to work09:46
gibi__the problem is that it then ignores the py310 part of the target and runs with whathever python3 interpreter I have09:47
gibi__so functionalpy39 runs with the same python3.10 I have installed09:47
sahido/ any chance to get some reviews on https://review.opendev.org/c/openstack/nova/+/858383 ?09:49
sahidperhpas gibi__ when you have a moment :D ^09:50
gibi__bauzas: so I do believe that the generative env feature is broken somehwo09:51
gibi__stephenfin: ^^09:51
bauzasgibi__: yeah, that's my guess09:51
gibi__sahid: ack, I'm not sure when I will have that moment, sorry09:51
bauzasgibi__: tox can't guess which python interpreter to use09:51
bauzasthat said, it looks a large regression09:52
* bauzas wonders whether pyproject.toml has the same issue09:53
bauzasgibi__: ^09:53
* bauzas looks at https://tox.wiki/en/4.2.6/config.html09:55
opendevreviewBalazs Gibizer proposed openstack/nova master: Define basepython for functional targets  https://review.opendev.org/c/openstack/nova/+/86954509:57
gibi__bauzas: ^^ this seems to work locally09:57
bauzastheorically, this shouldn't be needed09:58
bauzashttps://tox.wiki/en/4.2.6/config.html#base_python09:59
gibi__yeah, it worked before09:59
bauzasunfortunately the tox4 docs isn't that explaining how to autogenerate venvs with py versioning like tox3 docs do https://tox.wiki/en/3.4.0/config.html#generating-environments-conditional-settings10:00
gibi__I will open an issue for tox maybe the devs knows more10:00
bauzas"tox provides a number of default factors corresponding to Python interpreter versions. The conditional setting above will lead to either python3.6 or python2.7 used as base python, e.g. python3.6 is selected if current environment contains py36 factor."10:01
bauzasso I guess the default factors no longer work10:01
gibi__after some more trials it is more like basepython = python3 and -py310 factor creates a conflict but we have ignore_basepython_conflict to supress that and that lead to no interpreter found10:09
gibi__bauzas, gmann, stephenfin: opened https://github.com/tox-dev/tox/issues/283810:20
bauzasgibi__: we could remove basepython IMHO10:21
gibi__we could if we assume no env will have python2.7 as a default interpreter installed10:23
stephenfinyeah, be can/should drop basepython at this point10:37
stephenfin*we10:37
stephenfingibi: replied on the tox bug also10:39
gibi__stephenfin: I tried in tox 3.28 and I did not need ingnore_base_python_conflict to make it work10:40
gibi__stephenfin: you can simply remova that from nova's tox.ini and it work in tox 3.28 for me locally10:40
gibi__stephenfin: anyhow so you suggest to just remove basepython = python3 and assume people's machine has python3 by default10:42
gibi__(which could be a fair assumption having python2.7 in EOL)10:43
stephenfinI think that's a reasonable workaround, yes10:43
gibi__OK, I will change https://review.opendev.org/c/openstack/nova/+/869545 to drop basepython instead of defining it for each generative env10:44
gibi__and then I can also try to drop ignore_basepython_conflict10:45
stephenfinoh, you can do the two in one go. ignore_basepython_conflict is only needed if `basepython` is defined (which it won't be here)10:45
gibi__OK10:46
sean-k-mooneybauzas: yes you can use tox -e py3|functional10:50
sean-k-mooneythose will use your defalt python10:50
sean-k-mooneywe only set basepython to cater for python2 vs python310:51
sean-k-mooneyso yes we can drop it now10:51
opendevreviewBalazs Gibizer proposed openstack/nova master: Remove basepython def from tox.ini  https://review.opendev.org/c/openstack/nova/+/86954510:53
gibi__stephenfin, bauzas: ^^10:53
sean-k-mooneygibi__: so regarding https://review.opendev.org/c/openstack/os-vif/+/869500 that now works but we need to squash it into your patch10:54
sean-k-mooneyor in your patch you can disable the functional jobs and we can re enable it in this one10:54
sean-k-mooneygibi__: any prefernce10:54
gibi__I need to update that tox patch to remove basepython and ignore_basepython_conflict, I can do a squash at the same time10:56
darkhorseartom: If you remember our discussion on unshelving pci instance, I tried to boot from image that is related to the unshelved instance but failed. I don't see an image created when I shelve an instance. I tried openstack images list and also checked in the glace>images table but nothing is created when I shelve an instance.10:57
gibi__sean-k-mooney: but I need to have lunch first10:57
sean-k-mooneygibi__: cool works for me enjoy your lunch10:59
gibi__thanks11:00
opendevreviewBalazs Gibizer proposed openstack/os-vif master: Make tox.ini tox 4.0.0 compatible  https://review.opendev.org/c/openstack/os-vif/+/86842011:31
gibi__sean-k-mooney: ^^ fix with the squash11:31
sean-k-mooneygibi__: thanks +2 although ignoring 2 +2s thing for a sec given i wrote part of this i want someone else to +w anyway11:40
opendevreviewsean mooney proposed openstack/os-vif master: Update gate jobs as per the 2023.1 cycle testing runtime  https://review.opendev.org/c/openstack/os-vif/+/86146811:42
gibi__stephenfin: if you have a sec then here https://review.opendev.org/c/openstack/placement/+/868418 I think we have some disagreements11:51
sean-k-mooneygibi__: the convention we had for the deps is generally to inherit and extend11:56
sean-k-mooneylike this 11:57
sean-k-mooneydeps =11:57
sean-k-mooney  {[testenv]deps}11:57
sean-k-mooney  -r{toxinidir}/doc/requirements.txt11:57
sean-k-mooneyi think that is what stephen was sugessing but not sure11:57
sean-k-mooneyto avoid repeatign 11:57
sean-k-mooney  -c{env:TOX_CONSTRAINTS_FILE:https://releases.openstack.org/constraints/upper/master}11:57
sean-k-mooney  -r{toxinidir}/requirements.txt11:57
gibi__sean-k-mooney: extending deps alone is not enough, it seems deps are not properly applied during the editable install of the package12:01
gibi__basically the editable install makes the deps unconstrained12:01
gibi__(from above)12:01
sean-k-mooneyreally thats not what i was expecting12:01
sean-k-mooneyi guess that is a delete in the skipsdist behavior12:02
sean-k-mooneyby not skiping we build a wheel and install form that12:02
stephenfingibi__: looking12:02
sean-k-mooneypresumable its the build step that might be the issue?12:03
stephenfinoh, interesting12:04
gibi__sean-k-mooney: yes it could be related to removing skipdist12:06
sean-k-mooneyuse_develop with skipsdist=false seams to not be doing an editiable install it instead ensure that a install of the current content of the working dir is done via a wheel i think12:06
stephenfinhmm, so in theory, either way should be okay. If we're separately listing 'requirements.txt' in our 'deps' setting then we'll have installed those (with constraints) first. That's because we've removed skipsdist alright12:06
sean-k-mooneywe coudl just move the -c line to the deps of testenv12:07
sean-k-mooneythen do  {[testenv]deps}12:07
stephenfinBut yeah, overriding 'install_command' is certainly less likely to cause issue12:07
sean-k-mooneyanytime we are modifing the deps later12:07
stephenfinsean-k-mooney: what gibi's saying though is that the package itself (i.e. placement or nova) is installed without constraints12:08
stephenfinso we're relying on us having already installed the deps with constraints and hoping (I guess) that tox doesn't decide to reinstall them without constraints when installing the package12:08
gibi__stephenfin: we install our deps with constraints yes, but then we install the placement package's deps again without constriants12:08
stephenfinso best to override the install_command12:08
sean-k-mooneyok but woudl we not12:09
sean-k-mooneyya would we not need to change that ^12:09
stephenfinwe should drop '-rrequirements.txt' from 'deps' too since it's now unnecessary and potentially confusing12:09
gibi__OK, I can move everything to install_command12:09
sean-k-mooneythis looks a littel differnt then normal actully12:09
gibi__and drop deps12:10
sean-k-mooneyhttps://github.com/openstack/os-vif/blob/master/tox.ini12:10
stephenfinI'd keep 'deps' but only for test-requirements.txt and doc/requirements.txt12:10
sean-k-mooneyif we compare it to osvif we droped the install_command a while ago12:10
stephenfinsean-k-mooney: you've got 'skipsdist = true' though12:11
sean-k-mooneytrue12:11
stephenfinso it won't actually install os-vif12:11
sean-k-mooneybut for nova we doint12:11
sean-k-mooneyhttps://github.com/openstack/nova/blob/master/tox.ini12:11
stephenfinYup, so it will install nova12:11
sean-k-mooneyok that is why the os-vif packages were not being installed12:12
stephenfinos-vif is working because Python adds $PWD to $PYTHONPATH12:12
stephenfinor rather, was12:12
stephenfinbut I think tox 4 might have changed that, idk12:12
sean-k-mooneywe could have actully kept the two commits sepeate instaed fo squashihng them12:12
sean-k-mooneystephenfin: i had to rebase this on top of gibis tox4 change https://review.opendev.org/c/openstack/os-vif/+/869500/2 because the os-vif package was not found12:13
sean-k-mooneythis combined one works https://review.opendev.org/c/openstack/os-vif/+/868420/312:13
sean-k-mooneybut we also could have used install command i guess12:14
stephenfingibi__: one other thing: instead of 'pip install' can we do 'python -m pip install'12:15
stephenfinthere's a reason for that that clarkb brought up on openstack-discuss recently (I think) but I don't recall what12:16
stephenfinit's what tox itself does though12:16
sean-k-mooneyi have been pushing people to move to -m pip install and got that changed in devstack12:17
sean-k-mooneythere are some odd behaivors with user install/venvs when using pip that does not happen if you use python -m pip12:17
sean-k-mooneybascailly you can have the pip package isntalled without the pip script being in your current path12:18
sean-k-mooneyalso due to how setup tools console scripts work there can also be some funkyness in a mixed python2/python3 enve with the #! line12:19
sean-k-mooneyso the module apporch is just generally more robost12:19
gibi__ack12:23
opendevreviewBalazs Gibizer proposed openstack/placement master: Make tox.ini tox 4.0.0 compatible  https://review.opendev.org/c/openstack/placement/+/86841813:46
gibistephenfin, sean-k-mooney: ^^ 13:46
kashyapgibi: What do you think of workarounds like this?  -- https://review.opendev.org/c/openstack/nova/+/869536/  (I'm not a fan of it...)13:47
kashyap(Gibi or anyone :-))13:47
kashyap(You can comment directly on the review.)13:52
gibisean-k-mooney, stephenfin: I cannot switch os-vif to install_command from deps it results in https://paste.opendev.org/show/bkSH8jaL4WH04S2sge5t/13:54
gibibasically we have a constraing about os-vif in global requirements so the editable install building locally will conflict with the global constraint13:54
stephenfinokay, I guess we need to continue using 'deps' there so13:55
gibistephenfin: even if it means we allow ignoring the upper constraint during the editable install?13:55
stephenfinwe'll still install the deps first, right?13:55
gibiright13:58
gibibut the package install can decided to upgrade the deps as there is no constraint there13:58
stephenfinbut would it, assuming the deps are already satisfied?13:58
gibiI don't know but relying on that feels dirty :)13:59
stephenfinIt does, yeah :)13:59
gibikashyap: I'm not even sure I understand the problem statement in that patch13:59
stephenfinI wonder if this is a pip bug?13:59
gibiit feels like a tox shortcoming as tox calls pip install 14:00
gibito install the deps of the package14:00
*** dasm|off is now known as dasm14:01
gibibasically the install_package_deps step in tox ignores the deps14:02
gibiso even if we put the constraint in the deps it has no effect14:03
gibiinstall_package_deps does use the install_commmand hence our solution in placement to put the constraint there.14:03
kashyapgibi: In this case, Intel "IceLake CPU" is not correctly recognized due to missing flag, "mpx".  (And another problem is Nova's now-broken suboptimal CPU comparison code)14:07
kashyapgibi: The quickest (and still valid) solution to this (and similar) problems is to _remove_ the CPU comparison that Nova does at all.  As libvirt will do the Right Thing.14:07
kashyapgibi: ... which can be done by reviving this short older patch (which you +1ed in the past).  See the commit:  https://review.opendev.org/c/openstack/nova/+/772917/14:08
gibibut that was abandoned in favor of https://review.opendev.org/q/topic:bp%252Fcpu-selection-with-hypervisor-consideration where https://review.opendev.org/c/openstack/nova/+/762330 needs substantial work14:09
kashyapgibi: Yeah, indeed!  That said: libvirt developers themselves now tell me that we (Nova) doesn't need to do that check anymore14:10
kashyapgibi: Read this comment from Jiri here:14:10
kashyaphttps://bugzilla.redhat.com/show_bug.cgi?id=2138381#c714:10
kashyapEspecially the 2nd paragraph14:11
kashyapgibi: That substantial work is more fragile and I don't have cycles to baby-sit it.  The best course is to remove the check w/ the shorter patch, which is still correct14:11
kashyapAs it provides most benefit with the shortest patch, IMHO.14:11
gibiOK. do you suggest to revive https://review.opendev.org/c/openstack/nova/+/772917/ ?14:11
gibiwill that solve the issue behind https://review.opendev.org/c/openstack/nova/+/869536 too?14:12
kashyapYes, definitely.  Based on that commit message rationale _and_ the advice of CPU modelling maintainer from libvirt14:12
kashyapgibi: Yes14:13
kashyapI'll comment there14:13
kashyapBefore removing that patch, we also have to deprecate (and remove later) this workaround: CONF.workarounds.skip_cpu_compare_on_dest14:14
gibiI'm OK with this approach14:16
gibiI don't believe we have the bandwidth to land https://review.opendev.org/q/topic:bp%252Fcpu-selection-with-hypervisor-consideration 14:17
kashyapgibi: Uh, I made a messy mistake in thinking: please ignore the above.  Here's my correction:14:17
kashyapgibi: We should actually get rid of _this_ compare_cpu() check in _ceck_cpu_compatibility() method - 14:17
kashyaphttps://github.com/openstack/nova/blob/8a476061c5e034016668cd9e5a20c4430ef6b68d/nova/virt/libvirt/driver.py#L99114:17
* kashyap proposes a test patch14:17
kashyapgibi: But the reason is the same.  (The only correction is a different 14:19
kashyap... method in Nova.14:19
gibiack14:20
gibifeel free to ping me if I need to re-review the https://review.opendev.org/c/openstack/nova/+/772917/14:20
kashyapNod, noted.  Not that one, I'm sure we need to get rid of the check in _check_cpu_compatibility().  Thank you!14:22
sean-k-mooneykashyap: in general im not sure i agree that we should relay on libvirt for the cpu compat check14:24
kashyapsean-k-mooney: Why?  What reason do we have?14:25
sean-k-mooneyi know libvirt will do it properly but i thing this is somethign that nova shoudl do not the hyperviros in general14:25
kashyapFWIW, I think this is the right approach after thinking about it for a long time, and relying on the advice of SMEs on this topic.14:25
kashyapDoing it ourselves is costly and error-prone at this point.14:25
sean-k-mooneyit may be the right approch form a libvirt point of view14:26
kashyapWhen the hypervisor (in this case libvirt + QEMU) is _already_ doing it, let's please rely on it14:26
sean-k-mooneybut nova should have validateed the destination for compatibality before we invokve libvirt14:26
kashyapsean-k-mooney: No, their advice is for management tools in general.14:26
sean-k-mooneyin fact form an nova point of veiw we shoudl have valdiated it entirly as part fo schudling14:26
kashyapsean-k-mooney: That destination check is there (but we have added a workaround to skip it - as that's not required too)14:26
sean-k-mooneyform a nova point of view pre-livemigrate is already quite late14:26
kashyapYeah, "ideally..." scenarios are hard at this point :-)14:27
kashyapsean-k-mooney: That's the one on destination skip: https://code.engineering.redhat.com/gerrit/c/nova/+/40528614:28
kashyap(Same reasoning in my commit applies for src check)14:28
sean-k-mooneyso form my perspective not validating all requirement in pre-livemigrateis incorrect but i understand why you want o delegate this to libvirt14:28
kashyapThank you.  I'm getting tired of some these reports and playing whack-a-mole :(14:29
sean-k-mooneyso i think goign forward we may need to reqest a new feature in libvirt or desgin a new feature in nova14:30
kashyapsean-k-mooney: What would the new RFE for libvirt be?14:30
sean-k-mooneyi consider it a bug to not validate all requiremnt like cpu compatiabliy so eventully i woudl like a more relyable way to do that validation14:30
sean-k-mooneykashyap: im not quite sure14:31
kashyaplibvirt precisely did have several RFEs and it took a few years to work out all these issues and come to this point of "doing the right thing" on src + dest14:31
sean-k-mooneyin general i would like a more declaritive way to understand if live migratoin is possibel14:31
sean-k-mooneyso that we can model this in placment in some way but i dont know what that woudl look like14:32
sean-k-mooneythe imperitive check we have right now by invoking cpu_compare or the new apis is not really compatible with nova current schduling model14:32
sean-k-mooneythat is why they happen late after schuding as pre miggrate checks14:33
kashyap(Right.  That's future goodness if we have cycles. :))14:33
kashyapgibi: sean-k-mooney: Unrelated - do you know what's off in my F35 env. for flake8 to fail this way? - https://paste.opendev.org/show/bLBgrdYhl1i7hqAPCvqP/14:34
sean-k-mooneyproably the import_lib version 14:35
sean-k-mooneyalthogh i think we dropped support for python 3.714:35
sean-k-mooneywe used to have a workaround for older python versions14:35
kashyapRight; I just learn that flake8 on master min requires 3.814:35
sean-k-mooneynot quite master required 3.814:35
sean-k-mooneybut  importlib_metadata gain suppport for some feautre sin 3.814:36
sean-k-mooneybefore that we had a workaorund when we had 3.6 suoprt still14:36
* kashyap looks14:36
sean-k-mooneyanyway if you can use 3.8 that woudl be better14:37
kashyapYeah, trying :)14:39
sean-k-mooneyyou could change [testenv:pep8] to [testenv:pep8{,-py38,-py39,-py310}]14:39
sean-k-mooneypep8 is runnign with your systems default python14:40
sean-k-mooneyso your other option is to update the alternitives to make python3.8 the default python14:40
sean-k-mooneyactully you can create a python venv with 3.8 and run tox form that too if needed14:40
kashyapIt's a new venv; but the pre-commit hook seems to use system python14:41
sean-k-mooneywhat im suggestign is you should do python3.8 -m venv .venv14:45
sean-k-mooneyand install precommit and tox in that 14:45
sean-k-mooneyand use those to mange your tox envs and commit ectra14:45
sean-k-mooneyif you are not able to update your default system python to 3.8+14:46
kashyap$> /usr/bin/python3 --version14:46
kashyapPython 3.10.814:46
kashyapDefault system is already well above 3.8+.  I just don't know how pre-commit is getting 3.714:46
sean-k-mooneyod14:46
sean-k-mooneyi would unistall and reinstal it14:47
kashyapYep, tryin14:47
kashyapThis fixed it for me:15:16
kashyap$> pre-commit install --allow-missing-config15:16
kashyap$> rm -rf /home/kashyapc/.cache/pre-commit/15:16
opendevreviewBalazs Gibizer proposed openstack/nova master: Remove basepython def from tox.ini  https://review.opendev.org/c/openstack/nova/+/86954515:18
gibibauzas: ^^ needed to unblock the nova gate15:19
gibibauzas: and https://review.opendev.org/c/openstack/placement/+/868418 needed to unblock the placement gate15:20
opendevreviewBalazs Gibizer proposed openstack/placement master: Make tox.ini tox 4.0.0 compatible  https://review.opendev.org/c/openstack/placement/+/86841815:21
darkhorseartom: I tried to boot from image that is related to the shelved instance but failed. I don't see an image created when I shelve an instance. I tried openstack images list and also checked in the glace > images table in mariadb but nothing is created when I shelve an instance.15:37
artomdarkhorse, has to be shelved_offloaded15:46
artomThat's either a manual step after the instance is shelved, or done automatically by the cloud depending on config15:46
darkhorseartom: yes its shelved_offloaded.15:46
artomErr, there should be an image...15:47
artomUnless it's boot from volume? I'm not sure about that case15:47
darkhorseno its not boot from volume15:48
darkhorseI launched the instance from cirros image and flavor.15:48
bauzasgibi: sorry was at the school for getting my child15:48
bauzasreviewing the change15:48
bauzasand thanks for having worked on it :)15:48
artomdarkhorse, not sure what to tell you. If the shelve was successful there should be an image.15:51
darkhorseIs the image hidden maybe? I guess it is not visible to other users? It's not showing in the horizon dashboard nor from cli when I do openstack image list.15:52
artomNormally only admins can shelve, and admins can see all the images16:06
bauzasI have a network issue folks16:09
bauzassean-k-mooney: I have a network issue, please move on16:10
opendevreviewBalazs Gibizer proposed openstack/nova stable/yoga: Reproduce bug 1981813 in func env  https://review.opendev.org/c/openstack/nova/+/85931217:07
opendevreviewBalazs Gibizer proposed openstack/nova stable/yoga: Gracefully ERROR in _init_instance if vnic_type changed  https://review.opendev.org/c/openstack/nova/+/85931317:08
opendevreviewBalazs Gibizer proposed openstack/nova stable/xena: Reproduce bug 1981813 in func env  https://review.opendev.org/c/openstack/nova/+/85931417:14
opendevreviewBalazs Gibizer proposed openstack/nova stable/xena: Gracefully ERROR in _init_instance if vnic_type changed  https://review.opendev.org/c/openstack/nova/+/85931517:14
opendevreviewBalazs Gibizer proposed openstack/nova stable/wallaby: Reproduce bug 1981813 in func env  https://review.opendev.org/c/openstack/nova/+/85932017:22
opendevreviewBalazs Gibizer proposed openstack/nova stable/wallaby: Gracefully ERROR in _init_instance if vnic_type changed  https://review.opendev.org/c/openstack/nova/+/85932117:22
opendevreviewBalazs Gibizer proposed openstack/nova stable/victoria: Reproduce bug 1981813 in func env  https://review.opendev.org/c/openstack/nova/+/86958317:31
opendevreviewBalazs Gibizer proposed openstack/nova stable/victoria: Gracefully ERROR in _init_instance if vnic_type changed  https://review.opendev.org/c/openstack/nova/+/86958417:31
sean-k-mooneybauzas: can you take a look at https://review.opendev.org/c/openstack/nova-specs/+/865432 again17:34
sean-k-mooneymelwitt: gibi: and if one of ye has time https://review.opendev.org/c/openstack/nova-specs/+/85549017:34
sean-k-mooneythe cinder spec is appvoed for ^ if i recall17:35
sean-k-mooneyhttps://review.opendev.org/c/openstack/cinder-specs/+/86671817:35
melwittsean-k-mooney: I've been meaning to get back to that one 😓 17:38
opendevreviewDan Smith proposed openstack/nova master: Add virt/node module for stable uuids  https://review.opendev.org/c/openstack/nova/+/86391517:38
opendevreviewDan Smith proposed openstack/nova master: Pass service ref to init_host(), if exists  https://review.opendev.org/c/openstack/nova/+/86391617:38
opendevreviewDan Smith proposed openstack/nova master: Add get_available_node_uuids() to virt driver  https://review.opendev.org/c/openstack/nova/+/86391717:38
opendevreviewDan Smith proposed openstack/nova master: WIP: Persist existing node uuids locally  https://review.opendev.org/c/openstack/nova/+/86391817:38
opendevreviewDan Smith proposed openstack/nova master: Make resource tracker use UUIDs instead of names  https://review.opendev.org/c/openstack/nova/+/86391917:38
opendevreviewDan Smith proposed openstack/nova master: WIP: Detect host renames and abort startup  https://review.opendev.org/c/openstack/nova/+/86392017:38
dansmithmelwitt: sean-k-mooney ^17:43
dansmithI was able to make it all work without removing that test after all it seems17:43
sean-k-mooneycool is ignore WIP status is that more or less feature complete at this point17:43
sean-k-mooney*so ignoring..17:44
dansmiththe two WIP ones just need more tests17:44
sean-k-mooneyack17:44
melwittack also17:44
sean-k-mooneybut in terms fo the spec i assume that series now covers most of the work itmes or all of it?17:44
dansmithre: that test, I had one thing in the fake driver that was being done earlier in the set than needed, which meant I was triggering the undelete early in the stack before we had the code to handle it17:45
dansmithsean-k-mooney: yeah17:45
sean-k-mooney  "lambda: None" ... ok i guess that one way to noop17:47
sean-k-mooneyi guess fixtures.MockPatch need a callback functions to work17:48
opendevreviewBalazs Gibizer proposed openstack/nova stable/ussuri: Reproduce bug 1981813 in func env  https://review.opendev.org/c/openstack/nova/+/86958517:48
opendevreviewBalazs Gibizer proposed openstack/nova stable/ussuri: Gracefully ERROR in _init_instance if vnic_type changed  https://review.opendev.org/c/openstack/nova/+/86958617:48
opendevreviewKashyap Chamarthy proposed openstack/nova master: libvirt: Remove compareCPU() check in _check_cpu_compatiblity()  https://review.opendev.org/c/openstack/nova/+/86958717:57
opendevreviewKashyap Chamarthy proposed openstack/nova master: libvirt: Remove compareCPU() check in _check_cpu_compatibility()  https://review.opendev.org/c/openstack/nova/+/86958718:01
gmanngibi: thanks. +2, leaving approval to stephenfin in case anything else missing18:06
opendevreviewGhanshyam Mann proposed openstack/nova master: Enable new defaults and scope checks by default  https://review.opendev.org/c/openstack/nova/+/86621818:08
opendevreviewGhanshyam Mann proposed openstack/placement master: Avoid rbac defaults conflict in functional tests  https://review.opendev.org/c/openstack/placement/+/86952518:09
sean-k-mooneydansmith: nothing major so far just weighed in on the open() discussion https://review.opendev.org/c/openstack/nova/+/863915 i looked into why your useage is actully safe but this change between python 2 and 318:39
dansmithsean-k-mooney: yeah I do this all the time to avoid extra indents for no reason.. I'm pretty surprised it's even controversial18:52
sean-k-mooneyits not really just never seen this done before18:52
sean-k-mooneybut again im pretty sure that was because it was not safe on python 2 but we dont need to supprot that anymore18:52
dansmithalso it hasn't changed, python 2.7 works the same way18:52
dansmithI just re-confirmed to convince myself as I still have a system with 2.7 on it18:53
sean-k-mooneywell python2 gave you back the file like object but i tough you had to close that 18:53
dansmithno, when the last reference goes away it closes18:53
sean-k-mooneyok then this is just the inertia of tutorials18:53
sean-k-mooneyack18:53
opendevreviewGhanshyam Mann proposed openstack/python-novaclient stable/yoga: [stable-only] Pin tox <4  https://review.opendev.org/c/openstack/python-novaclient/+/86959718:54
dansmithit's of course not critical to that patch and I could change it, there's just no reason :)18:55
opendevreviewGhanshyam Mann proposed openstack/python-novaclient stable/xena: [stable-only] Pin tox <4  https://review.opendev.org/c/openstack/python-novaclient/+/86959818:55
sean-k-mooneyya im not going to block on it if gibi is fine with the explanation18:55
sean-k-mooneyill keep reviewing the rest in the interim once i do downstream bug triage assignmet18:56
sean-k-mooneydansmith: its just the first time i had seen it so i assumed the same as gibi18:56
opendevreviewManuel Bentele proposed openstack/nova master: libvirt: Add configuration options to set SPICE compression settings  https://review.opendev.org/c/openstack/nova/+/82867520:43
opendevreviewGhanshyam Mann proposed openstack/python-novaclient stable/xena: [stable-only] Pin tox <4  https://review.opendev.org/c/openstack/python-novaclient/+/86959820:46
*** EugenMayer40 is now known as EugenMayer420:53
sean-k-mooneydansmith: if you have time to cast your eyes over teh user-data update spec https://review.opendev.org/c/openstack/nova-specs/+/863884 that would be ideal21:15
opendevreviewMerged openstack/os-vif master: Make tox.ini tox 4.0.0 compatible  https://review.opendev.org/c/openstack/os-vif/+/86842021:18
gmannbauzas: gibi: this is to pin tox<4 for python-novaclient https://review.opendev.org/q/I442568a5f5900e593feb2b5527109e0aa79e5aa7+status:open22:07
gmannbauzas: dansmith : nova rbac default switch is ready https://review.opendev.org/c/openstack/nova/+/866218  which need placement test fixture change too https://review.opendev.org/c/openstack/placement/+/869525/322:08
dansmithsean-k-mooney: yep thanks22:16
dansmithgmann: will have to be tomorrow22:16
gmanndansmith: sure, thanks22:16
*** dasm is now known as dasm|off22:20

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