| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2018-06-25 | |||
| 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 | |
| 20:47:36 | mnaser | why throw stuff in vendor data if it has a general usefulness :x | |
| 20:47:45 | mriedem | yeah i know | |
| 20:48:04 | mriedem | if it's in the compute rest api i'm not sure of any reason it shouldn't be in metadata api if it's useful to the guest | |
| 20:48:21 | mriedem | we throw the az in there for example | |
| 20:49:00 | mnaser | well i'll push up a patch and because it seems simple enough and we can discuss there | |
| 20:49:02 | mnaser | (famous last words) | |
| 20:49:16 | mriedem | well, it's technically an api change | |
| 20:49:25 | mriedem | it would require a version bump to the metadata api | |
| 20:49:53 | mnaser | is there some document for me to review about this | |
| 20:50:06 | openstackgerrit | Matt Riedemann proposed openstack/nova stable/ocata: Use instance project/user when creating RequestSpec during resize reschedule https://review.openstack.org/577929 | |
| 20:50:08 | mriedem | SURE IS | |
| 20:50:16 | mriedem | mnaser: https://docs.openstack.org/nova/latest/contributor/blueprints.html | |
| 20:50:25 | mnaser | oh god i was hoping i'd avoid that but ok | |
| 20:50:47 | mriedem | you'd have to talk to the boss about getting a spec freeze exception | |
| 20:51:19 | mnaser | "API changes always require a design discussion." | |
| 20:51:20 | mnaser | o | |
| 20:51:37 | mriedem | which for something coming up post-spec freeze when we have other specs that didn't make the cut, would be kind of a d*ck move if we gave this an exception for rocky | |
| 20:51:55 | mnaser | nah, i wouldn't want to jump the line | |
| 20:52:04 | mriedem | even though it's like a 4 line change... | |
| 20:52:18 | mriedem | idk, it's worth bringing up i guess | |
| 20:52:44 | mnaser | let me check if it really will be a 4 line change | |
| 20:52:45 | mriedem | i don't have a big problem with making exceptions for trivial and clearly useful things | |
| 20:52:54 | mriedem | it's basically: | |
| 20:53:06 | mriedem | ROCKY_META_HOSTID = 'new date' | |
| 20:53:27 | mriedem | if version >= ROCKY_META_HOSTID: metadata['hostId'] = hashed hostid | |
| 20:53:41 | mriedem | plus a test | |
| 20:53:48 | mnaser | yeah that's what i figured it would be | |
| 20:54:39 | mnaser | i guess i'll write the simple patch and bring it up in the meeting or on ML, if people aren't opposed, i'll go through writing the spec | |
| 20:54:49 | mnaser | mainly because the time taken writing the spec is literally more than the 4 lines involved | |
| 20:55:27 | mnaser | oh | |
| 20:55:31 | mnaser | and there was already an api bump in rocky | |
| 20:55:42 | mriedem | this would be a delta | |
| 20:55:52 | mriedem | see NEWTON_ONE and NEWTON_TWO | |
| 20:55:57 | mnaser | oh | |
| 20:55:58 | mnaser | gotcha | |
| 20:56:10 | mriedem | like, we're not great about versioning the metadata api, or testing it, or documenting it, like the compute rest api, | |
| 20:56:16 | mriedem | but we still have *some* standards | |
| 20:56:44 | mnaser | um | |
| 20:56:47 | mnaser | the date for rocky is the openstack release date | |
| 20:56:54 | mnaser | so what would ROCKY_TWO be lol | |
| 20:57:05 | mriedem | gdi | |
| 20:57:29 | mnaser | :( | |
| 20:57:39 | mriedem | https://www.youtube.com/watch?v=FZ9d7SWF7Z0 | |
| 20:57:46 | mnaser | it looks like it is 1 bump per release rather than per change in metadata | |
| 20:58:29 | mnaser | lols | |
| 20:59:05 | mriedem | so NEWTON_ONE must have been the one that didn't follow the release date, | |
| 20:59:07 | mriedem | but the others do yeah https://releases.openstack.org/ | |
| 20:59:44 | mriedem | idk, if we stuck to our CD guns we'd require at least a delta, like 1 day after ROCKY(_ONE) | |