| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2018-06-25 | |||
| 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! | |
| 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 | |
| 21:44:15 | mriedem | "An ID string representing the host. This is a hashed value so will not actually look like a hostname, and is hashed with data from the project_id, so the same physical host as seen by two different project_ids, will be different. It is useful when within the same project you need to determine if two instances are on the same or different physical hosts for the purposes of availability or performance." | |
| 21:44:34 | mnaser | yeah and because it's hashed, nothing to worry about in terms of exposing anything | |
| 21:44:36 | efried | Oh, yeah, it's obfuscate... | |
| 21:44:38 | efried | d | |
| 21:44:46 | mriedem | efried: i could create my server, then get the hostId from the compute rest api, post that into the servers user metadata, and then get it into the guest via the metadata api | |
| 21:44:56 | mriedem | so this is all possible today, just in an annoying roundabout way | |
| 21:45:19 | efried | mriedem: Right, but that would again be a thing you would have to do from outside. Rather than it being always available from within the VM without any choice in the matter. | |
| 21:45:27 | efried | like a conf option to say whether to expose it or not. | |
| 21:45:33 | mnaser | well, vms also have access to the instance type they are, the az they sit in | |
| 21:45:53 | efried | I really have no skin in this game, just blabbing a thing that came to mind when I saw this. | |
| 21:46:34 | mnaser | oh yeah i totally thought about that, but i just don't see too much of an issue | |