| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2017-04-11 | |||
| 14:35:05 | jaypipes | mordred: you mean a list of port_ids I assume? | |
| 14:35:17 | mordred | I want a port id with every ip address in addresses | |
| 14:35:18 | sdague | mordred: ok, we weren't talking about serviers | |
| 14:35:34 | mriedem | mordred: right which gets us into fixed the addresses monster | |
| 14:35:39 | mordred | (although I really want a new thing that isn't addresses, but I'd take just adding a port_id to addresses) | |
| 14:35:41 | mriedem | which we weren't getting into for this spec | |
| 14:35:44 | mordred | gotcha | |
| 14:35:51 | mordred | so - for me, /interfaces is not useful at all | |
| 14:35:59 | mordred | because I've got neutron if I want to query that info | |
| 14:36:11 | jaypipes | mordred: EXACTLY. | |
| 14:36:17 | mordred | I want to know how to contact my server without an additional roundtrip | |
| 14:36:34 | jaypipes | mordred: why are we even trying to return any of this other than a list of port_ids (or even hyperlinks to a Neutron URL). | |
| 14:36:42 | mordred | and the server record as it is today is not sufficient for that | |
| 14:36:57 | mordred | jaypipes: don't return hyperlinks, they're gross | |
| 14:37:06 | mriedem | so GET /ports/?device_id=<server uuid> is preferred? | |
| 14:37:15 | mordred | mriedem: that's what I have to do today | |
| 14:37:33 | mordred | so - let me give a specific use case, that might help | |
| 14:37:37 | jaypipes | mordred: please. | |
| 14:37:52 | mordred | I boot a server and I now want to attach a new floating ip | |
| 14:38:08 | mordred | in order to do that, I need the port id of the fixed ip on the server so that I can pass it to the neutron create_floating_ip call | |
| 14:38:21 | mordred | but in order to be able to do that, Ineed to call GET /ports/?device_id=<server uuid> | |
| 14:38:32 | mordred | so I can find the port id | |
| 14:38:45 | mordred | so it's "boot sever, list ports, create fip" - instead of "boot server, create fip" | |
| 14:39:10 | mordred | (that's the super basic use case and doesn't get in to "how do I know if I need a FIP or not" | |
| 14:39:14 | mriedem | POST /servers/{'networks': 'auto-floating'} :) | |
| 14:39:21 | mriedem | get me a network + floating IP | |
| 14:39:47 | mordred | mriedem: I'd still need the port id | |
| 14:39:50 | mordred | OR | |
| 14:39:59 | jaypipes | mordred: if that's the use case, why does any of that information need to be exposed to the end user? I mean, why not just say "hey, boot me a server with external connectivity". oh wait... that's kind of what "get me a network" was supposed to be. | |
| 14:40:00 | mordred | neutron auto-network-and-float would need to grow the abilityto take a server id | |
| 14:40:29 | mordred | jaypipes: yes. cloud.create_server(auto_ip=True) is what I _actually_ want | |
| 14:40:30 | alex_xu | mordred: after 'boot server' you can't get the network info, because the port created in nova-compute. So at least you need to 'boot server, show server, create fip' | |
| 14:40:35 | mriedem | mordred: i'm not sure why you'd need the port id if nova takes care of this for you at server create | |
| 14:40:54 | mriedem | anyway, we're sort of going off course here | |
| 14:40:55 | mordred | alex_xu: yes - wel - Ihave to do a poll loop on show server anyway to tell when it's active | |
| 14:41:09 | mordred | mriedem: because nova does not take care of this for me at server create | |
| 14:41:16 | jaypipes | alex_xu: the port doesn't *have* to be created in nova-compute. in fact, for virtually all NFV use cases, the ports are created separately and before any VM is launched. | |
| 14:41:23 | jaypipes | alex_xu: ala service function chaining | |
| 14:41:31 | mriedem | mordred: i know, today it doesn't, i'm talking about requested support | |
| 14:41:36 | mordred | mriedem: unless nova has grown a "please make me a FIP if I need a fip on this cloud otherwise please do not get me a FIP" | |
| 14:41:36 | mriedem | expanding get me a network | |
| 14:41:52 | mordred | mriedem: dear god in heaven yes that would be a BILLION times better | |
| 14:42:16 | mordred | mriedem: but that logic, I'll warn you, does get rather complex :) | |
| 14:42:31 | mordred | so I'll take port_id in addresses in the meantime :) | |
| 14:42:36 | mriedem | right so we're digressing | |
| 14:42:42 | alex_xu | jaypipes: emm..yea, and you creat the port by your own, then you already know the port id | |
| 14:42:56 | mriedem | mordred has pointed out that he doesn't care about or use GET /os-interface/{server_id} | |
| 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 | |