| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2018-08-02 | |||
| 10:55:13 | sean-k-mooney | i was going to ask what do we use it for? | |
| 10:56:00 | stephenfin | Indeed. I imagine we'll need to support Python 3.7 long before we could even think about dropping that. | |
| 10:56:24 | sean-k-mooney | is this what the api-past.ini files are for? | |
| 10:57:29 | cdent | sean-k-mooney: that's what paste (the lib) reads | |
| 10:57:39 | sean-k-mooney | oh we use it in the wsgi scripts. | |
| 10:57:41 | cdent | it configured the middlware stack in noav-api | |
| 10:58:35 | cdent | other projects use it too. placement intentionally chose not to use it because it intentionally doesn't have configurable middleware: you get what you're given | |
| 10:59:43 | sean-k-mooney | cdent: do we test reconfiguring the middelware in nova? | |
| 10:59:53 | cdent | I don't know | |
| 11:00:31 | stephenfin | cdent: I wonder if that risk should be mentioned to anyone, given that Python 3.7 is going to be a thing soon enough? | |
| 11:01:05 | stephenfin | I'm pretty sure someone could reach out to the author and offer to help maintain it (bugfixes and future Python support vs. actual new features), but I'm likely spread too thin to actually do it myself right now | |
| 11:02:02 | sean-k-mooney | stephenfin: well will it. i have not heard anyone seriously suggesting more the 3.6 support | |
| 11:02:18 | cdent | I'll bring it up with the TC crowd this afternoon. I also vaguely know Ian from way way back, so might be able to find something out from him | |
| 11:02:24 | sean-k-mooney | ubuntu 18.04 will be sticking with 3.6 as far as i know | |
| 11:02:31 | stephenfin | cdent: ack | |
| 11:02:33 | cdent | (when I say TC crowd I mostly mean doug) | |
| 11:02:42 | stephenfin | ack ack :) | |
| 11:11:47 | rabel | sean-k-mooney: thanks! | |
| 11:16:40 | gibi | stephenfin: +2 on the tox.ini fix | |
| 12:19:14 | openstack | Launchpad bug 1779845 in OpenStack Compute (nova) "hide_hypervisor_id doesn't hide hyperv signature for Windows VMs" [Undecided,In progress] - Assigned to Konstantinos Samaras-Tsakiris (kosamara) | |
| 12:19:14 | maciejjozefczyk | kosamara: hey, I can confirm that bug: https://bugs.launchpad.net/nova/+bug/1779845 | |
| 12:19:33 | maciejjozefczyk | kosamara: and in fact I just started to working on that point, but you were first ;) | |
| 12:34:34 | openstackgerrit | Merged openstack/nova master: Hook resource_tracker to remove stale node information https://review.openstack.org/587922 | |
| 12:37:34 | bauzas | network issues at home, folks | |
| 12:37:43 | bauzas | just in case you need me | |
| 12:37:46 | sean-k-mooney | maciejjozefczyk: glad to hear. that said strictly speaking it not a bug as you are using hardwar in a way the hardwar vendor explictly does not support and has taken measures to prevent | |
| 12:37:54 | sean-k-mooney | maciejjozefczyk: but i do think we should allow it | |
| 12:38:20 | bauzas | given we're in August and in France, can I hope my network issues to be fixed around Aug 29th ? | |
| 12:38:37 | sean-k-mooney | maciejjozefczyk: so really this is an RFE(request for enhancement) | |
| 12:45:43 | sean-k-mooney | why dos our suspend fucntion in the libvirt diriver not suspend the instance ... | |
| 12:50:37 | maciejjozefczyk | sean-k-mooney: yes, thats not a bug, but RFE. Anyway if we have support for spoofing hypervisor identification inside VM, we should be consistent in that point | |
| 12:50:40 | stephenfin | bauzas: Fancy sending this on its way? https://review.openstack.org/588207 | |
| 12:52:10 | stephenfin | gibi: ta! | |
| 12:52:12 | sean-k-mooney | maciejjozefczyk: we add that capablity sole to work for the usecase of running nvidia gpus in a guest via pci passthrough. it is not support on any other virt driver, but sure | |
| 12:52:43 | openstackgerrit | Eric Fried proposed openstack/nova master: doc: fix resize user guide link https://review.openstack.org/588097 | |
| 12:52:51 | gibi | stephenfin: there are two relatively small refactor that https://review.openstack.org/#/c/586968/ and https://review.openstack.org/#/c/587412/ if you have some time | |
| 12:53:05 | sean-k-mooney | maciejjozefczyk: that said if we were being consitent we would hide every feature observable withing the guest that implies you are in a vm not just the hypervior id. | |
| 12:53:05 | stephenfin | gibi: I'll hit those right now | |
| 12:53:40 | openstackgerrit | Stephen Finucane proposed openstack/nova master: Remove unused stubbing function from test https://review.openstack.org/586968 | |
| 12:58:15 | stephenfin | gibi: Could you expand on your comment here? https://review.openstack.org/#/c/587412/3/nova/tests/functional/libvirt/test_numa_servers.py | |
| 12:58:26 | gibi | stephenfin: looking... | |
| 12:58:40 | stephenfin | i.e. why do we need to re-stub? | |
| 12:59:04 | maciejjozefczyk | sean-k-mooney: yes, anyway if we have usecase we should do this :) nvidia is good example | |
| 12:59:38 | gibi | stephenfin: _IntegratedTestBase base class already set up the generic NeutronFixture which means that nova.network.neutronv2.api.get_client is already stubbed by the NeutronFixture | |
| 12:59:40 | sean-k-mooney | maciejjozefczyk: not nessicarialy. but in this case it is not that invasive a cchange | |
| 13:00:02 | gibi | stephenfin: then L350 sets up another fixture NUMAAffinityNeutronFixture that will also stub nova.network.neutronv2.api.get_client | |
| 13:00:20 | gibi | stephenfin: this is OK as the second stub overrides what the first stub did | |
| 13:00:23 | stephenfin | gibi: ahhh, of course. I missed that we were using the other fixture | |
| 13:00:33 | stephenfin | Not like I wrote that code or anything :) | |
| 13:00:53 | gibi | stephenfin: I guess you had a good vacation at properly reset your brain :) | |
| 13:01:01 | gibi | s/at/that/ | |
| 13:01:06 | sean-k-mooney | maciejjozefczyk: for there binary direver it may or may not be complient with there EULA. for the linux opensource Nouveau driver its probaly fine | |
| 13:01:12 | stephenfin | gibi: Currently trying to remember what "Python" is | |
| 13:01:22 | stephenfin | :) | |
| 13:01:24 | gibi | :) | |
| 13:03:46 | stephenfin | gibi: One other comment (the second one here) https://review.openstack.org/#/c/587412/3/nova/tests/functional/libvirt/test_numa_servers.py | |
| 13:04:12 | stephenfin | sean-k-mooney: Off the top of your head, would calling os_vif.initialize() twice have any bad side effects? | |
| 13:04:33 | sean-k-mooney | stephenfin: no we specificaly check for that | |
| 13:04:57 | gibi | stephenfin: I can remove that os_vif.initialize() as that is already in the fake libivirt now | |
| 13:04:58 | sean-k-mooney | call it a 1000 times in a loop if you like it will only initalise once | |
| 13:05:25 | stephenfin | gibi: Meh, unless you want to, I'm happy to just +W as is. It's a nit | |
| 13:05:26 | sean-k-mooney | stephenfin: unless you pass reset=true | |
| 13:05:43 | stephenfin | sean-k-mooney: Excellent. It's just a clean up so | |
| 13:05:47 | gibi | stephenfin: I will respin it quickly | |
| 13:05:54 | stephenfin | gibi: ack | |
| 13:06:39 | sean-k-mooney | stephenfin: by the way if your remove os_vif.initialize from setup and dont call it at all your test will fail | |
| 13:08:21 | sean-k-mooney | stephenfin: i added it becuse your tests were failing because nova assumes (correctly) that os-vif is initalised when its using it and the code is written in such a way that it fails if its not | |
| 13:09:17 | sean-k-mooney | stephenfin: i put it in setup beacuse i dont know what order the test will be run in | |
| 13:09:37 | stephenfin | sean-k-mooney: Yup, I think is was you that pointed that out to me. It should be good now though because of https://review.openstack.org/#/c/587412/3/nova/tests/unit/virt/libvirt/fakelibvirt.py | |
| 13:09:50 | stephenfin | So it'll get initialized the same time the fake nova-compute service starts | |
| 13:10:11 | sean-k-mooney | oh sweet then ya you can remove it from setup | |
| 13:11:20 | openstack | Launchpad bug 1784353 in OpenStack Compute (nova) "Rescheduled boot from volume instances fail due to the premature removal of their attachments" [Medium,In progress] - Assigned to Lee Yarwood (lyarwood) | |
| 13:11:20 | mriedem | lyarwood: before i get too far into https://bugs.launchpad.net/nova/+bug/1784353 - we don't reschedule on a boot from volume failure | |
| 13:11:21 | sean-k-mooney | or not its a nit as you said. its not needed anymore but not enough for a respin on its own | |
| 13:11:59 | mriedem | lyarwood: or is this non-volume backed, so not really boot from volume, | |
| 13:12:06 | mriedem | just boot with volumes attached, but the root disk is on local storage | |
| 13:15:19 | openstackgerrit | Balazs Gibizer proposed openstack/nova master: Improve NeutronFixture and remove unncessary stubbing https://review.openstack.org/587412 | |
| 13:15:23 | gibi | stephenfin: ^^ | |
| 13:17:32 | stephenfin | gibi: and done | |
| 13:17:40 | gibi | stephenfin: thanks | |
| 13:17:42 | mriedem | lyarwood: do you have some extra changes that make us reschedule on volume attach failures during boot? because we should abort here on any failure to attach volumes https://github.com/openstack/nova/blob/7125dcb9cb821faf3c68526ac34365a28141e480/nova/compute/manager.py#L2320 | |
| 13:18:23 | lyarwood | mriedem: I've used BFV instances in the regression tests and just mocked out spawn to fail, not the volume attachments etc | |
| 13:18:39 | mriedem | lyarwood: that's not your bug though | |
| 13:18:46 | mriedem | your bug is not that spawn fails, but volume attach fails | |
| 13:19:06 | mriedem | oh wait, | |
| 13:19:11 | mriedem | i think i get it, | |
| 13:19:13 | lyarwood | mriedem: that's for the following attempt | |
| 13:19:14 | mriedem | first boot spawn() fails, | |
| 13:19:16 | mriedem | reschedule, | |
| 13:19:17 | lyarwood | mriedem: yeah | |
| 13:19:22 | mriedem | 2nd host fails b/c volume attachments are wrong | |
| 13:19:23 | mriedem | ok | |
| 13:19:28 | openstack | bug 1488111 in OpenStack Compute (nova) "Boot from volumes that fail in initialize_connection are not rescheduled" [Wishlist,Confirmed] https://launchpad.net/bugs/1488111 | |
| 13:19:28 | mriedem | b/c bug 1488111 | |
| 13:19:39 | mriedem | i was like, whatchutalkinboutyarwood | |
| 13:19:47 | lyarwood | ^_^ | |
| 13:30:09 | sean-k-mooney | mriedem: lyarwood stephenfin. Quick Question can you think of any reason why i shoulds not replace calls to suspend in cold shapshot case with calles to pause given suspend does not actully suspend the instance regardless of the name or comemnt and its break sriov/pcipasshtough in some cases? | |
| 13:31:30 | sean-k-mooney | im going to try it in any case and see what happens but do ye know why the current bevhaior is to detach all pci devices then save guest ram and not suspend | |
| 13:32:23 | mriedem | don't ask me | |
| 13:32:45 | mriedem | i always have to lookup the difference in libvirt between pause and suspend | |