| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2017-04-24 | |||
| 14:33:18 | openstackgerrit | jichenjc proposed openstack/nova master: Use plain routes list for flavors-extraspecs endpoint instead of stevedore https://review.openstack.org/456585 | |
| 14:33:18 | openstackgerrit | jichenjc proposed openstack/nova master: Use plain routes list for '/os-aggregates' endpoint instead of stevedore https://review.openstack.org/456825 | |
| 14:33:19 | openstackgerrit | jichenjc proposed openstack/nova master: use plain routes list for hypervisor endpoint instead of stevedore https://review.openstack.org/459235 | |
| 14:33:19 | openstackgerrit | jichenjc proposed openstack/nova master: Use plain routes list for '/os-keypairs' endpoint instead of stevedore https://review.openstack.org/456478 | |
| 14:34:00 | jaypipes | bauzas: heh, indeed... | |
| 14:34:12 | jaypipes | bauzas: when is the second round vote day? | |
| 14:34:27 | bauzas | jaypipes: May the 7th | |
| 14:34:32 | jaypipes | hmm. | |
| 14:34:37 | jaypipes | good luck! | |
| 14:34:37 | bauzas | I'd hope it would have been May the 4th... | |
| 14:34:42 | jaypipes | heh | |
| 14:34:44 | jaypipes | indeed. | |
| 14:35:18 | bauzas | anyway, my wife will proxy my vote, so I'm fine with my mind | |
| 14:52:11 | mriedem | alex_xu: Kevin_Zheng: it's very confusing but I think i know why you're trying to stash the tags on the BuildRequest in https://review.openstack.org/#/c/394321/36/nova/compute/api.py | |
| 14:52:15 | mriedem | i'm leaving a ton of comments :) | |
| 14:52:19 | mriedem | but i think we're doing this the hard way | |
| 14:52:27 | mriedem | and i think some of the code in the api for this is all dead now | |
| 14:52:30 | mriedem | so i'm going to clean it up | |
| 14:52:36 | mriedem | in a separate patch | |
| 14:52:47 | mriedem | i.e. i think this was a workaround until we were creating instances and bdms in conductor | |
| 14:53:02 | mriedem | i'll have dansmith take a look later too in case i'm missing something | |
| 14:53:44 | Kevin_Zheng | mriedem: cool thanks, I will check tomorrow | |
| 14:54:13 | bauzas | mriedem: jaypipes: FWIW, I'm entering into the hell zone of deletes wrt claims | |
| 14:54:52 | mriedem | bauzas: fwiw, i spent 6 hours yesterday in the hell zone that is swap volume | |
| 14:54:53 | bauzas | mriedem: jaypipes: AFAICT, we currently unclaim the resources (ie. we DELETE allocations) only by the compute service, right ? | |
| 14:55:20 | jaypipes | bauzas: yes, AFAIK. | |
| 14:55:26 | bauzas | mriedem: jaypipes: so, what happens in the case of a local delete where we gently instance.delete() ? | |
| 14:55:40 | bauzas | do we DELETE /allocations too ? None from what I can tell | |
| 14:55:42 | jaypipes | bauzas: only in the periodic audit interval task (update_available_resource) | |
| 14:56:08 | mriedem | bauzas: we don't delete allocations for local delete, | |
| 14:56:11 | mriedem | remember i opened that bug? | |
| 14:56:19 | bauzas | jaypipes: mriedem: okay, so then should we keep the same behaviour ? | |
| 14:56:21 | mriedem | bauzas: and yes, the only place we delete allocations today is the scheduler report client via the RT | |
| 14:56:39 | bauzas | I mean, should we really not be concerned by DELETE allocations in the scheduler claims spec ? | |
| 14:56:59 | bauzas | or we could do that earlier in the compute API worker | |
| 14:57:22 | bauzas | well, only if not soft-deletes, of course | |
| 14:57:31 | mriedem | the fact we don't cleanup allocations during local delete is a bug | |
| 14:57:36 | mriedem | regardless of claims in the scheduler | |
| 14:57:38 | bauzas | mriedem: I vaguely remembered one bug, yup | |
| 14:57:54 | mriedem | bauzas: https://bugs.launchpad.net/nova/+bug/1679750 | |
| 14:57:54 | openstack | Launchpad bug 1679750 in OpenStack Compute (nova) "Allocations are not cleaned up in placement for instance 'local delete' case" [Medium,Confirmed] | |
| 14:58:20 | bauzas | okay, so my question is | |
| 14:58:24 | mriedem | we talked about doing the cleanup in the api service, or leaving it to init_host on the compute, | |
| 14:58:42 | bauzas | should we modify the current behaviour of when we delete allocations, regardless of the above bug ? | |
| 14:58:45 | mriedem | i.e. if the db says we have deleted instances for this host when nova-compute starts up, then go through and attempt to delete their allocation records for that host | |
| 14:59:11 | mriedem | modify how? | |
| 14:59:16 | bauzas | or should we keep the compute service responsible for notifying placement ? | |
| 14:59:29 | bauzas | mriedem: call placement in the compute worker | |
| 14:59:40 | bauzas | mriedem: I mean the api worker | |
| 14:59:55 | bauzas | mriedem: before sending the RPC call to compute | |
| 14:59:56 | mriedem | i thought people wanted to do it in compute | |
| 15:00:06 | mriedem | hold up | |
| 15:00:10 | mriedem | you're conflating two things | |
| 15:00:23 | mriedem | 1. normal delete where we rpc cast to the compute to do the delete | |
| 15:00:34 | bauzas | right, whatever the delete type is | |
| 15:00:38 | mriedem | 2. local delete in the api where the compute service is down, or the instance is shelved offloaded | |
| 15:00:48 | bauzas | yup, I'm not conflating | |
| 15:01:04 | bauzas | I just wonder if we wanted to notify placement earlier than now | |
| 15:01:10 | mriedem | no | |
| 15:01:15 | mriedem | we don't want to tie up the api | |
| 15:01:25 | bauzas | okay, so I'll just wipe out the paragraph I wrote about deletes | |
| 15:01:35 | bauzas | because it's unrelated | |
| 15:01:37 | mriedem | we only do that in the api for local deletes, but there isn't clear agreement on deleting allocations in the api even in the local delete case | |
| 15:01:46 | mriedem | the options are in the bug report above | |
| 15:01:50 | bauzas | I'll just mention the bug as a necessary prereq | |
| 15:02:00 | mriedem | yeah the bug needs to be fixed regardless | |
| 15:02:03 | mriedem | and most likely backported | |
| 15:03:11 | bauzas | okay, thanks for cleaning up the mess in my brain | |
| 15:03:15 | bauzas | I'm all clear | |
| 15:05:19 | bauzas | jaypipes: so, you told me we don't DELETE allocations right now but only when we self-heal ? | |
| 15:05:23 | openstackgerrit | Stephen Finucane proposed openstack/os-vif master: HW offload support for openvswitch https://review.openstack.org/398277 | |
| 15:05:24 | openstackgerrit | Stephen Finucane proposed openstack/os-vif master: Add documentation for Linux Bridge plugin https://review.openstack.org/459291 | |
| 15:05:32 | bauzas | jaypipes: that's something that needs to change then | |
| 15:06:31 | jaypipes | bauzas: no, sorry, I was referring to instances that were terminated but the compute host was down at the time. | |
| 15:06:53 | jaypipes | bauzas: in a "normal" DELETE /servers call, the allocations are indeed deleted. | |
| 15:07:05 | bauzas | okay, looking at code | |
| 15:07:41 | sean-k-mooney | sfinucan: moshele: on the vnic type i dont think this should be documented seperatly per plugin as they are common across all plugins | |
| 15:08:09 | sfinucan | sean-k-mooney: Have you seen the patches themselves | |
| 15:08:31 | sfinucan | They're common, yes, but not all VIF types are supported across all plugins | |
| 15:08:41 | sfinucan | I didn't grasp that nuance until this morning | |
| 15:09:30 | bauzas | jaypipes: mmm, can't find where we call DELETE /allocations in the compute manager, but only in the RT | |
| 15:09:42 | sean-k-mooney | sfinucan: no i havent atleast not lately. correct that is why im working on https://review.openstack.org/#/c/441590/ | |
| 15:10:09 | sean-k-mooney | i am hoping to implement the nova neutron negociation this cycle if i can ever finish the supprot for ovs-dpdk in kolla | |
| 15:10:15 | jaypipes | bauzas: https://github.com/openstack/nova/blob/master/nova/compute/manager.py#L716-L731 | |
| 15:10:38 | jaypipes | bauzas: that's called at the end of the manager's _delete_instance() method. | |
| 15:10:49 | bauzas | ok, seeing it noxw | |
| 15:10:54 | bauzas | we force a RT update | |
| 15:11:00 | bauzas | which will delete the allocation, gotcha | |
| 15:11:02 | jaypipes | bauzas: the _update_resource_tracker() call eventually calls the scheduler client. | |
| 15:11:06 | jaypipes | right. | |
| 15:11:14 | sean-k-mooney | sfinucan: the host_info object discribes what vif types are supported by each plugin and it will with that patch allso describe what port profiles are supporte db each vif_type per plugin | |
| 15:11:27 | bauzas | jaypipes: okay, no explicit allocation delete, RT handles that | |
| 15:11:45 | bauzas | jaypipes: thanks, so nothing needed from a scheduler claims spec perspective | |
| 15:11:51 | bauzas | jaypipes: except the local delete problem | |
| 15:12:01 | sean-k-mooney | sfinucan: this object will be serialsed into the neutron binding profile and read by the mechanisum drivers as part of the port binding call. | |
| 15:12:11 | jaypipes | bauzas: no, that's still called for soft deletes. | |
| 15:12:20 | sfinucan | sean-k-mooney: Nice. I wasn't aware of host_info either | |
| 15:12:23 | bauzas | jaypipes: local delete != soft delete | |
| 15:12:37 | jaypipes | bauzas: no? | |
| 15:12:38 | bauzas | jaypipes: if the RPC compute service is down, we local delete in the api worker | |