| darkhorse | dansmith: thank you very much! | 00:46 |
|---|---|---|
| elodilles | bauzas sean-k-mooney : if you are around: the final wallaby release patch has merged, so a formal +1 would be good for the transition patch: https://review.opendev.org/c/openstack/releases/+/862298 | 11:55 |
| sean-k-mooney | this si EM os-vif too | 12:52 |
| sean-k-mooney | elodilles: i think we need a release of os-vif to get the correct upperconstrati | 12:52 |
| sean-k-mooney | i was going to do a release of that this week for that reason | 12:52 |
| sean-k-mooney | elodilles: ya we still need to do that for wallaby we noticed it downstream last week | 12:53 |
| sean-k-mooney | https://github.com/openstack/os-vif/blob/2.4.0/tox.ini#L12 | 12:53 |
| sean-k-mooney | let me do a 2.4.1 release quickly then we can tansiation it to EM | 12:54 |
| elodilles | sean-k-mooney: i heard that RH uses the releases a bit differently (i guess building the packages from based on tags) but most users tend to consume the released pypi packages and tarballs, and upper-constraints are not compiled in those packages | 12:56 |
| sean-k-mooney | we actully dont use the tox env in general but it confused some | 12:57 |
| elodilles | sean-k-mooney: so that's why it should not be released, because it would contain the very same content as the previous relese, and would just confuse operators | 12:57 |
| sean-k-mooney | rdo only packages the released rpm in general | 12:57 |
| sean-k-mooney | well are you saying we dont include tox.ini in the package | 12:57 |
| sean-k-mooney | i woudl have expected that to be in the tar | 12:58 |
| sean-k-mooney | so you can run the tests | 12:58 |
| sean-k-mooney | if its not then we dont need to do anything | 12:58 |
| sean-k-mooney | i guess i can check | 12:58 |
| elodilles | in pypi packages i'm sure we don't have it | 12:59 |
| elodilles | besides, the code would be the very same either way | 12:59 |
| sean-k-mooney | its in the tar | 13:00 |
| sean-k-mooney | https://tarballs.opendev.org/openstack/os-vif/os_vif-2.4.0.tar.gz | 13:00 |
| sean-k-mooney | and the tar is the primary release artifact | 13:00 |
| sean-k-mooney | the tar is what the rpm and deb packages are built form | 13:00 |
| sean-k-mooney | elodilles: you are correct that its not in the wheel | 13:01 |
| sean-k-mooney | elodilles: so its in the tar published to pypi but not the whl | 13:02 |
| sean-k-mooney | https://files.pythonhosted.org/packages/14/2a/dc1cac486333a725c3835b9e8d33ec4ab3bb0ed3e0f49d6354548c8cde1f/os_vif-2.4.0.tar.gz | 13:02 |
| sean-k-mooney | elodilles: so i think we should like fix this unless you strongly disagree | 13:03 |
| elodilles | sean-k-mooney: i'd rather not release this, but maybe it's just me :/ | 13:05 |
| *** dasm|off is now known as dasm | 13:09 | |
| elodilles | sean-k-mooney: anyway, please propose the patch if you think it should be released, i'll comment on it, and let's see others opinion about it | 13:10 |
| sean-k-mooney | https://review.opendev.org/c/openstack/releases/+/863644 | 13:11 |
| sean-k-mooney | i had the patch ready locally i ment to do it last week | 13:11 |
| sean-k-mooney | lets see what bauzas thinks | 13:11 |
| sean-k-mooney | other then that im fine with movign things to em now | 13:12 |
| sean-k-mooney | elodilles: i set +1 on the em transition patch so if others dont think we need the os-vif release you can just proceed with merging the em patch | 13:23 |
| elodilles | sean-k-mooney: ack, thanks! | 13:26 |
| sean-k-mooney | elodilles: part of why i at least wanted to push the patch is i told peole i would do it downstream in a ci escalation bug | 13:27 |
| elodilles | i see | 13:27 |
| sean-k-mooney | this was not actully the cause of the downstream issue https://bugzilla.redhat.com/show_bug.cgi?id=2109536 | 13:27 |
| sean-k-mooney | stestr was just not installed in the correct location | 13:28 |
| elodilles | i'll ask about this release on the weekly relmgmt meeting, which will start soon (14:00 UTC) | 13:30 |
| sean-k-mooney | sure | 13:31 |
| elodilles | sean-k-mooney: fyi, there were no strong objection about the os-vif release, so it is +2+W'd (and even released already) | 15:23 |
| elodilles | i'll update the wallaby-em patch in a minute | 15:23 |
| sean-k-mooney | ack i saw the email come in | 15:23 |
| sean-k-mooney | cool | 15:23 |
| sean-k-mooney | ill set +1 on it when done | 15:23 |
| elodilles | sean-k-mooney: https://review.opendev.org/c/openstack/releases/+/862298 | 15:27 |
| opendevreview | Jean-Sébastien Bevilacqua proposed openstack/nova master: Add Lustre support to nova https://review.opendev.org/c/openstack/nova/+/853786 | 15:34 |
| opendevreview | Alexey Stupnikov proposed openstack/nova master: Don't ignore InstanceNotFound exception by libvirt https://review.opendev.org/c/openstack/nova/+/863665 | 15:38 |
| atmark | hello, is it posible to set `resume_guests_state_on_host_boot=true` in nova and then `virsh autostart $domainname --disable` a selected VMs that I don't want to start | 18:45 |
| atmark | will two conflict with each other? | 18:45 |
| dansmith | pretty sure they're unrelated and so the nova one will win, | 18:47 |
| dansmith | but let me see if I can find it | 18:47 |
| dansmith | atmark: by my reading, if the nova tunable is enabled, this is the only logic that might cause us not to take hard_reboot() action on the guest: https://github.com/openstack/nova/blob/master/nova/virt/libvirt/driver.py#L4150-L4172 | 18:51 |
| atmark | dansmith: this it means i cannot mix the two. if leave nova tunable disabled and then virsh autostart selected VMs, will it work or power states will get messed up? | 19:13 |
| atmark | btw, thx for pointing me to code | 19:14 |
| dansmith | atmark: not sure tbh, nova might force it back off if it thinks it should be off, but if it was active and is active by the time nova starts I suspect it'll say "yep, as expected" | 19:52 |
| *** dasm is now known as dasm|off | 20:29 | |
Generated by irclog2html.py 2.17.3 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!