| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2018-06-25 | |||
| 19:08:42 | openstackgerrit | Matt Riedemann proposed openstack/nova master: Use consumer generation in _heal_allocations_for_instance https://review.openstack.org/577905 | |
| 19:25:42 | openstackgerrit | Matt Riedemann proposed openstack/nova master: Add instance.unlock notification https://review.openstack.org/576703 | |
| 19:27:27 | openstackgerrit | Merged openstack/nova stable/pike: placement: Fix HTTP error generation https://review.openstack.org/571218 | |
| 19:28:43 | openstackgerrit | Eric Fried proposed openstack/nova master: DNM: Testing driver-notes https://review.openstack.org/577908 | |
| 19:29:04 | efried | stephenfin: FYI: ^ | |
| 19:34:24 | openstackgerrit | Matt Riedemann proposed openstack/nova master: Heal allocations with incomplete consumer information https://review.openstack.org/574488 | |
| 19:34:25 | openstackgerrit | Matt Riedemann proposed openstack/nova master: Refactor _heal_instances_in_cell https://review.openstack.org/577896 | |
| 19:34:26 | openstackgerrit | Matt Riedemann proposed openstack/nova master: Use consumer generation in _heal_allocations_for_instance https://review.openstack.org/577905 | |
| 19:51:13 | openstackgerrit | Chris Dent proposed openstack/nova master: [placement] Demonstrate bug in consumer generation handling https://review.openstack.org/577914 | |
| 19:51:14 | openstackgerrit | Chris Dent proposed openstack/nova master: [placement] Fix bug in consumer generation handling https://review.openstack.org/577915 | |
| 20:16:33 | openstackgerrit | Matt Riedemann proposed openstack/nova stable/queens: Use instance project/user when creating RequestSpec during resize reschedule https://review.openstack.org/577918 | |
| 20:17:54 | mriedem | dansmith: i assume there was no cells v2 meeting last week since mel and i were out? did surya talk to you about the handling a down cell stuff at all? | |
| 20:18:11 | dansmith | mriedem: we did, but not in the meeting | |
| 20:18:23 | dansmith | mriedem: I put some details in the spec review | |
| 20:18:30 | mriedem | ok | |
| 20:22:43 | dansmith | mriedem: you reading that now such that I can expect some follow-on discussion here shortly? | |
| 20:22:52 | mriedem | just opened it | |
| 20:23:03 | dansmith | aight | |
| 20:23:11 | mriedem | heh, i did ask for super user / ops input in the ML but got crickets | |
| 20:23:26 | dansmith | ack | |
| 20:23:42 | dansmith | well, in the absence of anything from them, this is the biggest data point we have I think | |
| 20:27:33 | mriedem | "DELETE would "succeed" and never happen, like it does today for lots of things" | |
| 20:27:42 | mriedem | not sure about that - i think we'd get an error looking up the instance to delete | |
| 20:27:57 | dansmith | yeah, I think I waffled about that | |
| 20:28:00 | mriedem | we'd find the instance mapping and then try to pull the instance from the cell and that would 500- | |
| 20:28:03 | dansmith | yeah | |
| 20:28:42 | dansmith | I think he was also hoping that delete would be queued, which it wouldn't, IIRC | |
| 20:33:04 | mriedem | right you'd get a 500 and have to wait until the cell is back up | |
| 20:33:09 | mriedem | or a 503 or something | |
| 20:33:51 | mriedem | the main issues gibi and i had was w/o a new microversion, we'd be returning these shells with a bunch of bogus field data, and a lot of the fields aren't simple strings where we can just say UNKNOWN | |
| 20:34:09 | mriedem | paging and filtering is also a problem in the spec, i think i said we ignore down cells if we're paging and filtering | |
| 20:34:18 | mriedem | *we should | |
| 20:34:35 | mriedem | if i'm following this irc log conversation, it sounds like we're saying: | |
| 20:34:38 | mriedem | 1. new microversion | |
| 20:34:53 | mriedem | 2. if < new microversion and there are down cells, we omit those instances when listing | |
| 20:35:02 | dansmith | mriedem: right | |
| 20:35:10 | dansmith | which is what we do now once her patch merges | |
| 20:35:13 | dansmith | just omit things, | |
| 20:35:21 | mriedem | 3. if >= new microversion, we return what we can, but for missing instances, we don't try to return a full instance, just the uuid and project_id (what we can get from instance_mappings) | |
| 20:35:26 | dansmith | and then the new microversion will be opting into "I've read the contract that says values can be null now" | |
| 20:35:34 | mriedem | oh and status=UNKNOWN | |
| 20:35:42 | dansmith | yes | |
| 20:35:48 | tssurya | are the values going to be NULL, or are the keys going to be totally missing ? | |
| 20:35:53 | dansmith | and maybe "anything we can get from reqspec" | |
| 20:36:01 | dansmith | tssurya: either, missing would be better | |
| 20:36:08 | mriedem | i wouldn't really want to hit reqspec while listing 1000 instances | |
| 20:36:17 | mriedem | GET /servers/{id} hitting reqspec would be ok with me | |
| 20:36:18 | dansmith | mriedem: hence the "and maybe" | |
| 20:36:24 | tssurya | dansmith: ack | |
| 20:36:25 | dansmith | mriedem: he really wanted instance name, as you saw | |
| 20:36:38 | dansmith | mriedem: so we may come across something where it's worth the hit (even though not name, obviously) | |
| 20:36:43 | mriedem | i didn't read the entire irc log | |
| 20:36:51 | tssurya | mriedem: I thought we decided on going with 503 if we do a nova show on a down cell | |
| 20:37:17 | mriedem | i can't remember | |
| 20:37:19 | dansmith | yeah, 50x on show probably makes sense | |
| 20:37:22 | mriedem | also, | |
| 20:37:27 | tssurya | and for a simple start, we should just stick to uuid maybe and status and leave the rest out ? | |
| 20:37:28 | mriedem | the name from the reqspec could be old | |
| 20:37:34 | dansmith | name' | |
| 20:37:37 | mriedem | you can update and rename a server, and that doesn't update the reqspec | |
| 20:37:37 | dansmith | isn't in there | |
| 20:37:48 | tssurya | we don't have info on the name anywhere | |
| 20:38:00 | mriedem | oh yeah | |
| 20:38:00 | mriedem | ok | |
| 20:38:12 | dansmith | mriedem: so you're okay with this it sounds like? | |
| 20:38:22 | dansmith | and gibi seemed okay with it barring a couple more questions | |
| 20:38:29 | mriedem | it's a compromise | |
| 20:38:46 | dansmith | anything is a compromise when we're talking about how to handle missing info :) | |
| 20:38:51 | mriedem | i seem to remember the godaddy guys in boston also wanting name... | |
| 20:39:01 | dansmith | yeah, and I think also IP info :/ | |
| 20:39:04 | dansmith | but one step at a time | |
| 20:39:15 | mriedem | "we want cells v1 but not so shitty" | |
| 20:39:22 | dansmith | heh | |
| 20:39:29 | tssurya | :) | |
| 20:40:53 | mriedem | yeah L42 https://etherpad.openstack.org/p/BOS-forum-using-searchlight-to-list-instances | |
| 20:41:06 | mriedem | this is part of why we had the whole searchlight thing | |
| 20:41:20 | dansmith | let it go. | |
| 20:41:30 | mriedem | oh i did long ago | |
| 20:41:36 | mriedem | just moaning from the grave | |
| 20:41:45 | tssurya | umm, why did we let it go ? | |
| 20:41:48 | tssurya | I mean you* | |
| 20:42:17 | tssurya | meaning if so much work was already put in | |
| 20:42:26 | mriedem | tssurya: see that etherpad | |
| 20:42:35 | openstackgerrit | Matt Riedemann proposed openstack/nova stable/pike: Use instance project/user when creating RequestSpec during resize reschedule https://review.openstack.org/577926 | |
| 20:43:17 | tssurya | got it | |
| 20:43:25 | mriedem | tssurya: it was just complicated | |
| 20:43:44 | mriedem | even though i wrote a masterful spec | |
| 20:44:20 | mriedem | dansmith: tssurya: so i'll try to reply to the ML thread and summarize and you can correct whatever i screw up | |
| 20:44:28 | dansmith | sounds good | |
| 20:44:34 | tssurya | mriedem: cool, thanks | |
| 20:44:35 | mnaser | is there some wild security reason behind why we don't share hostId in metadata? | |
| 20:45:05 | mnaser | in infra we're having issues with a provider and gathering that info would be useful (and i can imagine many other anti affinity scheduling scenarios) | |
| 20:45:45 | mnaser | by anti-affinity, i mean the application running in the vm being able to do anti-affinity by knowing what host it's on | |
| 20:46:23 | mriedem | hostId being the hashed thing from GET /servers/{id}? | |
| 20:46:28 | mnaser | yeah | |
| 20:46:41 | mriedem | likely no one ever asked to add it before | |
| 20:46:41 | mnaser | so it can show up in configdrive | |
| 20:46:46 | mnaser | oh | |
| 20:47:03 | mriedem | you could vendordata it in if you needed, but that wouldn't be standard | |
| 20:47:16 | mnaser | well i figure it'd be useful in general | |