Earlier  
Later
New Search
Posted Nick Remark
#openstack-nova - 2018-06-13
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 stephenfin It is, but it involved far more work. (a) it is
16:26:32 mriedem but, i see what you're doing in (b) also
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
16:39:37 jangutter efried: I'm not 100% sure what's the criteria for qualifying to be a 'reference' plugin...
16:39:56 efried jangutter: Just thinking ahead whether code we have in openstack/networking-powervm is gonna stay there, or if we create openstack/os-vif-powervm (or whatever)
16:40:25 jangutter efried: ah, I've seen both. It all depends on the project, I guess.
16:40:46 efried okay
16:41:06 jangutter efried: and the convention seems to be something like vif_plug_powervm (for the os-vif plugin name)
16:41:42 efried jangutter: We're likely to have more than one - vif_plug_sea_powervm, vif_plug_sriov_powervm
16:42:05 efried anyway, I don't want to try to solve that now.
16:43:16 efried can I just say it's confusing that a `plugin` is responsible for providing `plug` and `unplug` actions.
16:44:12 dansmith man, infra is pretty busy
16:44:23 dansmith things have been in there 1.5 hours that still haven't even started a single job
16:47:42 openstackgerrit Eric Berglund proposed openstack/nova master: Powervm configuration cleanup https://review.openstack.org/575171
16:48:41 openstackgerrit Eric Berglund proposed openstack/nova master: Powervm configuration cleanup https://review.openstack.org/575171
16:50:58 simondodsley_ mriedem: can we force a rerun of the final checks for https://review.openstack.org/#/c/558530/
16:53:19 jangutter efried: wait till you try to to say out loud that this plugin is responsible for VIF plugging in Nova.
16:59:33 mriedem simondodsley_: yes, just leave a comment of "recheck" on the change
16:59:46 mriedem simondodsley_: note that because of the depends-on to the cinder docs patch, the nova patch won't merge until the cinder change merges
17:00:59 dansmith I just did
17:01:08 dansmith checked the failure and it seems unrelated
17:07:41 BlackDex Hmm i'm getting an error "DBNonExistentTable: (sqlite3.OperationalError) no such table: services"
17:11:00 openstackgerrit Jan Gutter proposed openstack/nova-specs master: Spec to implement vRouter HW offloads https://review.openstack.org/567148
17:20:53 simondodsley_ mriedem: I did a "recheck" and nothing happened...

Earlier   Later