| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2017-04-11 | |||
| 14:16:33 | mriedem | i'm totally fine with putting the os-interface response on a diet | |
| 14:16:40 | mriedem | i.e. remove port_status and fixed_ips | |
| 14:16:48 | mriedem | leave port_id, net_id, and mac_addr | |
| 14:17:01 | sdague | so, the real question I wonder is if we are making enough change to those, if we change the resource url at the same time | |
| 14:17:21 | mriedem | GET /servers/ports? | |
| 14:17:29 | jaypipes | mriedem: honestly, I hate all the existing APIs for dealing with both BDMs and vNICs. | |
| 14:17:29 | mriedem | GET /servers/{server_id}/ports? | |
| 14:17:30 | sdague | I was going to say interfaces | |
| 14:17:49 | sdague | jaypipes: ok, well hate only gets so far :) | |
| 14:17:59 | mriedem | jaypipes: yeah, provide your alternatie | |
| 14:18:02 | mriedem | *alternative | |
| 14:18:10 | jaypipes | fine, I will. | |
| 14:18:14 | mriedem | because i'm about to ragequit on this spec | |
| 14:18:16 | sdague | it seems like this is the way to understand relationships so you can chain through | |
| 14:18:27 | sdague | well, etherpad sketch things first | |
| 14:22:20 | sdague | is net_id readily available? | |
| 14:22:42 | sdague | like how much of this data exists cheaply for us? | |
| 14:23:08 | mriedem | it's cheap | |
| 14:23:16 | mriedem | it's all in the instance info_cache | |
| 14:24:19 | openstackgerrit | Andy McCrae proposed openstack/nova master: Don't force CONTENT_LENGTH to be an int() https://review.openstack.org/455710 | |
| 14:24:58 | jaypipes | sdague: honestly, I'm thinking in terms of the end user here. Which end user needs to know the subnet_id or the net_id? | |
| 14:25:06 | openstackgerrit | Andy McCrae proposed openstack/nova master: Allow CONTENT_LENGTH to be present but empty https://review.openstack.org/455710 | |
| 14:25:27 | sdague | jaypipes: if you have multiple networks and some can get out and others cant? | |
| 14:25:33 | mriedem | jaypipes: we agreed to drop fixed_ips from the response, which drops the subnet_id | |
| 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 | 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:28:52 | sdague | alex_xu: which is all well and good until their interface dosen't actually get an IP because of things | |
| 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 | 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 | |