| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2017-04-11 | |||
| 14:29:44 | jaypipes | sdague: no, they have many actually. | |
| 14:29:45 | dansmith | jaypipes: the user-specified tag seems extremely useful to me | |
| 14:29:50 | mordred | in openstack, your cloud could be doing networking a bilion different ways | |
| 14:29:55 | mordred | and doesn't use dns to return your ip | |
| 14:30:04 | jaypipes | dansmith: sure, on the Neutron *port* object, not on the server instance's information. | |
| 14:30:07 | dansmith | jaypipes: not for public cloud so much, but for just base IaaS where you are trying to arrange your I in a particular way... | |
| 14:30:15 | mordred | jaypipes: I REALLY need the port id on server objects | |
| 14:30:27 | dansmith | jaypipes: but the whole point is to know which interface in the guest is the one you tied to which neutron network | |
| 14:30:27 | mordred | it would save at least 4 additional API calls, including 2 lists | |
| 14:30:36 | dansmith | jaypipes: otherwise it's just ethN and you don't know what to do with it | |
| 14:30:38 | mordred | that's per server | |
| 14:30:40 | mordred | yah | |
| 14:31:09 | mordred | I have no way of knowing just from an address on the server if it's routable or if it's attached to the server or is NATed | |
| 14:31:17 | mordred | those are important things to know | |
| 14:31:45 | mordred | "fixed vs. floating" doesn't tell me anytihng by itself | |
| 14:31:46 | sdague | mordred: so... network_id also valuable in that context? I think that's kind of any outstanding question | |
| 14:31:51 | mordred | sdague: yes | |
| 14:31:53 | mordred | it is | |
| 14:31:56 | sdague | https://etherpad.openstack.org/p/nova-os-interfaces | |
| 14:32:02 | sdague | some sketching | |
| 14:32:08 | jaypipes | mordred: I still don't understand why this is information a user of Nova needs to know (versus just calling Neutron if you're a power user or a VNFM) | |
| 14:32:24 | mordred | because if an IP is not floating but is fixed, I need to be able to ask neutron whether or not the network the ip is from is externally routable or not | |
| 14:32:41 | openstackgerrit | Andy McCrae proposed openstack/nova master: Allow CONTENT_LENGTH to be present but empty https://review.openstack.org/455710 | |
| 14:32:58 | mordred | jaypipes, sdague: network id would be nice and save me a roundtrip - but port_id is the more important thing | |
| 14:33:11 | mordred | because port_id is my foreign key into my neutron resources | |
| 14:33:13 | jaypipes | mordred: you're equating floating IP to "publically routable" but OK... still doesn't answer why the *Nova* API needs to expose this stuff when Neutron's API already does. | |
| 14:33:15 | sdague | mordred: yeh, port_id seems mandatory | |
| 14:33:34 | mordred | jaypipes: port_id is the essential - I can live wihtout network being on the server | |
| 14:33:39 | jaypipes | mordred: I'm not arguing against port_id being in the return.. | |
| 14:33:43 | mordred | awesome | |
| 14:33:57 | sdague | but, network_id also doesn't cost us anything | |
| 14:33:57 | mordred | if we can agree on port id, then we're at a good baseline :) | |
| 14:34:02 | jaypipes | mordred: I'm arguing against crap like Neutron's "port_state" which is totally out of sync with the actual state of the VIF on the VM. | |
| 14:34:14 | sdague | and it would save mordred round trips in real world use cases | |
| 14:34:20 | jaypipes | mordred: which we just dump out into our os-interface/ return. | |
| 14:34:24 | mriedem | jaypipes: we also agreed to drop port_state | |
| 14:34:39 | jaypipes | also, WTF is it os-interface and not os-interfaces/ or, I don't know... just /interfaces. :( guh. | |
| 14:34:41 | mordred | oh- so - I'm saying please add port_id to the server | |
| 14:34:50 | mordred | not to /servers/{server}/interfaces | |
| 14:35:00 | mordred | adding it to /interfaces doens't save me anything | |
| 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 | mriedem | expanding get me a network | |
| 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: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 | |