| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2018-07-25 | |||
| 07:25:01 | gmann | let's close then. | |
| 07:25:04 | vishakha | gmann, just wanted you to review https://review.openstack.org/#/c/580271/ | |
| 07:25:05 | Kevin_Zheng | me | |
| 07:25:12 | gmann | Kevin_Zheng: go ahead | |
| 07:25:30 | Kevin_Zheng | Our product team found out a strange API behaviour | |
| 07:25:31 | Kevin_Zheng | https://developer.openstack.org/api-ref/compute/#get-availability-zone-information | |
| 07:25:36 | gmann | vishakha: sure, ll add in my list | |
| 07:25:41 | Kevin_Zheng | there is a hosts field | |
| 07:25:55 | Kevin_Zheng | and it will always be "null" | |
| 07:26:02 | Kevin_Zheng | it was just added here: | |
| 07:26:14 | Kevin_Zheng | https://github.com/openstack/nova/blob/master/nova/api/openstack/compute/availability_zone.py#L42 | |
| 07:26:26 | Kevin_Zheng | so any particular reason why it is added? | |
| 07:26:34 | Kevin_Zheng | Or should we just remove it | |
| 07:27:53 | gmann | Kevin_Zheng: may be for consistency for GET and GET detail API | |
| 07:28:05 | gmann | Kevin_Zheng: Detail give the host information | |
| 07:28:09 | vishakha | gmann, Thanks :) | |
| 07:28:19 | Kevin_Zheng | but do we need this kind of consistency? | |
| 07:28:23 | Kevin_Zheng | looks strange | |
| 07:28:33 | gmann | #link https://github.com/openstack/nova/blob/master/nova/api/openstack/compute/availability_zone.py#L91 | |
| 07:28:42 | Kevin_Zheng | we do not have this kind of consistency in list server and list server details | |
| 07:29:17 | Kevin_Zheng | yeah, I know that, just think this is not necessary | |
| 07:29:22 | gmann | ohk it is not get particular AZ | |
| 07:29:49 | gmann | we can remove but need microversion. what harm in keeping it ? | |
| 07:30:15 | Kevin_Zheng | no harm, just found it strange | |
| 07:30:21 | Kevin_Zheng | and the customer asks | |
| 07:30:37 | Kevin_Zheng | so we have to tell them why it is like that all the time | |
| 07:30:48 | gmann | i remember we kept it for v2.1 for compatibility | |
| 07:31:12 | Kevin_Zheng | So might be good to remove it in S? | |
| 07:31:18 | Kevin_Zheng | with microversion | |
| 07:32:01 | gmann | Kevin_Zheng: ok. i can note down this on API improvement etherpad (which i need to create yet)and then we can decide if we can fix this with other consistent changes | |
| 07:32:15 | Kevin_Zheng | yeah cool | |
| 07:32:26 | gmann | microversion alone for this seems little overhead for me | |
| 07:32:39 | Kevin_Zheng | yeah | |
| 07:33:04 | gmann | Kevin_Zheng: thanks for finding and reporting this. | |
| 07:33:29 | Kevin_Zheng | NP, just solving our problems | |
| 07:33:44 | gmann | anything else to discuss | |
| 07:34:29 | gmann | ok let's close then | |
| 07:34:35 | gmann | thanks everyone for joining | |
| 07:34:39 | gmann | #endmeeting | |
| 07:34:40 | openstackgerrit | Lucian Petrut proposed openstack/nova master: Hyper-V + OVS: plug vifs before starting VMs https://review.openstack.org/585661 | |
| 07:34:42 | openstack | Meeting ended Wed Jul 25 07:34:39 2018 UTC. Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4) | |
| 07:34:43 | openstack | Minutes: http://eavesdrop.openstack.org/meetings/nova_api/2018/nova_api.2018-07-25-06.02.html | |
| 07:34:44 | openstack | Minutes (text): http://eavesdrop.openstack.org/meetings/nova_api/2018/nova_api.2018-07-25-06.02.txt | |
| 07:34:45 | openstack | Log: http://eavesdrop.openstack.org/meetings/nova_api/2018/nova_api.2018-07-25-06.02.log.html | |
| 07:34:50 | Kevin_Zheng | gmann a test related question | |
| 07:34:59 | gmann | Kevin_Zheng: yup | |
| 07:35:12 | Kevin_Zheng | https://review.openstack.org/#/c/583927/ I'm working on this | |
| 07:35:39 | Kevin_Zheng | and Matt asked me to use a real mc backend instead of mock | |
| 07:36:01 | Kevin_Zheng | Seems like it need to have some set_up besides just override the configs | |
| 07:36:20 | gmann | checking | |
| 07:36:22 | Kevin_Zheng | I have no clue how do it, do you have this kind of experience/ | |
| 07:36:24 | Kevin_Zheng | ? | |
| 07:36:34 | Kevin_Zheng | Thanks | |
| 07:39:17 | gmann | i have not done yet but trying to look | |
| 07:41:20 | gmann | Kevin_Zheng: it did not work with dogpile.cache.memory also ? | |
| 07:41:50 | gibi | mriedem: No worries, I didn't planned to have a meeting this week (either) http://lists.openstack.org/pipermail/openstack-dev/2018-July/132410.html | |
| 07:42:13 | Kevin_Zheng | yeah, seems the backend is not working, the client can be correctly initialized, but no data was saved | |
| 07:42:25 | Kevin_Zheng | so cannot retrive any data | |
| 07:50:37 | openstackgerrit | Lucian Petrut proposed openstack/nova master: Hyper-V + OVS: plug vifs before starting VMs https://review.openstack.org/585661 | |
| 07:53:01 | gmann | Kevin_Zheng: i was thinking expiration_time is missing but is defaulted here - https://github.com/openstack/nova/blob/ddc807f85aad4e3d2ed6434809325320c1c21281/nova/cache_utils.py#L69 | |
| 07:53:36 | Kevin_Zheng | hmm, yeah | |
| 07:54:08 | Kevin_Zheng | so you don't think we should do any setup action? | |
| 07:55:06 | gmann | Kevin_Zheng: means? | |
| 07:55:24 | Kevin_Zheng | I mean, do we need to setup the backend? | |
| 07:55:52 | gmann | Kevin_Zheng: i do not think so | |
| 07:56:01 | Kevin_Zheng | hmm ok | |
| 07:56:17 | Kevin_Zheng | Then I should check more on the params | |
| 07:56:22 | gmann | let me dig into that. need to go for firstcontact SIG now. | |
| 07:56:32 | Kevin_Zheng | NP, thanks anyway | |
| 07:56:36 | gmann | ll check later and let you know | |
| 07:56:53 | Kevin_Zheng | thanks | |
| 08:09:28 | openstackgerrit | Tetsuro Nakamura proposed openstack/nova master: WIP: Enable nested allocation candidates in scheduler https://review.openstack.org/585672 | |
| 08:15:14 | tetsuro | ^gibi, jaypipes, efried and everyone: I'd like to help you on consuming nrp-aloc-cands work in nova side, but I think I need brief feedback if this is a right way and where I should go. | |
| 08:17:21 | tetsuro | This is at least working on getting candidates with child rp + custom resource class inventory and have allocations on them with compute host resources. | |
| 08:17:37 | tetsuro | ...with a new instance | |
| 08:28:36 | cdent | tetsuro: I looked at that, looks like a good start and the right thing for there. The complexity is going to happen if/when an instance with nested wants to do a migration. There's quite a bit of a TODO in the report client about that kind of thing. | |
| 08:29:27 | gmann | tetsuro: we were discussing about your BP in api office hour - https://review.openstack.org/#/q/topic:bp/handling-down-cell+(status:open+OR+status:merged) | |
| 08:30:09 | gmann | tetsuro: what's the plan for this? is it still target for Rocky or stein. i saw the comment of doing service list also along with server list | |
| 08:30:31 | gibi | tetsuro: left some feedback in that patch. I think simply reading the consumer generation from placement during the claim_resources is defeate the purpose of having consumer generations | |
| 08:30:57 | gibi | tetsuro: I'm trying to add support for consumer generations here https://review.openstack.org/#/c/583667/ | |
| 08:31:19 | cdent | tetsuro, gibi: for the case where we have a new instance the consumer is new, so generation is meaningless? | |
| 08:31:38 | gibi | cdent: unfortunately that is not the only case when claim_resources are called | |
| 08:32:00 | cdent | yeah, I know, I'm trying to work out if we can streamline the easy path | |
| 08:32:07 | cdent | because it is the common path too | |
| 08:32:41 | cdent | in the uncommon cases there will be existing allocations, yes? | |
| 08:32:58 | cdent | thus what the code is doing is at least close, if not fully correct | |
| 08:33:18 | gibi | cdent: plus when we assume that it is a new consumer we can still need to prepare that we get consumer generation conflict and handle that (most probably fail the build) | |
| 08:33:45 | cdent | clearly there needs to be some conflict detection, but bar that the logic is mostly right unless there's a detail I'm not aware of (which is very likely) | |
| 08:34:22 | cdent | yes, a generation conflict on a new build would mean that UUIDs are broken :) | |
| 08:34:49 | gibi | cdent: or that our assumption in the claim_resources about the fact that it is a new build is invalid | |
| 08:36:11 | gibi | cdent: even if we are coming from the scheduer select_destination it is possible that the consumer exists as evacuate does not use migration.uuid to hold the allocation of the source host | |
| 08:36:47 | openstackgerrit | Lee Yarwood proposed openstack/nova master: libvirt: Do not reraise DiskNotFound exceptions during resize https://review.openstack.org/571410 | |
| 08:37:17 | gibi | cdent: I agree that assuming consumer_generation = None in claim_resource a good first step | |
| 08:38:13 | gibi | cdent: I just fustrated about the hairy cases that I have to takle in my patch and I don't think we can merge support for 1.29 before solving 1.28 for the edge cases too | |
| 08:38:41 | lyarwood | mdbooth: ^ would you mind taking a look at that again? | |
| 08:38:48 | cdent | I'm not disputing that we need to merge (and understand) your 1.28 code first | |
| 08:39:18 | cdent | just, as I said, trying to make sure that we don't overcomplicate things when we claim, if possible | |
| 08:39:28 | mdbooth | lyarwood: yup | |
| 08:39:51 | cdent | if new: gen is none, if gen conflict bail, something went badly wrong | |
| 08:40:44 | gibi | cdent: when you say 'if new' do you mean checking if there is no other allocation in placement for the consumer? | |