| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2018-06-25 | |||
| 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 | |
| 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 | |
| 21:50:32 | efried | mriedem: responded on https://review.openstack.org/#/c/576877/ | |
| 21:52:26 | openstackgerrit | Merged openstack/nova master: Add instance.lock notification https://review.openstack.org/576702 | |
| 21:52:42 | mriedem | efried: ok +W | |
| 21:53:27 | efried | mriedem: tbc, prior to the preceding patch where I f'ed up, ironic was "broken" in that they would strip out any traits set outside of ironic. Then I broke it differently (and arguably worse) by the preceding patch to where we would only ever *add* traits, never take them away. This is restoring the previous less-broken behavior. Eventually we will (probably) unbreak this by making logic that only adds+removes traits the | |
| 21:53:29 | efried | mriedem: Thanks. | |
| 21:54:03 | mriedem | yup | |
| 21:54:14 | mriedem | following the update_traits mention in the RT from the commit message clarified that for me | |
| 21:54:27 | efried | cool | |
| 21:56:20 | cfriesen | mriedem: RE: the metadata thing...not sure of a way to simplify it while still letting it work like it does now. For newish libvirt something like virtio-vsock would be simpler. | |
| 21:56:37 | cfriesen | But it'd require guest support | |
| 21:57:18 | mriedem | cfriesen: pretty sure dansmith and artom have talked about that a few times | |
| 21:57:31 | mriedem | also, note that libvirt isn't our only virt driver... | |
| 21:57:39 | cfriesen | yeah, I know. :) | |
| 22:00:10 | openstackgerrit | Takashi NATSUME proposed openstack/nova master: Remove mox in unit/network/test_neutronv2.py (1) https://review.openstack.org/572018 | |
| 22:00:35 | openstackgerrit | Takashi NATSUME proposed openstack/nova master: Remove mox in unit/network/test_neutronv2.py (2) https://review.openstack.org/573481 | |
| 22:01:49 | mriedem | efried: replied in https://review.openstack.org/#/c/577905/ | |
| 22:01:55 | efried | ... | |