| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2017-02-09 | |||
| 20:43:03 | mordred | sdague: the payload has differnet top level keys if it's from versioned or unversioned endpoint, and then some of the weirder clouds have different subkeys | |
| 20:43:17 | sdague | mordred: sigh :) | |
| 20:44:47 | mordred | sdague: so you can have dict(version={}), dict(versions=dict(values=[])), dict(versions=dict(version=[])) and dict(version=[]) - and in at least one case a thing with both values and version in the second level | |
| 20:45:22 | mordred | sorry, that last one should be dict(versions=[]) | |
| 20:45:38 | mordred | sdague: yah. it's the hole I fell down today | |
| 20:47:46 | cfriesen | sdague: if we were to add flavor info to "nova show", how would you suggest formatting it? Add a dict to the existing "flavor" line? Or add a new property for the flavor dict? | |
| 20:49:59 | openstackgerrit | Diana Clarke proposed openstack/nova master: Fix nova-manage cell_v2 metavar strings https://review.openstack.org/431714 | |
| 20:50:30 | sdague | cfriesen: well, for the basic attributes, I would put the keys directly inline I think. memory_mb, disk_gb, and the like | |
| 20:52:02 | sdague | for extra specs, I guess that would need a dedicated dict. I don't think we really pondered that here | |
| 20:52:27 | cfriesen | sdague: just include them as instance properties? what about extra_specs? call it "flavor_extra_specs" and put it inline? And what about odd ones like "rxtx_factor" | |
| 20:52:59 | sdague | cfriesen: honestly, this is basically where the whole debate is, what the representation looks like. | |
| 20:53:27 | sdague | honestly, if you want to get the ball rolling I would sketch out what the responses and flow would look like for a couple of different options | |
| 20:53:35 | YmodeMonk | In the [api_database] it still suggests that the connection = none ? | |
| 20:53:37 | sdague | fully inline, linked resource | |
| 20:53:57 | sdague | And get the vote on what's least gross :) | |
| 20:54:00 | cfriesen | sdague: ah, okay. well maybe I'll put something up for discussion. | |
| 20:54:41 | sdague | because I think that's where things broke down, there is not *great* answer that doesn't feel dirty in someway, but the status quo isn't really an option either, so it's going to have to be go with least worse I think | |
| 20:55:26 | YmodeMonk | can anyone tell me how to import the novaapidb schema? Seems the debconf fails and doesn't import it :-/ | |
| 20:55:32 | cfriesen | sdague: how could you do linked resource given that the resource doesn't necessarily exist anymore? (we allow modifying extra-specs) | |
| 20:56:18 | melwitt | YmodeMonk: please see the channel topic. this is a nova dev channel | |
| 20:56:24 | sdague | that's the /servers/{id}/flavor approach | |
| 20:56:31 | sdague | so it would be a dedicated sub resource | |
| 20:56:38 | sdague | and the flavor link would go there | |
| 20:57:24 | cfriesen | sdague: ah, I see what you mean. I think it makes more sense in the "nova show" output. | |
| 20:57:57 | sdague | cfriesen: yeh, my lean is in the servers resource itself at this point, as this seems at least as relevant as many of the attributes currently there | |
| 20:58:31 | mordred | sdague, cfriesen: are you only discussing the nova show output? or also putting more details about flavor into /servers/{id}/detail response? | |
| 20:58:57 | sdague | mordred: that's a good question | |
| 20:59:36 | sdague | mordred: wait, actually I'm confused by the question | |
| 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 | mordred | or /servers/{id} - sorry | |
| 21:00:01 | sdague | you mean /servers/detail ? | |
| 21:00:16 | sdague | yeh, the same representation is in /servers/{id} and /servers/detail | |
| 21:00:16 | mordred | either one - the server record | |
| 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 | mriedem | mordred: i guess with glance you just use the schema thing to filter which keys are base and which are custom... | |
| 21:04:10 | sdague | mriedem: electroconvulsive therapy? | |
| 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 | |