| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2018-06-25 | |||
| 20:37:48 | tssurya | we don't have info on the name anywhere | |
| 20:38:00 | mriedem | ok | |
| 20:38:00 | mriedem | oh yeah | |
| 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 | mnaser | so it can show up in configdrive | |
| 20:46:41 | mriedem | likely no one ever asked to add it before | |
| 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) | |
| 21:00:00 | mnaser | seem a bit wild | |
| 21:00:02 | mnaser | lol | |
| 21:00:34 | mriedem | note the note from mikal in there | |
| 21:00:37 | mriedem | # from EC2, which this needs to be compatible with. | |
| 21:00:37 | mriedem | # required for testing purposes. We know this isn't great, but its inherited | |
| 21:00:37 | mriedem | # hidden from the listing, but can still be requested explicitly, which is | |
| 21:00:37 | mriedem | # release bundled into a single version. Note that versions in the future are | |
| 21:00:37 | mriedem | # correlate with OpenStack release dates, with all the changes for a given | |
| 21:00:37 | mriedem | # NOTE(mikal): think of these strings as version numbers. They traditionally | |
| 21:00:56 | mriedem | if we go by that, then you'd just add your thing to ROCKY and CD be damned | |
| 21:01:18 | mnaser | technically means no api bump | |
| 21:01:39 | mriedem | yeah, sure, like i said, we aren't real strict or good about the metadata api | |
| 21:01:47 | mriedem | IT SHOULD BE ITS OWN SERVICE! | |