| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2017-02-09 | |||
| 20:59:46 | mordred | I ask becuase shade currently does an extra call to /flavors/{id} and fills in with what it can fill in - I'd love to skip the extra call - and would also love to get details for flavors that have changed | |
| 20:59:51 | sdague | There is no /servers/{id}/detail | |
| 21:00:01 | sdague | you mean /servers/detail ? | |
| 21:00:01 | mordred | or /servers/{id} - sorry | |
| 21:00:16 | mordred | either one - the server record | |
| 21:00:16 | sdague | yeh, the same representation is in /servers/{id} and /servers/detail | |
| 21:00:19 | mordred | ++ | |
| 21:00:20 | mordred | yah. that | |
| 21:00:21 | cfriesen | mordred: assuming you mean /servers/detail, the way the help text is written, any field in nova show should be valid for nova list | |
| 21:00:38 | sdague | yeh, those actually share backend code | |
| 21:00:53 | sdague | so we'd have to go out of our way to make them different, and I have no idea why we would do that | |
| 21:01:11 | mriedem | reminds me of image show for glance v1 and v2 | |
| 21:01:17 | mriedem | i.e. the metadata properties in those | |
| 21:01:28 | mriedem | in glance v1, the metadata was in a sub-properties key | |
| 21:01:32 | YmodeMonk | melwitt: Ah, sorry. | |
| 21:01:34 | mriedem | in glance v2 they are all flat right? | |
| 21:01:39 | mriedem | base + custom metadata in the v2 image show | |
| 21:01:59 | sdague | mriedem: yeh, I think that's right | |
| 21:02:17 | mordred | yes. it is | |
| 21:02:27 | mordred | and it's SUPER ANNOYING THE WORST THING EVER | |
| 21:03:01 | sdague | mordred: that it is now flat? | |
| 21:03:04 | mordred | yes | |
| 21:03:15 | mriedem | i think i'd just have server: {"flavor": {"flavorid": <uuid>, "root_gb: 20", "extra_specs": {"hw:watchdog_action": "required"}}} | |
| 21:03:16 | mriedem | something like that | |
| 21:03:25 | mordred | mriedem: ++ | |
| 21:03:30 | sdague | mordred: ok, well if you have ideas on how you'd like the flavor representation on server resource, throw in | |
| 21:03:33 | mordred | that would be lovely | |
| 21:03:34 | mriedem | sdague: how do you not have the glance v2 rest api imprinted in your head by now? :) | |
| 21:04:05 | cfriesen | I assume we could skip stuff like "is_public", "disabled", etc? | |
| 21:04:10 | sdague | mriedem: electroconvulsive therapy? | |
| 21:04:10 | mriedem | mordred: i guess with glance you just use the schema thing to filter which keys are base and which are custom... | |
| 21:04:25 | mriedem | mordred: which also varies by cloud and their backing image schema config... | |
| 21:04:26 | sdague | cfriesen: yeh, I think that was in my spec | |
| 21:04:37 | sdague | there are a set of things which just aren't relevant | |
| 21:04:57 | mriedem | cfriesen: idk honestly | |
| 21:04:58 | mordred | mriedem: yah. I grok the intent. as a user it's terrible | |
| 21:05:12 | mordred | mriedem: as is the cloud being able to have a custom backing image schema config | |
| 21:05:13 | mriedem | mordred: at least they send you the schema | |
| 21:05:32 | mordred | mriedem: yeah. at least | |
| 21:05:35 | mriedem | like, | |
| 21:05:44 | mriedem | at least you still get 1 kidney when you wake up | |
| 21:06:06 | mordred | 'flavor': {u'id': u'5cf64088-893b-46b5-9bb1-ee020277635d'}, | |
| 21:06:20 | sdague | so, schemas are useful for "let me make sure I didn't typo this parameter" | |
| 21:06:30 | mordred | is what it currently looks like over in shade land - with more keys filled in if the flavor still exists and we can fetch it | |
| 21:06:43 | mordred | that's pretty darned similar to what mriedem said a second ago | |
| 21:06:51 | sdague | but they are really dubious for "I have abstractly abtracted my thing in a dsl so you can try to compile it to something useful" | |
| 21:06:57 | cfriesen | mriedem: would we still keep the existing flavor id/link? | |
| 21:07:01 | mordred | sdague: ++ | |
| 21:07:28 | sdague | cfriesen: definitely not the link | |
| 21:07:34 | mriedem | cfriesen: right no link | |
| 21:07:37 | sdague | because that was part of the problem | |
| 21:07:43 | mriedem | since the link was to get you what we're now giving you directly | |
| 21:07:46 | cfriesen | so that would break horizon, right? | |
| 21:07:51 | mriedem | cfriesen: microversions friend | |
| 21:07:55 | cfriesen | ah, right | |
| 21:08:06 | sdague | the id is dubious unless we know that the id referenced hasn't changed | |
| 21:08:28 | mriedem | i did enjoy using the image schema when writing this fix https://github.com/openstack/nova/blob/master/nova/image/glance.py#L638 | |
| 21:08:44 | mriedem | b/c qcow2 wasn't in xen clouds or something | |
| 21:08:49 | cfriesen | okay, I kind of like the idea of a single "flavor" property with a single dict including a nested dict for extra_specs. | |
| 21:09:24 | sdague | I'm more inclined to instead enhance the flavor filters so you could filter by more things | |
| 21:09:31 | sdague | so you could find a compatible flavor in the cloud | |
| 21:09:50 | sdague | because part of the issue is that people are changing or deleting flavors | |
| 21:10:17 | mordred | s/suggest/request/ | |
| 21:10:20 | sdague | mordred: sure | |
| 21:10:28 | cfriesen | I think we could keep the id as a historical data point | |
| 21:10:31 | sdague | but, you do realize it becomes kind of fiction | |
| 21:10:52 | mriedem | i thought we exposed the flavor.id primary key out of the api | |
| 21:10:53 | mordred | I'd be fine with it being None if it's fiction | |
| 21:10:54 | sdague | I'm fine if we document "here was the orginal id, it might be fiction, don't use it" | |
| 21:10:59 | mriedem | but i'm only seeing flavor.flavorid exposed which is the uuid | |
| 21:11:24 | mordred | yah. you expose the flavor id which is the uuid - but it's exposed in server.flavor.id | |
| 21:11:27 | sdague | mordred: well, the issue is, we don't always know it's fiction | |
| 21:11:32 | mordred | sdague: fair | |
| 21:11:46 | cfriesen | mordred: as soon as you boot it could be changed by an admin | |
| 21:12:01 | mordred | sdague: I'll ultimately be fine with any of the things being discussed here - adding flavor details to that dict would be _amaze_ | |
| 21:12:11 | sdague | mordred: the big issue is the uuid kind of never goes on the wire today | |
| 21:12:25 | sdague | so all the identifiers could be recycled | |
| 21:12:43 | sdague | but, we can just doc it as "could be historical fiction, don't trust this field too much" | |
| 21:12:44 | mordred | aroo? I get a uuid? | |
| 21:12:47 | mriedem | i think the flavor_id here is the uuid https://github.com/openstack/nova/blob/master/nova/api/openstack/compute/views/servers.py#L259 | |
| 21:12:49 | cfriesen | sdague: isnt' that the "id" value returned in the current "flavor"? | |
| 21:12:50 | mriedem | not the primary key | |
| 21:12:58 | mordred | 'flavor': {u'id': u'bbcb7eb5-5c8d-498f-9d7e-307c575d3566'}, | |
| 21:12:58 | sdague | mordred: where? | |
| 21:13:03 | sdague | mordred: what cloud | |
| 21:13:06 | mordred | vexxhost | |
| 21:13:16 | mriedem | dansmith: do you remember where the flavor.id primary key is leaked out of the rest api? | |
| 21:13:47 | sdague | mordred: ok, so they chose to make that a uuid | |
| 21:13:57 | sdague | mordred: it's a user settable string | |
| 21:14:03 | mriedem | by default it's a uuid | |
| 21:14:18 | mriedem | https://github.com/openstack/nova/blob/master/nova/compute/flavors.py#L74 | |
| 21:14:19 | mordred | gotcha | |
| 21:14:21 | sdague | http://developer.openstack.org/api-ref/compute/?expanded=list-flavor-access-information-for-given-flavor-detail,list-flavors-detail,create-flavor-detail#create-flavor | |
| 21:14:30 | sdague | mriedem: oh, if they don't pass a thing? | |
| 21:14:33 | cfriesen | I get the same thing in ours (mitaka though) | |
| 21:14:35 | mriedem | sdague: correct | |
| 21:14:39 | sdague | right, but it's not *actually* a uuid | |
| 21:14:45 | mriedem | sure | |
| 21:14:52 | mriedem | it could be "squishy-squat" | |
| 21:14:56 | sdague | like you could delete it and rebuild a new one completely different, same id | |