Earlier  
Later
New Search
Posted Nick Remark
#openstack-nova - 2018-02-02
15:22:23 melwitt bauwser: I know, just saying why the wait was put there initially
15:22:42 melwitt I don't think it should be there now, based on how it behaves and based on the other comment in the file
15:22:58 bauwser melwitt: yup, I just said in the review that with your patch, the only case now where we wait is boot
15:23:07 melwitt yeah
15:23:24 mriedem what did we do before the "blow everything away on reboot"? did we wait, or we just didn't touch the vifs at all?
15:23:53 melwitt didn't touch the vifs
15:24:22 melwitt well, the code has always called plug_vifs for some reason, but before, we didn't *unplug* them
15:24:40 melwitt so we'd call plug_vifs on vifs that were already plugged
15:25:01 melwitt (since _create_domain_and_network calls plug_vifs unconditionally)
15:25:55 openstackgerrit Matt Riedemann proposed openstack/nova master: libvirt: fix native luks encryption failure to find volume_id https://review.openstack.org/539739
15:26:00 mriedem yaaaaarwood: melwitt: ^ now handling pre_live_migration also and unfuckified the test
15:28:21 melwitt ack
15:28:26 Spazmotic Alright well. goodnight then folks.
15:28:59 openstackgerrit Ed Leafe proposed openstack/nova master: Escalate UUID validation warning to error in test https://review.openstack.org/540386
15:29:17 figleaf giblet: ^^ I'm not seeing the exception being raised for bad UUIDs
15:31:04 mriedem melwitt: reading back over the related bug for that comment i left in the resize code, https://bugs.launchpad.net/nova/+bug/1323658
15:31:05 openstack Launchpad bug 1323658 in neutron "Nova resize/restart results in guest ending up in inconsistent state with Neutron" [Medium,Fix released] - Assigned to Dariusz Smigiel (smigiel-dariusz)
15:31:12 mriedem phil day linked this related change https://review.openstack.org/#/c/68942/
15:31:19 mriedem to wait for the guest to stop
15:31:44 mriedem if we're blowing away the guest on a reboot, i wonder if we should be doing that also, although if you're doing a soft reboot i think we give the guest os some time and then hard reboot just blows it away
15:32:04 melwitt yeah, our case is a hard reboot
15:32:35 melwitt meaning you're right, the soft reboot does the graceful shutdown thing and hard reboot doesn't
15:36:29 melwitt I'm trying asking in #openstack-neutron
15:36:38 sean-k-mooney mriedem: in the case of ovs the neutron ovs agent spawns a monitor process that recives noticiation every time a new interfaces is added to ovs
15:37:47 openstackgerrit Chris Dent proposed openstack/nova master: Don't rely on parse.urlencode in url comparisons https://review.openstack.org/540420
15:38:00 mriedem melwitt: this is the closest i get in the history on that other bug for an explanation on why we don't wait for vif plugged on resize https://bugs.launchpad.net/nova/+bug/1323658/comments/57
15:38:01 openstack Launchpad bug 1323658 in neutron "Nova resize/restart results in guest ending up in inconsistent state with Neutron" [Medium,Fix released] - Assigned to Dariusz Smigiel (smigiel-dariusz)
15:39:44 belmoreira melwitt mriedem we upgraded to Ocata yesterday and I'm observing that "memory_mb_used" in "compute_nodes" tables is not correct. However, the resourcetracker log in the hypervisor is correct.
15:39:52 belmoreira Is there a known bug that you are aware about this issue?
15:40:16 melwitt mriedem: nice sleuthing
15:41:14 mriedem melwitt: so in the resize case, we don't wait for vif-plugged events on the destination host because the vifs are already plugged on the source host, and the source host vifs aren't unplugged until the user confirms the resize and we cleanup the guest from the source
15:41:16 melwitt ihar said that if os-vif doesn't rebind the port, neutron would probably not be aware of the unplug/plug. I'm not sure whether it rebinds it
15:44:13 sean-k-mooney mriedem: so when os-vif adds a port we set the neurtorn port uuid in the external_ids field and wehn it get the notification fo the port added the neutron agent looks up the port and does the binding
15:44:32 sean-k-mooney melwitt: os-vif should not be binding the port port binding and port plugging are 2 different things
15:44:50 sean-k-mooney melwitt: you cannont call os-vif wiht an unbound port
15:45:07 melwitt thanks sean-k-mooney. I really need to read a book about this stuff
15:45:24 sean-k-mooney melwitt: if you do you proably will wish you had not :P
15:45:30 melwitt heh, fair
15:45:45 mriedem sean-k-mooney: it sounds like this behavior is different based on if you're using linuxbridge or not
15:46:45 sean-k-mooney mriedem: kind of. the general patteren is the same but some of the details are different
15:46:55 Spazmotic melwitt, you happen to have time to talk?
15:47:12 melwitt Spazmotic: that sounds mysterious
15:47:16 sean-k-mooney mriedem: for ovs neuton can subscrible to notification form the ovsdb for port add/remove events
15:47:26 Spazmotic Lol nah nah I assure you, just a quick conversation about nova related activities
15:47:39 sean-k-mooney melwitt: for linuxbridge i belive they have to poll
15:47:47 Spazmotic If you're too busy it's no rush :)
15:47:47 sean-k-mooney * mriedem ^
15:47:54 melwitt Spazmotic: go ahead
15:48:25 mriedem sean-k-mooney: really just trying to figure out if/why vif plug events from neutron might be different in the case of a hard reboot if you're using LB or OVS
15:48:40 mriedem since the wait logic on the nova side would suck if we had to know it changes per network backend
15:49:18 openstackgerrit Eric Fried proposed openstack/nova master: Fix nits in update_provider_tree series https://review.openstack.org/531260
15:49:18 openstackgerrit Eric Fried proposed openstack/nova master: Use update_provider_tree from resource tracker https://review.openstack.org/520246
15:49:19 openstackgerrit Eric Fried proposed openstack/nova master: Make generation optional in ProviderTree https://review.openstack.org/539324
15:49:19 openstackgerrit Eric Fried proposed openstack/nova master: Move refresh time from report client to prov tree https://review.openstack.org/535517
15:50:08 sean-k-mooney mriedem: if you do a hard reboot we will actully terminate the qemu process and remove the tap and re add it
15:50:23 sean-k-mooney if you are polling you may miss that
15:50:50 sean-k-mooney with ovs you will get the notifcation from the ovsdb for the add and remove
15:52:19 sean-k-mooney mriedem: is this all in relation to https://bugs.launchpad.net/nova/+bug/1323658
15:52:20 openstack Launchpad bug 1323658 in neutron "Nova resize/restart results in guest ending up in inconsistent state with Neutron" [Medium,Fix released] - Assigned to Dariusz Smigiel (smigiel-dariusz)
15:52:36 mriedem sean-k-mooney: no, https://review.openstack.org/#/c/540168
15:57:16 bauwser damn, interesting convo about vif pluging and neutron agents
15:57:24 giblet figleaf: Locally it raises for me if I pull the oslo ovo patch into my env (Depends-On: https://review.openstack.org/540344)
15:57:38 giblet figleaf: I mean it raised before the rebase
15:57:55 giblet figleaf: let me try with the new patch
15:58:22 bauwser mriedem: yeah, I guess the crux of the problem is how linuxbridge notifies the events
15:58:34 bauwser since that bug report is all about it
15:59:07 bauwser I mean for Quantum
15:59:08 sean-k-mooney welll so i think we are conflating too things here
15:59:16 sean-k-mooney vif pluging and vif binding
15:59:27 bauwser vif binding is the allocation, right?
15:59:28 sean-k-mooney vif plugging is the act of adding the tap to the backend
15:59:40 bauwser vif plugging is the fact to attach the vif to the guest ?
16:00:03 sean-k-mooney vif binding id that ack of the neutron ml2 direver populating the port details with a vif_type and vif_binding_details
16:00:25 mriedem this might be closer to the issue https://review.openstack.org/#/c/540168/1/nova/virt/libvirt/driver.py@5372
16:00:38 mriedem for one, we're operating on a stale cache to determine which vifs to wait for
16:00:46 mriedem b/c we never wait for the vifs to be unplugged and refresh the nw info cache
16:01:02 mriedem based on that, it's likely better to yes just ignore the vif plugged event,
16:01:19 mriedem in the server create case, we have the async network info wrapper that is waiting for the nw_info cache updates during port binding,
16:01:24 mriedem and then the virt driver spawn is waiting on those
16:01:40 mriedem so the nw info cache is up to date in the server create case, but we have nothing like that in the case of hard reboot
16:02:26 melwitt yeah, IIUC we get the network_info fresh at the beginning of a reboot and then that's it
16:02:33 sean-k-mooney mriedem: well one thing im not clear on. when we do a hard reboot do we redo the neutron port binding or jsut reuse the old one
16:02:43 mriedem re-use the existing one
16:03:38 sean-k-mooney well the neutron event is sent when neutron finish wirieing up a prot for the first time after portbinding. i dont know if neutron will send it again if we dont rebind
16:04:06 mriedem it must, otherwise this would be 100% fail in the gate
16:04:09 mriedem what we have is a race right now
16:04:25 sean-k-mooney mriedem: oh thats good to know
16:05:37 mriedem melwitt: i think we should probably not copy the comment from finish_migration
16:06:11 mriedem i bet this is primarily an issue based on (1) which network backend you're using and (2) the fact we're operating on a stale nw info cache, which is different from how spawn() works and waits for vif plug events
16:06:20 bauwser mriedem: melwitt: good point, the nw_info is only accurate when we call hard_reboot, not when it comes to _create_domain_and_nw()
16:06:24 melwitt okay
16:06:26 mriedem and therefore we should assume the vifs are already plugged and we don't need to wait for them
16:06:43 mriedem if we wanted to be thorough,
16:07:00 mriedem we'd (1) wait for the vif-unplugged event, and then (2) refresh the nw-info cache before moving on to plug the vifs
16:07:08 bauwser right
16:07:27 mriedem i'm not advocating that we do that in this patch, since we have to backport this
16:07:34 mriedem melwitt: so if you wanted to just update the comments, i'd be cool with that
16:07:56 melwitt I was scrutinizing the logs of a failed run yesterday
16:07:56 bauwser fair enough
16:10:10 sean-k-mooney mriedem: when you say the vif are already plugged you mean from a neutron point of view correct. not that the vif is added to the backend which is done by os-vif

Earlier   Later