Earlier  
Posted Nick Remark
#openstack-nova - 2018-08-02
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
13:33:17 lyarwood sean-k-mooney: hmmm iirc we need to detach PCI devices as we can't save or restore their state
13:33:46 sean-k-mooney lyarwood: to stop dma transfer or somthing?
13:34:54 sean-k-mooney in any case the current state seams broken.
13:35:00 lyarwood sahid: ^ do you know?
13:35:09 lyarwood sean-k-mooney: I'm not sure tbh
13:35:53 lyarwood sean-k-mooney: and yeah suspend just saves the domain state to disk right? So that wouldn't help during a cold snapshot.

Earlier   Later