| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2017-04-11 | |||
| 14:02:20 | mriedem | we could drop port_state since it doesn't really make sense | |
| 14:02:23 | mriedem | or help | |
| 14:02:28 | peter-hamilton | johnthetubaguy: i'm not that familiar with them | |
| 14:02:42 | mriedem | peter-hamilton: https://github.com/openstack/oslo.versionedobjects | |
| 14:02:44 | sdague | /ips is all super weird, and that's all in the main server doc iirc | |
| 14:02:52 | peter-hamilton | mriedem: thanks! | |
| 14:02:58 | johnthetubaguy | peter-hamilton: sure thing, the rest of those instance extra entries are basically serialised versioned objects, helps with upgrades, etc, long term | |
| 14:03:06 | mriedem | sdague: it is, in fact, more of /ips is in the main server doc than it is in /ips | |
| 14:03:09 | mriedem | sdague: details wise | |
| 14:03:26 | peter-hamilton | johnthetubaguy: ok, so it would just match the current convention for InstanceExtras | |
| 14:03:33 | johnthetubaguy | peter-hamilton: yeah | |
| 14:03:42 | mriedem | peter-hamilton: the nova objects are in https://github.com/openstack/nova/tree/master/nova/objects | |
| 14:03:49 | peter-hamilton | johnthetubaguy: thanks | |
| 14:03:56 | mriedem | instance_extra stuff is used in https://github.com/openstack/nova/blob/master/nova/objects/instance.py | |
| 14:04:09 | peter-hamilton | johnthetubaguy: i'm fine with making that a versionedobject then | |
| 14:04:15 | mriedem | https://github.com/openstack/nova/blob/master/nova/db/sqlalchemy/models.py#L372 | |
| 14:04:28 | peter-hamilton | johnthetubaguy: i'm working through some updates to the spec now | |
| 14:04:30 | johnthetubaguy | peter-hamilton: the extra bit of detail might be here, in case that helps with context: https://github.com/openstack/nova/blob/master/nova/objects/instance.py#L718 | |
| 14:04:39 | mriedem | if we store something in the nova database and it's passed over rpc, it should be a versioned object | |
| 14:04:43 | peter-hamilton | johnthetubaguy: thanks, i'll look it over | |
| 14:04:45 | johnthetubaguy | peter-hamilton: sweet, will try hit that as soon as its updated | |
| 14:04:58 | johnthetubaguy | +1 mriedem | |
| 14:08:27 | dansmith | mriedem: is this docs failure known? http://logs.openstack.org/92/443292/15/check/gate-nova-docs-ubuntu-xenial/a9a4dc5/console.html | |
| 14:08:45 | dansmith | seems like the kind of thing that would be wide failure | |
| 14:08:46 | mriedem | dansmith: not by me | |
| 14:08:53 | dansmith | okay | |
| 14:09:04 | mriedem | lemme checkade logstash | |
| 14:09:09 | sdague | mriedem: I don't understand the dropping of mac address, how would you determine what guest interface is what port if you don't have that? | |
| 14:09:35 | alex_xu | sdague: good point~ | |
| 14:10:04 | mriedem | sdague: I only mentioned that b/c the /ips API also has it | |
| 14:10:12 | mriedem | so maybe we remove mac from /ips and leave in os-interface | |
| 14:10:14 | sdague | dansmith: it looks like that job ran on python 3.5, which is the issue | |
| 14:10:30 | dansmith | sdague: talking in infra now, it's known | |
| 14:10:37 | sdague | mriedem: well, if you have > 1 port I'm not sure how ips helps | |
| 14:10:40 | mriedem | yeah http://logstash.openstack.org/#dashboard/file/logstash.json?query=message%3A%5C%22AttributeError%3A%20'dict_keys'%20object%20has%20no%20attribute%20'sort'%5C%22&from=7d | |
| 14:11:39 | dansmith | pabelanger said they'd send out a note shortly | |
| 14:11:46 | openstackgerrit | Gábor Antal proposed openstack/nova master: Add json style checking for sample notifications https://review.openstack.org/443677 | |
| 14:11:56 | mriedem | the /ips api is also a bit goofed up since it keys off the network label | |
| 14:12:24 | mriedem | so it's less about showing fixed/floating ips for a server and more about showing addresses for a server within a network | |
| 14:13:06 | mriedem | and of course we have /os-fixed-ips/ | |
| 14:13:29 | mriedem | but that's not tied to the server | |
| 14:13:47 | mriedem | and /os-floating-ips but that's not tied to a server either | |
| 14:13:49 | sdague | ok, so, let's not go through everything that's wrong, that will just take us in loops :) | |
| 14:13:58 | mriedem | so, | |
| 14:13:58 | mriedem | right, | |
| 14:14:02 | sdague | how compat are you trying to be here? | |
| 14:14:17 | mriedem | can we agree that at some point in the future, we want to expose bdm and vif tags out of the rest api? | |
| 14:14:28 | mriedem | since those are a nova-only concept | |
| 14:15:16 | mriedem | well, i guess you can set tags on ports in neutron too | |
| 14:15:28 | mriedem | but you can't tag volumes in cinder, and they aren't used the same way in nova anyway | |
| 14:16:04 | sdague | https://etherpad.openstack.org/p/nova-os-interfaces - scratch space, because there seem like there are so many options | |
| 14:16:10 | sdague | yeh, I think tags exposed would be good | |
| 14:16:19 | mriedem | sdague: my goal is one day expose tags for both bdms and ports in a single microversion, and i planned on exposing vif tags out of the os-interface API | |
| 14:16:27 | sdague | sure | |
| 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 | mriedem | GET /servers/{server_id}/ports? | |
| 14:17:29 | jaypipes | mriedem: honestly, I hate all the existing APIs for dealing with both BDMs and vNICs. | |
| 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 | 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 | |