| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2018-06-25 | |||
| 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) | |
| 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 | # NOTE(mikal): think of these strings as version numbers. They traditionally | |
| 21:00:37 | mriedem | # correlate with OpenStack release dates, with all the changes for a given | |
| 21:00:37 | mriedem | # release bundled into a single version. Note that versions in the future are | |
| 21:00:37 | mriedem | # hidden from the listing, but can still be requested explicitly, which is | |
| 21:00:37 | mriedem | # required for testing purposes. We know this isn't great, but its inherited | |
| 21:00:37 | mriedem | # from EC2, which this needs to be compatible with. | |
| 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! | |
| 21:02:02 | mriedem | er, project | |
| 21:02:03 | mriedem | repo | |
| 21:02:39 | mriedem | mnaser: just patch it up and send to the ML for discussion i gues | |
| 21:07:03 | cfriesen | the number of hoops metadata jumps through between neutron and nova is nuts | |
| 21:11:36 | mriedem | cfriesen: do you have suggestions for improvements? | |
| 21:18:30 | mriedem | dansmith: http://lists.openstack.org/pipermail/openstack-dev/2018-June/131803.html | |
| 21:20:43 | efried | mriedem: Would you please have a look at https://review.openstack.org/#/c/576877/ -- it's a followon to https://review.openstack.org/#/c/576588/ where mgoddard pointed out an oopsie I made. | |
| 21:21:27 | mriedem | sure | |
| 21:24:39 | openstackgerrit | Mohammed Naser proposed openstack/nova master: Add hostId to metadata service https://review.openstack.org/577933 | |
| 21:27:48 | dansmith | mriedem: looks right to me | |
| 21:29:16 | openstackgerrit | Matt Riedemann proposed openstack/nova master: Make nova list and migration-list ignore down cells https://review.openstack.org/575734 | |
| 21:29:19 | mnaser | mriedem: ^ + http://lists.openstack.org/pipermail/openstack-dev/2018-June/131804.html for/if whenever you want to comment about that | |
| 21:39:15 | openstackgerrit | Mohammed Naser proposed openstack/nova master: Add hostId to metadata service https://review.openstack.org/577933 | |
| 21:42:22 | efried | mnaser: I'll refrain from using the ML for what may be a stupid question, but... | |
| 21:42:57 | mriedem | efried: questions for clarification https://review.openstack.org/#/c/576877/2 | |
| 21:43:03 | efried | mnaser: Might the hostId be omitted from metadata because it could pose a security hole? And/or because it breaks the Principle Of Cloudiness? | |
| 21:43:09 | efried | mriedem: thx, looking... | |
| 21:43:27 | mriedem | efried: hostId is in the GET /servers/{id} rest api already | |
| 21:43:40 | mriedem | https://developer.openstack.org/api-ref/compute/#show-server-details | |
| 21:43:41 | efried | Is that accessible from within the VM, though? | |
| 21:43:50 | mriedem | no, but it's accessible by the tenant | |
| 21:43:57 | efried | so that's the point, innit? | |
| 21:43:58 | mnaser | efried: i mean, we expose the az. hostid is just a more dug-down version of it | |