| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2017-04-24 | |||
| 13:57:22 | mriedem | tdurakov: lyarwood: ^ let's see what happens | |
| 14:00:57 | openstackgerrit | Matt Riedemann proposed openstack/nova master: Enable test_iscsi_volume in live migration job https://review.openstack.org/459316 | |
| 14:01:21 | mriedem | kashyap: which version of qemu has native iscsi support? | |
| 14:01:39 | openstack | Launchpad bug 1524898 in OpenStack Compute (nova) "Volume based live migration aborted unexpectedly" [High,Confirmed] | |
| 14:01:39 | mriedem | would be interesting to see if we can test against https://bugs.launchpad.net/nova/+bug/1524898 again | |
| 14:01:40 | kashyap | mriedem: I don't know top off my head, let me look | |
| 14:02:06 | bhagyashris | cdent: Hi, actually I am willing or curious to track the nfs share as a resource provider and manage its inventory with my own tooling as per you suggest me so How can I proceed Can you please give me some guide line or steps to do this? | |
| 14:04:46 | cdent | bhagyashris: I can show you how it is described in the spec, but you'll need some tooling of your own, and the information won't be very useful for two reasons: | |
| 14:05:05 | cdent | nothing will be using the info for scheduling, and nothing will be automatically writing allocations when disk is used | |
| 14:05:33 | kashyap | mriedem: If you're talking about the built-in iSCSI driver, it's there since "eons" -- version 1.0 (as the first commit dates to 2011) -- http://git.qemu.org/?p=qemu.git;a=commitdiff;h=c589b24 | |
| 14:06:00 | cdent | bhagyashris: some of the info here may be useful: http://specs.openstack.org/openstack/nova-specs/specs/newton/implemented/generic-resource-pools.html#scenario-1-shared-disk-storage-used-for-vm-disk-images | |
| 14:06:29 | mriedem | kashyap: it wasn't in the ubuntu package though | |
| 14:06:29 | bhagyashris | cdent:ok. | |
| 14:06:39 | mriedem | kashyap: https://specs.openstack.org/openstack/nova-specs/specs/kilo/implemented/qemu-built-in-iscsi-initiator.html | |
| 14:06:59 | mriedem | looks like it should be there now though http://packages.ubuntu.com/xenial/qemu-block-extra | |
| 14:07:22 | bhagyashris | cdent: yeah I have checked the generic-resource-pool spec long back ago. | |
| 14:07:51 | kashyap | mriedem: What is this 'qemu-block-extra'? | |
| 14:08:01 | kashyap | It's a separate package for Ubuntu? | |
| 14:08:09 | mriedem | yeah | |
| 14:08:10 | mriedem | i guess | |
| 14:08:25 | bhagyashris | cdent: thanks for information | |
| 14:08:36 | mriedem | kashyap: see https://bugs.launchpad.net/nova/+bug/1524898/comments/17 | |
| 14:08:37 | openstack | Launchpad bug 1524898 in OpenStack Compute (nova) "Volume based live migration aborted unexpectedly" [High,Confirmed] | |
| 14:09:19 | mriedem | kashyap: long ago i think danpb said that might not fix that bug, but it might provide better details when it fails if we're using native iscsi | |
| 14:10:00 | openstackgerrit | Sylvain Bauza proposed openstack/nova-specs master: Claims in the scheduler https://review.openstack.org/437424 | |
| 14:10:13 | bauzas | jaypipes: edleafe: cdent: mriedem: dansmith: others ^ | |
| 14:10:22 | cdent | thanks bauzas | |
| 14:10:39 | bauzas | some help would be accepted for the wording :) | |
| 14:11:08 | openstackgerrit | Matt Riedemann proposed openstack/nova master: Enable test_volume_backed_live_migration with block migration https://review.openstack.org/459321 | |
| 14:21:56 | openstackgerrit | Chris Dent proposed openstack/nova master: [WIP] Register osapi_compute when nova-api is wsgi https://review.openstack.org/457283 | |
| 14:26:43 | kashyap | mriedem: Yeah, I recall this bug, and I se you've just enabled the said test given the recent version bumps | |
| 14:27:10 | mriedem | yeah | |
| 14:28:25 | jaypipes | bauzas: done. | |
| 14:29:47 | bauzas | jaypipes: thanks for the wording details, lovely appreciated | |
| 14:30:36 | bauzas | for the fun story, we have a 2nd election round happening when I land in BOS, I have 39% of chances to stay there :p | |
| 14:33:15 | openstackgerrit | jichenjc proposed openstack/nova master: Use plain routes list for limits endpoint instead of stevedore https://review.openstack.org/458805 | |
| 14:33:16 | openstackgerrit | jichenjc proposed openstack/nova master: Use plain routes list for '/servers' endpoint instead of stevedore https://review.openstack.org/445864 | |
| 14:33:16 | openstackgerrit | jichenjc proposed openstack/nova master: Use plain routes list for flavors-access endpoint instead of stevedore https://review.openstack.org/456589 | |
| 14:33:17 | openstackgerrit | jichenjc proposed openstack/nova master: Use plain routes list for hosts endpoint instead of stevedore https://review.openstack.org/459231 | |
| 14:33:17 | openstackgerrit | jichenjc proposed openstack/nova master: Use plain routes list for flavor endpoint instead of stevedore[1] https://review.openstack.org/456549 | |
| 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 | |