| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2018-06-13 | |||
| 15:50:34 | mriedem | there are platform-specific connectors in brick | |
| 15:50:38 | mriedem | for windows and p and z | |
| 15:50:55 | efried | mriedem: but not in os-vif | |
| 15:51:09 | efried | that one has just ovs and lb | |
| 15:51:09 | mriedem | os-vif has vif type specific objects | |
| 15:51:17 | mriedem | os-vif can load up plugins | |
| 15:51:25 | mriedem | so vendor vif type plugins don't need to be in the os-vif repo | |
| 15:51:29 | mriedem | just loaded via stevedore extension point | |
| 15:51:34 | mriedem | like jangutter's | |
| 15:51:49 | mriedem | os-brick doesn't use versioned objects, and os-vif does, | |
| 15:52:05 | mriedem | the long-term / ideal with os-vif is nova/neutron can pass around versioned serialized versions of os-vif objects | |
| 15:52:35 | mriedem | rather than neutron throwing a random bag-o-dicts at nova in the port binding profile and other random dicts and nova just trusting things might not be there and handling if so for upgrades | |
| 15:53:15 | mriedem | so nova can say, here is this version of this ovs object that i'm plugging into this host for this port, and neutron will make that object compatible for the version of os-vif it understands | |
| 15:53:38 | jangutter | An os-vif object gets handled by two things: Nova passes it to the hypervisor to say "hey, plug this into the instance", it also passes it to the os-vif 3rd (or 1st) party plugin to say "hey, plug this into the datapath". | |
| 15:54:07 | efried | Do you have an example of one of these plugin thingies? | |
| 15:54:24 | jangutter | There's reference plugins in the os-vif repo for things like Linuxbridge and OVS. | |
| 15:54:31 | mriedem | efried: this is the defailed spec for os-vif https://specs.openstack.org/openstack/nova-specs/specs/newton/implemented/os-vif-library.html | |
| 15:54:52 | mriedem | https://github.com/6WIND/os-vif-plugin-vhostuser-fp | |
| 15:54:55 | jangutter | Sometimes the os-vif plugin thingy is basically a null operation (libvirt does everything, say). | |
| 15:55:00 | mriedem | https://github.com/bigswitch/os-vif-bigswitch | |
| 15:55:11 | mriedem | https://github.com/bigswitch/os-vif-bigswitch/blob/master/setup.cfg#L26 | |
| 15:55:27 | mriedem | register an os_vif extension point with the vif type namespace key | |
| 15:55:29 | efried | "passes it to the hypervisor" via e.g. plug_vifs in the ComputeDriver API? | |
| 15:55:30 | mriedem | 'ivs' in this case | |
| 15:56:14 | efried | Thanks guys. | |
| 15:56:21 | jangutter | efried: I think so, libvirt has a conversion layer for VIFs inside Nova. | |
| 15:56:31 | mriedem | plug_vifs takes the network info list of vifs (ports) and translates those to os-vif objects which for libvirt then gets converted to interface configs, which go into the guest xml | |
| 15:56:57 | mriedem | the actual 'plug' call in os-vif on the object is the datapath thing i think? | |
| 15:57:32 | efried | edmondsw: Do we have (plans for) integration of networking-powervm into os-vif? | |
| 15:57:37 | jangutter | mriedem: yeah 'plug' and 'unplug' calls into the os-vif plugin that's been registered. | |
| 15:57:52 | efried | ...or am I still completely misunderstanding how this ties in? | |
| 15:58:23 | efried | networking-powervm provides, uh, ml2 plugin (or is it agent) and, uh, mech driver (or is it agent/plugin) | |
| 15:58:44 | efried | are those things that should be tied into os-vif somehow? | |
| 16:00:52 | mriedem | efried: it would be a plugin repo i think | |
| 16:00:55 | mriedem | like the ivs one above | |
| 16:01:10 | efried | k, thanks again. | |
| 16:01:25 | mriedem | so if you're using networking-powervm on a compute host, you need to have that repo installed there as well so nova can load it up via the extension point, keyed by the vif type | |
| 16:01:37 | mriedem | and the vif type comes from the neutron agent running on that host i believe | |
| 16:03:09 | jangutter | yep, the translation from Neutron VIF to os-vif is currently in the Nova network API, and should be independent of hypervisor, I believe. | |
| 16:04:01 | jangutter | There's like 3 things that call themselves VIF objects I think. | |
| 16:21:13 | jangutter | efried: for now, neutron knows nothing about os-vif, so things like the ml2 plugin and agent is completely unaware. | |
| 16:22:18 | efried | o | |
| 16:24:16 | cdent | efried: that's the saddest little 'o' I have ever seen | |
| 16:24:52 | stephenfin | mriedem, dansmith: Question RE: using limits to pass stuff back from the filter. Do you prefer (a) or (b)? (a) http://paste.openstack.org/show/723400/ (b) http://paste.openstack.org/show/723402/ | |
| 16:25:16 | efried | I'm still at the stage of overwhelm. This started because I wanted to try to understand the cyborg os-acc model, but it's described in terms of os-brick/os-vif as if you already know how those things work. So.... | |
| 16:25:25 | stephenfin | I've implemented (a) but it feels icky for some reason | |
| 16:25:47 | stephenfin | efried: What aspect of those do you not understand? | |
| 16:25:57 | stephenfin | I can talk to os-vif at least, anyway | |
| 16:26:00 | mriedem | stephenfin: (a) | |
| 16:26:08 | mriedem | i'm pretty sure that's exactly what i called out in the spec | |
| 16:26:32 | mriedem | but, i see what you're doing in (b) also | |
| 16:26:32 | stephenfin | It is, but it involved far more work. (a) it is | |
| 16:26:42 | efried | stephenfin: Basically all of it - but Matt and Jan gave me some refs above that I'm clawing my way through. | |
| 16:26:44 | mriedem | stephenfin: i never thought about (b) during the spec review | |
| 16:27:05 | stephenfin | Well, (b) made more sense to be because NUMATopologyLimits is the same kind of thing | |
| 16:27:07 | efried | stephenfin: I did fix a doc, though :) Pretty sure it was yours... https://review.openstack.org/575151 | |
| 16:27:18 | mriedem | stephenfin: why wouldn't the networks field in (b) but an instance of InstanceNUMANetworkInfo? | |
| 16:27:24 | stephenfin | Metadata about the request, rather than an actual requested itself | |
| 16:27:30 | mriedem | i thought that was the whole point - InstanceNUMANetworkInfo gets passed around and is the common interface | |
| 16:27:47 | stephenfin | There would be, though I've noted InstanceNUMANetworkInfo == NUMANetworkInfo | |
| 16:28:13 | stephenfin | but that would actually read " 'network': InstanceNUMANetworkInfo() " | |
| 16:28:16 | mriedem | well, 'networks': NUMANetworkInfo(), doesn't work anyway | |
| 16:28:18 | mriedem | that's not a field | |
| 16:28:29 | stephenfin | oops, fields.ObjectField | |
| 16:28:34 | dansmith | stephenfin: they're equivalent in functionality, just where it goes (top level or nested inside the numa limits obj) right? | |
| 16:28:40 | mriedem | dansmith: yeah | |
| 16:28:42 | stephenfin | dansmith: Correct | |
| 16:28:45 | mriedem | doesn't really matter to me i guess | |
| 16:28:49 | mriedem | i never thought about the nesting | |
| 16:28:56 | dansmith | yeah, so I'm mostly meh, but (b) seems maybe a little better | |
| 16:29:12 | stephenfin | It makes semantic sense to me but making sure I'm not mistaken | |
| 16:29:15 | mriedem | yeah wfm as well | |
| 16:29:23 | mriedem | i just never thought of that as an option | |
| 16:29:25 | stephenfin | I'm still not really up on why that object even exists... | |
| 16:29:33 | stephenfin | Cool, I'll try that out so | |
| 16:29:37 | edmondsw | efried I believe networking-powervm is just our SEA agent, not OVS, whereas I thought os-vif was just for OVS? | |
| 16:29:38 | mriedem | because random dicts o doom aren't fun? | |
| 16:29:54 | mriedem | stephenfin: the limits get passed over rpc | |
| 16:30:00 | mriedem | so they should be in versioned objects | |
| 16:30:18 | jangutter | efried: If Cyborg can pass os-acc objects directly to Nova, then it's already cut through 1.5 stages of migration os-vif is currently undergoing. | |
| 16:30:26 | stephenfin | Not the object itself but rather the idea of NUMA limits in the first place | |
| 16:30:34 | mriedem | jangutter: ++ | |
| 16:30:38 | jangutter | edmondsw: os-vif is for EVERYONE | |
| 16:30:39 | mriedem | i wish os-brick was passing objects to nova | |
| 16:30:55 | edmondsw | jangutter ok tx for clarifying | |
| 16:30:59 | mriedem | the host connector dict to/from os-brick and the connection_info dict to/from cinder are totally random | |
| 16:31:27 | mriedem | but standardizing connection_info across 80 cinder backends isn't anything anyone wants to work on | |
| 16:32:17 | jangutter | edmondsw: I think the first reference plugins was for OVS and linuxbridge, but the VIF migration is still underway. There's not a lot left for libvirt anymore. | |
| 16:33:04 | edmondsw | we have a TODO to try to use os-vif. I will expand my thinking to include SEA as well as OVS for that | |
| 16:33:09 | efried | edmondsw: Yeah, it looks like maybe we're supposed to provide an os_vif.objects.vif.VIFSharedEthernetAdapter whose `plugin` field points to... some version of our networking-powervm ml2 thingy?? | |
| 16:33:16 | edmondsw | I believe sean-k-mooney had said he might help look at that | |
| 16:34:07 | efried | edmondsw: Okay, if we have a TODO to work on os-vif integration, that's enough for me for now in that direction. | |
| 16:34:28 | edmondsw | yep, it's listed in https://etherpad.openstack.org/p/powervm-in-tree-todos | |
| 16:34:41 | efried | edmondsw: My immediate goal is just to understand the framework so I have context when cyborg says "os-acc is structured like os-vif" and assumes you know what that means. | |
| 16:35:03 | edmondsw | efried add any comments that in that etherpad as appropriate | |
| 16:37:06 | jangutter | edmondsw: efried: nova + external ovs-vif plugin should look and operate exactly like "legacy nova vif handling" (at this stage of os-vif migration) | |
| 16:37:55 | jangutter | edmondsw: efried: the only difference, is that at some point during the plugging process code under your control gets run. | |
| 16:38:03 | efried | jangutter: I haven't looked yet, do folks converting from legacy to os-vif keep their plugin in the same external project or create a new one just for os-vif? | |
| 16:38:42 | jangutter | efried: I think there's only a few in-tree plugins, almost everything is designed to be external or 3rd party. | |
| 16:38:57 | efried | jangutter: That's what I mean - external/3rd-party | |