| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2017-04-11 | |||
| 14:25:38 | openstackgerrit | Mario Villaplana proposed openstack/nova master: virt/ironic: Implement rescue and unrescue https://review.openstack.org/416487 | |
| 14:25:43 | sdague | maybe mordred's pov would be good | |
| 14:25:46 | jaypipes | sdague: it's just downright confusing to the end user, IMHO. I'd rather see an API that exposes things the end user is interested in in relation to the instance itself (not the port object in Neutron, which is what MANO/VNFM users are interested in) | |
| 14:25:50 | sdague | as he fights with network discovery all the time | |
| 14:26:10 | mordred | I do indeed! | |
| 14:27:27 | sdague | mordred: we're trying to fix the interfaces API in nova, because it remains full of some nova-net gorp. And the real question is what should it return in it's new state | |
| 14:27:31 | mordred | so - as a I read - a few quick thoughts: the addresses dict as it is today is horrible to work with, I'd love something new - I'd also love for port_ids to be returned inside of the server resource for all ips reported | |
| 14:27:42 | jaypipes | sdague: what I'm saying is not that network info isn't interesting to some users (it is for VNF managers and orchestrators) but for the most part, none of that is interesting for a normal cloud user. What they want to see is simply the IP[v46] address information, the routes and that's pretty much it. | |
| 14:28:02 | jaypipes | honestly, the VIF tag stuff should never have been added to Nova. It's a Neutron port profile thing iMHO. | |
| 14:28:17 | mordred | jaypipes: a normal cloud user cannot use a vm in a cloud without knowing a TON of informaiton about the networks and ports | |
| 14:28:25 | alex_xu | Emm...thinking of most user should distinguish the interface by ip address, so they have to have two API call to delete a interface | |
| 14:28:47 | jaypipes | mordred: other than routing and addressing information, what information about networks and ports do they need? | |
| 14:28:52 | sdague | alex_xu: which is all well and good until their interface dosen't actually get an IP because of things | |
| 14:28:52 | mordred | the number of neutron calls I have to do after getting a server from nova to figure out what the hell is going on with it is mind boggling | |
| 14:29:01 | mordred | jaypipes: well, the port_id for one | |
| 14:29:07 | dansmith | jaypipes: you mean the user-specified tag or the vlan tag? | |
| 14:29:14 | jaypipes | mordred: I'm thinking of myself as a normal cloud user here. In all my time using AWS, I've never needed anything other than routing and address info. | |
| 14:29:17 | mordred | jaypipes: also whether or not the IP came from a network that can route off of the cloud or not | |
| 14:29:26 | mordred | jaypipes: that's because AWS is only one install | |
| 14:29:28 | jaypipes | dansmith: both. | |
| 14:29:36 | sdague | jaypipes: because they have one very specific way of setting up networking | |
| 14:29:37 | mordred | jaypipes: and they give you your ip in DNS | |
| 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 | mordred | it would save at least 4 additional API calls, including 2 lists | |
| 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: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 | mordred | if we can agree on port id, then we're at a good baseline :) | |
| 14:33:57 | sdague | but, network_id also doesn't cost us anything | |
| 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 | |