| opendevreview | David Sedgmen proposed openstack/nova master: Nova: Add workaround to mask mpx on compareCPU() https://review.opendev.org/c/openstack/nova/+/869536 | 03:54 |
|---|---|---|
| gibi | gmann, 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.txt | 08:55 |
| *** priteau_ is now known as priteau | 08:58 | |
| gibi | it seems that nova functional jobs are hit but unit test jobs arent | 09:05 |
| songwenping_ | passwd | 09:06 |
| *** songwenping_ is now known as swp20 | 09:10 | |
| gibi | both job using tox 4.2.6 which supposed to contain the fix of missing interpreters | 09:19 |
| bauzas | gibi: sorry, this vgpu downstream reproducer vamps me | 09:20 |
| bauzas | gibi: can you please explain me the current status for tox4 issues ? | 09:21 |
| gibi | bauzas: o/\ | 09:21 |
| gibi | bauzas: so https://github.com/tox-dev/tox/pull/2828 supposed to fix the missing interpreter error that hit both unit and functional test jobs | 09:22 |
| gibi | bauzas: it merged and released during the weekend in 4.2.5 | 09:22 |
| bauzas | kk | 09:22 |
| gibi | bauzas: this morning I rechecked one of my patch | 09:22 |
| gibi | bauzas: the unit test jobs passed there with tox 4.2.6 | 09:23 |
| gibi | bauzas: but the functional ones are still failing with the missing interpreter error | 09:23 |
| bauzas | gibi: are you sure you're not pinned by a previous tox version ? | 09:23 |
| gibi | this is the recheck run I watch https://zuul.opendev.org/t/openstack/status#854615 | 09:23 |
| gibi | I'm pretty sure both jobs run with 4.2.6 but feel free to double check the logs | 09:25 |
| sahid | 220185 | 09:26 |
| bauzas | 2023-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 |
| bauzas | gibi: indeed ^ | 09:27 |
| gibi | I think I can reproduce it locally in a container with tox 4.2.6 | 09:29 |
| gibi | maybe it does not understand our generative tox env definition any more `[testenv:functional{,-py38,-py39,-py310}]` | 09:32 |
| bauzas | hmmm | 09:33 |
| gibi | no | 09:34 |
| gibi | simplifying that to `[testenv:functional-py310]` still doesnt work | 09:34 |
| bauzas | can you just remove the python version suffix ? | 09:34 |
| bauzas | with tox, it could autocreate the right dirs IIRC | 09:35 |
| gibi__ | my home internet went down | 09:42 |
| gibi__ | I'm not sure what I was able to send last time | 09:43 |
| gibi__ | so simplifying the tox target to functional-py310 does not help | 09:43 |
| bauzas | gibi__: can you create just a tox target without the python version ? | 09:43 |
| bauzas | I guess you have py39 default | 09:44 |
| gibi__ | let me see | 09:44 |
| gibi__ | hm, if I change the functional-py310 to functionalpy310 then it seems to work | 09:46 |
| gibi__ | the problem is that it then ignores the py310 part of the target and runs with whathever python3 interpreter I have | 09:47 |
| gibi__ | so functionalpy39 runs with the same python3.10 I have installed | 09:47 |
| sahid | o/ any chance to get some reviews on https://review.opendev.org/c/openstack/nova/+/858383 ? | 09:49 |
| sahid | perhpas gibi__ when you have a moment :D ^ | 09:50 |
| gibi__ | bauzas: so I do believe that the generative env feature is broken somehwo | 09:51 |
| gibi__ | stephenfin: ^^ | 09:51 |
| bauzas | gibi__: yeah, that's my guess | 09:51 |
| gibi__ | sahid: ack, I'm not sure when I will have that moment, sorry | 09:51 |
| bauzas | gibi__: tox can't guess which python interpreter to use | 09:51 |
| bauzas | that said, it looks a large regression | 09:52 |
| * bauzas wonders whether pyproject.toml has the same issue | 09:53 | |
| bauzas | gibi__: ^ | 09:53 |
| * bauzas looks at https://tox.wiki/en/4.2.6/config.html | 09:55 | |
| opendevreview | Balazs Gibizer proposed openstack/nova master: Define basepython for functional targets https://review.opendev.org/c/openstack/nova/+/869545 | 09:57 |
| gibi__ | bauzas: ^^ this seems to work locally | 09:57 |
| bauzas | theorically, this shouldn't be needed | 09:58 |
| bauzas | https://tox.wiki/en/4.2.6/config.html#base_python | 09:59 |
| gibi__ | yeah, it worked before | 09:59 |
| bauzas | unfortunately 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-settings | 10:00 |
| gibi__ | I will open an issue for tox maybe the devs knows more | 10: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 |
| bauzas | so I guess the default factors no longer work | 10: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 found | 10:09 |
| gibi__ | bauzas, gmann, stephenfin: opened https://github.com/tox-dev/tox/issues/2838 | 10:20 |
| bauzas | gibi__: we could remove basepython IMHO | 10:21 |
| gibi__ | we could if we assume no env will have python2.7 as a default interpreter installed | 10:23 |
| stephenfin | yeah, be can/should drop basepython at this point | 10:37 |
| stephenfin | *we | 10:37 |
| stephenfin | gibi: replied on the tox bug also | 10:39 |
| gibi__ | stephenfin: I tried in tox 3.28 and I did not need ingnore_base_python_conflict to make it work | 10:40 |
| gibi__ | stephenfin: you can simply remova that from nova's tox.ini and it work in tox 3.28 for me locally | 10:40 |
| gibi__ | stephenfin: anyhow so you suggest to just remove basepython = python3 and assume people's machine has python3 by default | 10:42 |
| gibi__ | (which could be a fair assumption having python2.7 in EOL) | 10:43 |
| stephenfin | I think that's a reasonable workaround, yes | 10:43 |
| gibi__ | OK, I will change https://review.opendev.org/c/openstack/nova/+/869545 to drop basepython instead of defining it for each generative env | 10:44 |
| gibi__ | and then I can also try to drop ignore_basepython_conflict | 10:45 |
| stephenfin | oh, 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__ | OK | 10:46 |
| sean-k-mooney | bauzas: yes you can use tox -e py3|functional | 10:50 |
| sean-k-mooney | those will use your defalt python | 10:50 |
| sean-k-mooney | we only set basepython to cater for python2 vs python3 | 10:51 |
| sean-k-mooney | so yes we can drop it now | 10:51 |
| opendevreview | Balazs Gibizer proposed openstack/nova master: Remove basepython def from tox.ini https://review.opendev.org/c/openstack/nova/+/869545 | 10:53 |
| gibi__ | stephenfin, bauzas: ^^ | 10:53 |
| sean-k-mooney | gibi__: so regarding https://review.opendev.org/c/openstack/os-vif/+/869500 that now works but we need to squash it into your patch | 10:54 |
| sean-k-mooney | or in your patch you can disable the functional jobs and we can re enable it in this one | 10:54 |
| sean-k-mooney | gibi__: any prefernce | 10:54 |
| gibi__ | I need to update that tox patch to remove basepython and ignore_basepython_conflict, I can do a squash at the same time | 10:56 |
| darkhorse | artom: 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 first | 10:57 |
| sean-k-mooney | gibi__: cool works for me enjoy your lunch | 10:59 |
| gibi__ | thanks | 11:00 |
| opendevreview | Balazs Gibizer proposed openstack/os-vif master: Make tox.ini tox 4.0.0 compatible https://review.opendev.org/c/openstack/os-vif/+/868420 | 11:31 |
| gibi__ | sean-k-mooney: ^^ fix with the squash | 11:31 |
| sean-k-mooney | gibi__: thanks +2 although ignoring 2 +2s thing for a sec given i wrote part of this i want someone else to +w anyway | 11:40 |
| opendevreview | sean 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/+/861468 | 11:42 |
| gibi__ | stephenfin: if you have a sec then here https://review.opendev.org/c/openstack/placement/+/868418 I think we have some disagreements | 11:51 |
| sean-k-mooney | gibi__: the convention we had for the deps is generally to inherit and extend | 11:56 |
| sean-k-mooney | like this | 11:57 |
| sean-k-mooney | deps = | 11:57 |
| sean-k-mooney | {[testenv]deps} | 11:57 |
| sean-k-mooney | -r{toxinidir}/doc/requirements.txt | 11:57 |
| sean-k-mooney | i think that is what stephen was sugessing but not sure | 11:57 |
| sean-k-mooney | to 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.txt | 11:57 |
| gibi__ | sean-k-mooney: extending deps alone is not enough, it seems deps are not properly applied during the editable install of the package | 12:01 |
| gibi__ | basically the editable install makes the deps unconstrained | 12:01 |
| gibi__ | (from above) | 12:01 |
| sean-k-mooney | really thats not what i was expecting | 12:01 |
| sean-k-mooney | i guess that is a delete in the skipsdist behavior | 12:02 |
| sean-k-mooney | by not skiping we build a wheel and install form that | 12:02 |
| stephenfin | gibi__: looking | 12:02 |
| sean-k-mooney | presumable its the build step that might be the issue? | 12:03 |
| stephenfin | oh, interesting | 12:04 |
| gibi__ | sean-k-mooney: yes it could be related to removing skipdist | 12:06 |
| sean-k-mooney | use_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 think | 12:06 |
| stephenfin | hmm, 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 alright | 12:06 |
| sean-k-mooney | we coudl just move the -c line to the deps of testenv | 12:07 |
| sean-k-mooney | then do {[testenv]deps} | 12:07 |
| stephenfin | But yeah, overriding 'install_command' is certainly less likely to cause issue | 12:07 |
| sean-k-mooney | anytime we are modifing the deps later | 12:07 |
| stephenfin | sean-k-mooney: what gibi's saying though is that the package itself (i.e. placement or nova) is installed without constraints | 12:08 |
| stephenfin | so 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 package | 12:08 |
| gibi__ | stephenfin: we install our deps with constraints yes, but then we install the placement package's deps again without constriants | 12:08 |
| stephenfin | so best to override the install_command | 12:08 |
| sean-k-mooney | ok but woudl we not | 12:09 |
| sean-k-mooney | ya would we not need to change that ^ | 12:09 |
| stephenfin | we should drop '-rrequirements.txt' from 'deps' too since it's now unnecessary and potentially confusing | 12:09 |
| gibi__ | OK, I can move everything to install_command | 12:09 |
| sean-k-mooney | this looks a littel differnt then normal actully | 12:09 |
| gibi__ | and drop deps | 12:10 |
| sean-k-mooney | https://github.com/openstack/os-vif/blob/master/tox.ini | 12:10 |
| stephenfin | I'd keep 'deps' but only for test-requirements.txt and doc/requirements.txt | 12:10 |
| sean-k-mooney | if we compare it to osvif we droped the install_command a while ago | 12:10 |
| stephenfin | sean-k-mooney: you've got 'skipsdist = true' though | 12:11 |
| sean-k-mooney | true | 12:11 |
| stephenfin | so it won't actually install os-vif | 12:11 |
| sean-k-mooney | but for nova we doint | 12:11 |
| sean-k-mooney | https://github.com/openstack/nova/blob/master/tox.ini | 12:11 |
| stephenfin | Yup, so it will install nova | 12:11 |
| sean-k-mooney | ok that is why the os-vif packages were not being installed | 12:12 |
| stephenfin | os-vif is working because Python adds $PWD to $PYTHONPATH | 12:12 |
| stephenfin | or rather, was | 12:12 |
| stephenfin | but I think tox 4 might have changed that, idk | 12:12 |
| sean-k-mooney | we could have actully kept the two commits sepeate instaed fo squashihng them | 12:12 |
| sean-k-mooney | stephenfin: 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 found | 12:13 |
| sean-k-mooney | this combined one works https://review.opendev.org/c/openstack/os-vif/+/868420/3 | 12:13 |
| sean-k-mooney | but we also could have used install command i guess | 12:14 |
| stephenfin | gibi__: one other thing: instead of 'pip install' can we do 'python -m pip install' | 12:15 |
| stephenfin | there's a reason for that that clarkb brought up on openstack-discuss recently (I think) but I don't recall what | 12:16 |
| stephenfin | it's what tox itself does though | 12:16 |
| sean-k-mooney | i have been pushing people to move to -m pip install and got that changed in devstack | 12:17 |
| sean-k-mooney | there are some odd behaivors with user install/venvs when using pip that does not happen if you use python -m pip | 12:17 |
| sean-k-mooney | bascailly you can have the pip package isntalled without the pip script being in your current path | 12:18 |
| sean-k-mooney | also due to how setup tools console scripts work there can also be some funkyness in a mixed python2/python3 enve with the #! line | 12:19 |
| sean-k-mooney | so the module apporch is just generally more robost | 12:19 |
| gibi__ | ack | 12:23 |
| opendevreview | Balazs Gibizer proposed openstack/placement master: Make tox.ini tox 4.0.0 compatible https://review.opendev.org/c/openstack/placement/+/868418 | 13:46 |
| gibi | stephenfin, sean-k-mooney: ^^ | 13:46 |
| kashyap | gibi: 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 |
| gibi | sean-k-mooney, stephenfin: I cannot switch os-vif to install_command from deps it results in https://paste.opendev.org/show/bkSH8jaL4WH04S2sge5t/ | 13:54 |
| gibi | basically we have a constraing about os-vif in global requirements so the editable install building locally will conflict with the global constraint | 13:54 |
| stephenfin | okay, I guess we need to continue using 'deps' there so | 13:55 |
| gibi | stephenfin: even if it means we allow ignoring the upper constraint during the editable install? | 13:55 |
| stephenfin | we'll still install the deps first, right? | 13:55 |
| gibi | right | 13:58 |
| gibi | but the package install can decided to upgrade the deps as there is no constraint there | 13:58 |
| stephenfin | but would it, assuming the deps are already satisfied? | 13:58 |
| gibi | I don't know but relying on that feels dirty :) | 13:59 |
| stephenfin | It does, yeah :) | 13:59 |
| gibi | kashyap: I'm not even sure I understand the problem statement in that patch | 13:59 |
| stephenfin | I wonder if this is a pip bug? | 13:59 |
| gibi | it feels like a tox shortcoming as tox calls pip install | 14:00 |
| gibi | to install the deps of the package | 14:00 |
| *** dasm|off is now known as dasm | 14:01 | |
| gibi | basically the install_package_deps step in tox ignores the deps | 14:02 |
| gibi | so even if we put the constraint in the deps it has no effect | 14:03 |
| gibi | install_package_deps does use the install_commmand hence our solution in placement to put the constraint there. | 14:03 |
| kashyap | gibi: 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 |
| kashyap | gibi: 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 |
| kashyap | gibi: ... 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 |
| gibi | but 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 work | 14:09 |
| kashyap | gibi: Yeah, indeed! That said: libvirt developers themselves now tell me that we (Nova) doesn't need to do that check anymore | 14:10 |
| kashyap | gibi: Read this comment from Jiri here: | 14:10 |
| kashyap | https://bugzilla.redhat.com/show_bug.cgi?id=2138381#c7 | 14:10 |
| kashyap | Especially the 2nd paragraph | 14:11 |
| kashyap | gibi: 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 correct | 14:11 |
| kashyap | As it provides most benefit with the shortest patch, IMHO. | 14:11 |
| gibi | OK. do you suggest to revive https://review.opendev.org/c/openstack/nova/+/772917/ ? | 14:11 |
| gibi | will that solve the issue behind https://review.opendev.org/c/openstack/nova/+/869536 too? | 14:12 |
| kashyap | Yes, definitely. Based on that commit message rationale _and_ the advice of CPU modelling maintainer from libvirt | 14:12 |
| kashyap | gibi: Yes | 14:13 |
| kashyap | I'll comment there | 14:13 |
| kashyap | Before removing that patch, we also have to deprecate (and remove later) this workaround: CONF.workarounds.skip_cpu_compare_on_dest | 14:14 |
| gibi | I'm OK with this approach | 14:16 |
| gibi | I don't believe we have the bandwidth to land https://review.opendev.org/q/topic:bp%252Fcpu-selection-with-hypervisor-consideration | 14:17 |
| kashyap | gibi: Uh, I made a messy mistake in thinking: please ignore the above. Here's my correction: | 14:17 |
| kashyap | gibi: We should actually get rid of _this_ compare_cpu() check in _ceck_cpu_compatibility() method - | 14:17 |
| kashyap | https://github.com/openstack/nova/blob/8a476061c5e034016668cd9e5a20c4430ef6b68d/nova/virt/libvirt/driver.py#L991 | 14:17 |
| * kashyap proposes a test patch | 14:17 | |
| kashyap | gibi: But the reason is the same. (The only correction is a different | 14:19 |
| kashyap | ... method in Nova. | 14:19 |
| gibi | ack | 14:20 |
| gibi | feel free to ping me if I need to re-review the https://review.opendev.org/c/openstack/nova/+/772917/ | 14:20 |
| kashyap | Nod, 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-mooney | kashyap: in general im not sure i agree that we should relay on libvirt for the cpu compat check | 14:24 |
| kashyap | sean-k-mooney: Why? What reason do we have? | 14:25 |
| sean-k-mooney | i know libvirt will do it properly but i thing this is somethign that nova shoudl do not the hyperviros in general | 14:25 |
| kashyap | FWIW, 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 |
| kashyap | Doing it ourselves is costly and error-prone at this point. | 14:25 |
| sean-k-mooney | it may be the right approch form a libvirt point of view | 14:26 |
| kashyap | When the hypervisor (in this case libvirt + QEMU) is _already_ doing it, let's please rely on it | 14:26 |
| sean-k-mooney | but nova should have validateed the destination for compatibality before we invokve libvirt | 14:26 |
| kashyap | sean-k-mooney: No, their advice is for management tools in general. | 14:26 |
| sean-k-mooney | in fact form an nova point of veiw we shoudl have valdiated it entirly as part fo schudling | 14:26 |
| kashyap | sean-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-mooney | form a nova point of view pre-livemigrate is already quite late | 14:26 |
| kashyap | Yeah, "ideally..." scenarios are hard at this point :-) | 14:27 |
| kashyap | sean-k-mooney: That's the one on destination skip: https://code.engineering.redhat.com/gerrit/c/nova/+/405286 | 14:28 |
| kashyap | (Same reasoning in my commit applies for src check) | 14:28 |
| sean-k-mooney | so form my perspective not validating all requirement in pre-livemigrateis incorrect but i understand why you want o delegate this to libvirt | 14:28 |
| kashyap | Thank you. I'm getting tired of some these reports and playing whack-a-mole :( | 14:29 |
| sean-k-mooney | so i think goign forward we may need to reqest a new feature in libvirt or desgin a new feature in nova | 14:30 |
| kashyap | sean-k-mooney: What would the new RFE for libvirt be? | 14:30 |
| sean-k-mooney | i consider it a bug to not validate all requiremnt like cpu compatiabliy so eventully i woudl like a more relyable way to do that validation | 14:30 |
| sean-k-mooney | kashyap: im not quite sure | 14:31 |
| kashyap | libvirt 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 + dest | 14:31 |
| sean-k-mooney | in general i would like a more declaritive way to understand if live migratoin is possibel | 14:31 |
| sean-k-mooney | so that we can model this in placment in some way but i dont know what that woudl look like | 14:32 |
| sean-k-mooney | the imperitive check we have right now by invoking cpu_compare or the new apis is not really compatible with nova current schduling model | 14:32 |
| sean-k-mooney | that is why they happen late after schuding as pre miggrate checks | 14:33 |
| kashyap | (Right. That's future goodness if we have cycles. :)) | 14:33 |
| kashyap | gibi: 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-mooney | proably the import_lib version | 14:35 |
| sean-k-mooney | althogh i think we dropped support for python 3.7 | 14:35 |
| sean-k-mooney | we used to have a workaround for older python versions | 14:35 |
| kashyap | Right; I just learn that flake8 on master min requires 3.8 | 14:35 |
| sean-k-mooney | not quite master required 3.8 | 14:35 |
| sean-k-mooney | but importlib_metadata gain suppport for some feautre sin 3.8 | 14:36 |
| sean-k-mooney | before that we had a workaorund when we had 3.6 suoprt still | 14:36 |
| * kashyap looks | 14:36 | |
| sean-k-mooney | anyway if you can use 3.8 that woudl be better | 14:37 |
| kashyap | Yeah, trying :) | 14:39 |
| sean-k-mooney | you could change [testenv:pep8] to [testenv:pep8{,-py38,-py39,-py310}] | 14:39 |
| sean-k-mooney | pep8 is runnign with your systems default python | 14:40 |
| sean-k-mooney | so your other option is to update the alternitives to make python3.8 the default python | 14:40 |
| sean-k-mooney | actully you can create a python venv with 3.8 and run tox form that too if needed | 14:40 |
| kashyap | It's a new venv; but the pre-commit hook seems to use system python | 14:41 |
| sean-k-mooney | what im suggestign is you should do python3.8 -m venv .venv | 14:45 |
| sean-k-mooney | and install precommit and tox in that | 14:45 |
| sean-k-mooney | and use those to mange your tox envs and commit ectra | 14:45 |
| sean-k-mooney | if you are not able to update your default system python to 3.8+ | 14:46 |
| kashyap | $> /usr/bin/python3 --version | 14:46 |
| kashyap | Python 3.10.8 | 14:46 |
| kashyap | Default system is already well above 3.8+. I just don't know how pre-commit is getting 3.7 | 14:46 |
| sean-k-mooney | od | 14:46 |
| sean-k-mooney | i would unistall and reinstal it | 14:47 |
| kashyap | Yep, tryin | 14:47 |
| kashyap | This fixed it for me: | 15:16 |
| kashyap | $> pre-commit install --allow-missing-config | 15:16 |
| kashyap | $> rm -rf /home/kashyapc/.cache/pre-commit/ | 15:16 |
| opendevreview | Balazs Gibizer proposed openstack/nova master: Remove basepython def from tox.ini https://review.opendev.org/c/openstack/nova/+/869545 | 15:18 |
| gibi | bauzas: ^^ needed to unblock the nova gate | 15:19 |
| gibi | bauzas: and https://review.opendev.org/c/openstack/placement/+/868418 needed to unblock the placement gate | 15:20 |
| opendevreview | Balazs Gibizer proposed openstack/placement master: Make tox.ini tox 4.0.0 compatible https://review.opendev.org/c/openstack/placement/+/868418 | 15:21 |
| darkhorse | artom: 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 |
| artom | darkhorse, has to be shelved_offloaded | 15:46 |
| artom | That's either a manual step after the instance is shelved, or done automatically by the cloud depending on config | 15:46 |
| darkhorse | artom: yes its shelved_offloaded. | 15:46 |
| artom | Err, there should be an image... | 15:47 |
| artom | Unless it's boot from volume? I'm not sure about that case | 15:47 |
| darkhorse | no its not boot from volume | 15:48 |
| darkhorse | I launched the instance from cirros image and flavor. | 15:48 |
| bauzas | gibi: sorry was at the school for getting my child | 15:48 |
| bauzas | reviewing the change | 15:48 |
| bauzas | and thanks for having worked on it :) | 15:48 |
| artom | darkhorse, not sure what to tell you. If the shelve was successful there should be an image. | 15:51 |
| darkhorse | Is 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 |
| artom | Normally only admins can shelve, and admins can see all the images | 16:06 |
| bauzas | I have a network issue folks | 16:09 |
| bauzas | sean-k-mooney: I have a network issue, please move on | 16:10 |
| opendevreview | Balazs Gibizer proposed openstack/nova stable/yoga: Reproduce bug 1981813 in func env https://review.opendev.org/c/openstack/nova/+/859312 | 17:07 |
| opendevreview | Balazs Gibizer proposed openstack/nova stable/yoga: Gracefully ERROR in _init_instance if vnic_type changed https://review.opendev.org/c/openstack/nova/+/859313 | 17:08 |
| opendevreview | Balazs Gibizer proposed openstack/nova stable/xena: Reproduce bug 1981813 in func env https://review.opendev.org/c/openstack/nova/+/859314 | 17:14 |
| opendevreview | Balazs Gibizer proposed openstack/nova stable/xena: Gracefully ERROR in _init_instance if vnic_type changed https://review.opendev.org/c/openstack/nova/+/859315 | 17:14 |
| opendevreview | Balazs Gibizer proposed openstack/nova stable/wallaby: Reproduce bug 1981813 in func env https://review.opendev.org/c/openstack/nova/+/859320 | 17:22 |
| opendevreview | Balazs Gibizer proposed openstack/nova stable/wallaby: Gracefully ERROR in _init_instance if vnic_type changed https://review.opendev.org/c/openstack/nova/+/859321 | 17:22 |
| opendevreview | Balazs Gibizer proposed openstack/nova stable/victoria: Reproduce bug 1981813 in func env https://review.opendev.org/c/openstack/nova/+/869583 | 17:31 |
| opendevreview | Balazs Gibizer proposed openstack/nova stable/victoria: Gracefully ERROR in _init_instance if vnic_type changed https://review.opendev.org/c/openstack/nova/+/869584 | 17:31 |
| sean-k-mooney | bauzas: can you take a look at https://review.opendev.org/c/openstack/nova-specs/+/865432 again | 17:34 |
| sean-k-mooney | melwitt: gibi: and if one of ye has time https://review.opendev.org/c/openstack/nova-specs/+/855490 | 17:34 |
| sean-k-mooney | the cinder spec is appvoed for ^ if i recall | 17:35 |
| sean-k-mooney | https://review.opendev.org/c/openstack/cinder-specs/+/866718 | 17:35 |
| melwitt | sean-k-mooney: I've been meaning to get back to that one 😓 | 17:38 |
| opendevreview | Dan Smith proposed openstack/nova master: Add virt/node module for stable uuids https://review.opendev.org/c/openstack/nova/+/863915 | 17:38 |
| opendevreview | Dan Smith proposed openstack/nova master: Pass service ref to init_host(), if exists https://review.opendev.org/c/openstack/nova/+/863916 | 17:38 |
| opendevreview | Dan Smith proposed openstack/nova master: Add get_available_node_uuids() to virt driver https://review.opendev.org/c/openstack/nova/+/863917 | 17:38 |
| opendevreview | Dan Smith proposed openstack/nova master: WIP: Persist existing node uuids locally https://review.opendev.org/c/openstack/nova/+/863918 | 17:38 |
| opendevreview | Dan Smith proposed openstack/nova master: Make resource tracker use UUIDs instead of names https://review.opendev.org/c/openstack/nova/+/863919 | 17:38 |
| opendevreview | Dan Smith proposed openstack/nova master: WIP: Detect host renames and abort startup https://review.opendev.org/c/openstack/nova/+/863920 | 17:38 |
| dansmith | melwitt: sean-k-mooney ^ | 17:43 |
| dansmith | I was able to make it all work without removing that test after all it seems | 17:43 |
| sean-k-mooney | cool is ignore WIP status is that more or less feature complete at this point | 17:43 |
| sean-k-mooney | *so ignoring.. | 17:44 |
| dansmith | the two WIP ones just need more tests | 17:44 |
| sean-k-mooney | ack | 17:44 |
| melwitt | ack also | 17:44 |
| sean-k-mooney | but in terms fo the spec i assume that series now covers most of the work itmes or all of it? | 17:44 |
| dansmith | re: 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 it | 17:45 |
| dansmith | sean-k-mooney: yeah | 17:45 |
| sean-k-mooney | "lambda: None" ... ok i guess that one way to noop | 17:47 |
| sean-k-mooney | i guess fixtures.MockPatch need a callback functions to work | 17:48 |
| opendevreview | Balazs Gibizer proposed openstack/nova stable/ussuri: Reproduce bug 1981813 in func env https://review.opendev.org/c/openstack/nova/+/869585 | 17:48 |
| opendevreview | Balazs Gibizer proposed openstack/nova stable/ussuri: Gracefully ERROR in _init_instance if vnic_type changed https://review.opendev.org/c/openstack/nova/+/869586 | 17:48 |
| opendevreview | Kashyap Chamarthy proposed openstack/nova master: libvirt: Remove compareCPU() check in _check_cpu_compatiblity() https://review.opendev.org/c/openstack/nova/+/869587 | 17:57 |
| opendevreview | Kashyap Chamarthy proposed openstack/nova master: libvirt: Remove compareCPU() check in _check_cpu_compatibility() https://review.opendev.org/c/openstack/nova/+/869587 | 18:01 |
| gmann | gibi: thanks. +2, leaving approval to stephenfin in case anything else missing | 18:06 |
| opendevreview | Ghanshyam Mann proposed openstack/nova master: Enable new defaults and scope checks by default https://review.opendev.org/c/openstack/nova/+/866218 | 18:08 |
| opendevreview | Ghanshyam Mann proposed openstack/placement master: Avoid rbac defaults conflict in functional tests https://review.opendev.org/c/openstack/placement/+/869525 | 18:09 |
| sean-k-mooney | dansmith: 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 3 | 18:39 |
| dansmith | sean-k-mooney: yeah I do this all the time to avoid extra indents for no reason.. I'm pretty surprised it's even controversial | 18:52 |
| sean-k-mooney | its not really just never seen this done before | 18:52 |
| sean-k-mooney | but again im pretty sure that was because it was not safe on python 2 but we dont need to supprot that anymore | 18:52 |
| dansmith | also it hasn't changed, python 2.7 works the same way | 18:52 |
| dansmith | I just re-confirmed to convince myself as I still have a system with 2.7 on it | 18:53 |
| sean-k-mooney | well python2 gave you back the file like object but i tough you had to close that | 18:53 |
| dansmith | no, when the last reference goes away it closes | 18:53 |
| sean-k-mooney | ok then this is just the inertia of tutorials | 18:53 |
| sean-k-mooney | ack | 18:53 |
| opendevreview | Ghanshyam Mann proposed openstack/python-novaclient stable/yoga: [stable-only] Pin tox <4 https://review.opendev.org/c/openstack/python-novaclient/+/869597 | 18:54 |
| dansmith | it's of course not critical to that patch and I could change it, there's just no reason :) | 18:55 |
| opendevreview | Ghanshyam Mann proposed openstack/python-novaclient stable/xena: [stable-only] Pin tox <4 https://review.opendev.org/c/openstack/python-novaclient/+/869598 | 18:55 |
| sean-k-mooney | ya im not going to block on it if gibi is fine with the explanation | 18:55 |
| sean-k-mooney | ill keep reviewing the rest in the interim once i do downstream bug triage assignmet | 18:56 |
| sean-k-mooney | dansmith: its just the first time i had seen it so i assumed the same as gibi | 18:56 |
| opendevreview | Manuel Bentele proposed openstack/nova master: libvirt: Add configuration options to set SPICE compression settings https://review.opendev.org/c/openstack/nova/+/828675 | 20:43 |
| opendevreview | Ghanshyam Mann proposed openstack/python-novaclient stable/xena: [stable-only] Pin tox <4 https://review.opendev.org/c/openstack/python-novaclient/+/869598 | 20:46 |
| *** EugenMayer40 is now known as EugenMayer4 | 20:53 | |
| sean-k-mooney | dansmith: 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 ideal | 21:15 |
| opendevreview | Merged openstack/os-vif master: Make tox.ini tox 4.0.0 compatible https://review.opendev.org/c/openstack/os-vif/+/868420 | 21:18 |
| gmann | bauzas: gibi: this is to pin tox<4 for python-novaclient https://review.opendev.org/q/I442568a5f5900e593feb2b5527109e0aa79e5aa7+status:open | 22:07 |
| gmann | bauzas: 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/3 | 22:08 |
| dansmith | sean-k-mooney: yep thanks | 22:16 |
| dansmith | gmann: will have to be tomorrow | 22:16 |
| gmann | dansmith: sure, thanks | 22:16 |
| *** dasm is now known as dasm|off | 22:20 | |
Generated by irclog2html.py 2.17.3 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!