| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2018-07-25 | |||
| 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? | |
| 08:41:02 | cdent | if existing allocations for this consumer uuid, do something else | |
| 08:41:27 | cdent | that would be one way, but I assume the caller of claim also knows? | |
| 08:42:32 | cdent | the "something else" looks to me to be very close to what is already being done in the code: merge the allocations, set the generation to what the server told us | |
| 08:42:36 | gibi | cdent: what if the caller thinks that it is not a new consumer but the claim_resources checks in placement and sees it is a new consumer and silently uses consumer_generation None instead of raise? | |
| 08:43:36 | gibi | cdent: I think in this case the caller needs to provider his view of the consumer generation and not let claim_resource decide | |
| 08:43:36 | cdent | then we should fix the caller because it sounds like the caller is broken? I'm not sure why we should overcomplicate the report client to deal with the fact that other code is flakey. What situation would cause what you're describing? | |
| 08:45:16 | gibi | cdent: sure it needs fix on the caller side but to know that the caller is broken we need to see the conflict and not simply use the consumer gen that will succeed in placement by asking it from placement | |
| 08:45:47 | cdent | I don't mean a fix at runtime, I mean a fix in the code | |
| 08:46:04 | cdent | Thus my question of "what situation.." | |
| 08:47:04 | gibi | cdent: I don't know exactly the case. I guess some parallel consumer update can happen. This is why we introduced consumer generation in the first place, isn't it? | |