| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2018-06-13 | |||
| 15:20:55 | gibi | mriedem: me neither so fair enough :) | |
| 15:21:21 | mgagne | mriedem: yes, that's right: CellsV1 + Ironic + Caching. CellsV1 + libvirt + filter elsewhere. (and no cells + libvirt + Caching in our private cloud) | |
| 15:27:01 | openstackgerrit | Chris Dent proposed openstack/nova master: [placement] replace deprecated accept.best_match https://review.openstack.org/575127 | |
| 15:30:52 | melwitt | I'm going to be out next week and need someone to run the nova meeting June 21 at 21:00 UTC. is there anyone who can help with that? | |
| 15:34:30 | mriedem | i'm out wed-fri next week so not it | |
| 15:34:54 | mriedem | i nominate dansmith or efried | |
| 15:35:55 | openstackgerrit | Chris Dent proposed openstack/nova master: [placement] Add status and links fields to version document at / https://review.openstack.org/575117 | |
| 15:37:15 | openstackgerrit | Jay Pipes proposed openstack/nova master: placement: Allocation.consumer field https://review.openstack.org/565405 | |
| 15:37:16 | openstackgerrit | Jay Pipes proposed openstack/nova master: rework allocation handler _allocations_dict() https://review.openstack.org/565407 | |
| 15:37:17 | openstackgerrit | Jay Pipes proposed openstack/nova master: Add a microversion for consumer generation support https://review.openstack.org/565604 | |
| 15:37:18 | openstackgerrit | Jay Pipes proposed openstack/nova master: Fix nits from change Id609789ef6b4a4c745550cde80dd49cabe03869a https://review.openstack.org/574324 | |
| 15:39:23 | dansmith | next week, the 21st which is a late meeting right? | |
| 15:40:04 | dansmith | melwitt: if you'll update the agenda so I just have to parrot it then I'll be your huckleberry | |
| 15:43:00 | melwitt | dansmith: yes, it's the 21:00 UTC, 2pm PST one. will update the agenda on friday (there's a chance runways will change next week tho). thank you for the help | |
| 15:43:42 | dansmith | melwitt: then I will parrot incorrect runway information | |
| 15:44:08 | dansmith | melwitt: I recommend you get a cell connection and laptop so you can update it from the bush if you want it to be correct | |
| 15:44:29 | melwitt | thanks for the tip :P | |
| 15:44:49 | dansmith | heh | |
| 15:47:47 | openstackgerrit | Eric Fried proposed openstack/os-vif master: doc: Mention second arg to (un)plug in usage doc https://review.openstack.org/575151 | |
| 15:49:01 | efried | Anyone feel like giving me a quick overview of what os-vif/os-brick are and how the fit into the world? | |
| 15:49:14 | efried | This is something I have been putting off knowing for too long. | |
| 15:49:28 | mriedem | connect vifs and volumes on the host | |
| 15:49:36 | mriedem | for various backends | |
| 15:49:54 | mriedem | </end> | |
| 15:50:07 | dansmith | checks out | |
| 15:50:07 | efried | mriedem: Does one subclass stuff out of those libs for specific platforms or whatever? | |
| 15:50:26 | mriedem | probably not, you'd put a connector in brick | |
| 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 | |