| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2017-04-11 | |||
| 14:43:10 | mriedem | sorry, GET /servers/{server_id}/os-interface | |
| 14:43:47 | jaypipes | mriedem: is the choice here about whether to reduce os-interface/ to just a list of port_ids or to have it repeat some/all of the informatio nin the instance_info cache? | |
| 14:44:16 | sdague | or.... delete os-interface entirely | |
| 14:44:22 | sdague | and put port_id in addresses | |
| 14:44:26 | jaypipes | sdague: ++ | |
| 14:44:33 | alex_xu | sdague: +1 | |
| 14:44:41 | mriedem | where are you going to move the POST and DELETE methods? | |
| 14:44:49 | alex_xu | move to action? | |
| 14:44:54 | alex_xu | our ugly action | |
| 14:44:59 | sdague | well... | |
| 14:45:46 | mriedem | and eventually when we want to expose vif tags, those are in 'addresses' as well? | |
| 14:46:10 | mordred | sdague: ++ | |
| 14:46:29 | sdague | mriedem: yeh, probably, they are honestly more useful than a lot of things we have in the server doc | |
| 14:46:40 | jaypipes | mriedem: Neutron ports can be tagged in the port binding details. | |
| 14:46:45 | openstackgerrit | Rodolfo Alonso Hernandez proposed openstack/nova master: Read NIC features in libvirt https://review.openstack.org/444415 | |
| 14:46:54 | mriedem | jaypipes: we don't use those tags | |
| 14:47:03 | mriedem | jaypipes: not for the 2.32 microversion anyway | |
| 14:47:07 | jaypipes | mriedem: yeah, unfortunately. now we have two places to look for them :( | |
| 14:48:31 | alex_xu | jaypipes: do you mean there is a copy in port binding detail for tag? or the tag in port binding detail is separated thing than nova's one | |
| 14:48:35 | mriedem | and binding:profile in the port is completely free form, | |
| 14:48:49 | mriedem | and a wild west of what could or might not be in there depending on version and backend of the neutron you're talking to | |
| 14:48:54 | mriedem | so that's also a ton of fun | |
| 14:50:38 | mordred | mriedem: because I don't follow everything y'all do - "when we want to expose vif tags" - can you point me to something where I can learn what vif tags are and what I might use them for? | |
| 14:50:53 | jaypipes | alex_xu: what mriedem said. but I will add that *Neutron* is the owner of all information about a port, so regardless of what we think about Neutron's API, it is what is the canonical source of truth for things like os-vif. | |
| 14:51:04 | mordred | ++ | |
| 14:51:09 | jaypipes | mordred: it's NFV fun. | |
| 14:51:14 | mriedem | mordred: https://docs.openstack.org/developer/nova/api_microversion_history.html#id29 | |
| 14:51:15 | mordred | jaypipes: ah. so I do not care aboutthem :) | |
| 14:51:27 | jaypipes | mordred: well, you should. | |
| 14:51:50 | mordred | jaypipes: yah. I was being snarky | |
| 14:52:01 | mordred | those seem potentially cool | |
| 14:52:30 | sdague | mriedem / jaypipes so... I guess the one question I still have, which jaypipes and I are cycling on is there is some delay between "attach" and it being attached | |
| 14:52:32 | mriedem | mordred: one example for a bdm tag i think is that, you know how we return a device_name for bdms attached to a server? and that's a total lie? people could think they can correlate that mountpoint in their guest to what the api says volume x is attached to, but that could be totally wrong | |
| 14:52:39 | sdague | and what are we indicating in that interim | |
| 14:52:47 | sdague | especially if there is no port_status | |
| 14:52:52 | mriedem | i believe the bdm tag can actually be used to correlate within the guest a given volume attached to the server | |
| 14:54:07 | mordred | mriedem: that would be neat | |
| 14:54:19 | jaypipes | sdague: well, the user could easily poll on GET /ports/{port_id} for the attachment state. | |
| 14:54:39 | sdague | jaypipes: yeh, that's probably reasonable | |
| 14:54:43 | mriedem | sdague: i think ^ is what tempest does | |
| 14:54:52 | mriedem | i added the code to do it i think, will look | |
| 14:54:57 | sdague | so it only shows up in servers once it's really there | |
| 14:55:02 | mriedem | mordred: we already do that | |
| 14:55:06 | sdague | mordred: you can add ports later too | |
| 14:55:09 | mriedem | we wait for the vif plug callback from neutron | |
| 14:55:28 | jaypipes | mordred: we're talking about the live attach/detach of a port. | |
| 14:55:34 | mordred | sdague: yes - post-create port attach I think polling the port in neutron for attach state is right - or port not showing up on server until it's attache | |
| 14:55:36 | mordred | either way | |
| 14:56:03 | mriedem | sdague: https://github.com/openstack/tempest/blob/master/tempest/api/compute/servers/test_attach_interfaces.py#L100 | |
| 14:56:21 | mriedem | sdague: https://github.com/openstack/tempest/blob/master/tempest/common/waiters.py#L264 | |
| 14:56:39 | mriedem | so tempest totally relies on the port_state in the os-interface response to see when the port is ACTIVE | |
| 14:56:42 | mriedem | and the attach is done | |
| 14:57:00 | sdague | mriedem: ok, sure | |
| 14:57:09 | sdague | so, you down at the bottom of the etherpad | |
| 14:57:28 | sdague | I think we could get that whole thing with the ports sub resource that jay proposed | |
| 14:57:52 | mordred | mriedem: maybe it's time to switch tempest to poll neutron port state instead? | |
| 14:58:29 | mriedem | mordred: i'm not saying that can't be change | |
| 14:58:38 | mriedem | the test doesn't even run if you're using nova-net https://github.com/openstack/tempest/blob/master/tempest/api/compute/servers/test_attach_interfaces.py#L35 | |
| 14:59:04 | mordred | mriedem: awesome. so it's only a neutron test anyway :) | |
| 14:59:09 | sdague | mriedem: sure, but also realize this isn't contract code, it's the incidental code | |
| 14:59:19 | mriedem | mordred: os-interface GET ONLY works for neutron | |
| 14:59:24 | mriedem | it's a NotImplementedError for nova-net | |
| 14:59:28 | sdague | yeh | |
| 14:59:35 | mriedem | and os-virtual-interfaces ONLY works for nova-net, and is a NotImplementedError for neutron | |
| 14:59:37 | mordred | mriedem: I don't know that I even knew os-interface existed | |
| 14:59:40 | mriedem | hence me wanting to collapse these | |
| 15:00:09 | sdague | mriedem: anyway, on your level of rage, what about the add ports to server document, provide this new minimalist interface for the port attach/detach/attaching status | |
| 15:00:15 | jaypipes | mriedem, sdague: sounds like we are converging on something here.. | |
| 15:00:39 | johnthetubaguy | I always wish the volume attachments and network attachments kinda look/feel similar in the API, not sure I like either right now though | |
| 15:00:47 | mordred | as I say that ... | |
| 15:00:57 | mriedem | johnthetubaguy: i was trying to get them closer, this gets them much further apart | |
| 15:00:58 | mordred | https://developer.openstack.org/api-ref/compute/?expanded=list-port-interfaces-detail is pretty | |
| 15:01:44 | mriedem | sdague: honestly it's a lot more than i was planning to do for this | |
| 15:01:44 | sdague | mordred: you just said that did you no good :P | |
| 15:01:51 | johnthetubaguy | mriedem: would we likely take everything there eventually? | |
| 15:01:52 | sdague | mordred: litterally, that's where we started | |
| 15:01:58 | mriedem | sdague: and if it comes to that, i'm basically going to punt for pike | |
| 15:02:14 | mriedem | and just deprecate os-virtual-interfaces as the easy thing we have to do anyway, we could lump that in with deprecating multinic | |
| 15:02:21 | sdague | mriedem: that's fine | |
| 15:02:24 | mriedem | johnthetubaguy: who knwos | |
| 15:02:31 | mriedem | johnthetubaguy: maybe eventually we do similar for bdms | |
| 15:02:37 | mordred | sdague: well, yah - it doesn't - because it's an extra call - I'm just saying it _is_ nice looking, so whoever wrote it didn't do a bad job or anything | |
| 15:02:40 | mriedem | GET /servers/{server_id}/volumes | |
| 15:03:04 | mriedem | johnthetubaguy: but in 2 years time when we talk about doing that, we'll have either all moved on or likely changed our minds and come to some other conclusion | |
| 15:03:12 | johnthetubaguy | mriedem: it feels like when they seems similar, we are closer to where we want to be | |
| 15:03:21 | mordred | sdague: if the addresses dict was instead list of those, that might be nice | |
| 15:03:22 | johnthetubaguy | +1 for deprecating the broken bits | |
| 15:03:36 | mordred | although I'd have to go poke for a minute to see how much code I could delete if it was | |
| 15:03:43 | sdague | ok, so I think that's where we stand, just deprecate the broken thing | |
| 15:03:45 | mriedem | how about microversion 2.43: completely rewrite the entire gd compute api? | |
| 15:03:55 | cdent | mriedem++ | |
| 15:04:01 | alex_xu | :) | |
| 15:04:27 | mriedem | because what i always think is an incremental step forward turns into a giant rewrite | |
| 15:05:07 | sdague | mriedem: yeh, they do have the natural tendancy to grow | |
| 15:05:17 | sdague | anyway, I think deprecate in a mv is fine | |
| 15:05:22 | sdague | that's a small change | |
| 15:06:19 | mriedem | alex_xu: if we just deprecate os-virtual-interfaces, i think we should combine that in the same microversion as deprecating multinic | |
| 15:06:27 | mriedem | so we don't have 20 separate microversions for just deprecating APIs | |
| 15:06:30 | alex_xu | mriedem: i'm ok with that | |
| 15:06:31 | mriedem | because that gets super annoying | |