14:04:21 <apuimedo> #startmeeting kuryr
14:04:22 <openstack> Meeting started Mon Jan 15 14:04:21 2018 UTC and is due to finish in 60 minutes.  The chair is apuimedo. Information about MeetBot at http://wiki.debian.org/MeetBot.
14:04:23 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
14:04:25 <openstack> The meeting name has been set to 'kuryr'
14:04:27 <apuimedo> Hi and welcome everybody
14:04:32 <apuimedo> who's here for the kuryr meeting?
14:04:39 <leyal> Hi
14:04:47 <danil> hi
14:05:19 <kaliya> Hi apuimedo, *
14:05:31 <yboaron> hi
14:05:33 <irenab> hi
14:05:39 <irenab> apuimedo, I have some conflicting meeting, apologize in advance for low participation
14:05:44 <apuimedo> irenab: ok
14:05:57 <apuimedo> #topic kuryr-kubernetes
14:06:22 <apuimedo> #info There was a very interesting video meeting today about network policy
14:06:26 <apuimedo> thanks for that leyal
14:07:08 <apuimedo> and now
14:07:11 <apuimedo> the biggest topic
14:07:24 <apuimedo> #info os-vif 1.8.0 was released
14:07:31 <leyal> apuimedo, thanks , and thanks to all participate :)
14:07:36 <apuimedo> it does two things that break us
14:08:09 <apuimedo> 1) It decided to drop ips from subnet and move them to vifs, which makes sense, but it probably should have been a major release
14:08:24 <apuimedo> this breaks our controller code that generates the os-vif object
14:08:56 <apuimedo> 2) They break the ovs loading we do for the CNI binary
14:09:21 <apuimedo> by having some clever code that detects when you try to load the module from an import callstack that does not include os-vif
14:09:33 <yboaron> apuimedo, can you elaborate abour ovs loading ? why do need that ?
14:10:48 <apuimedo> Personally I am inclined to get rid of os-vif
14:10:58 <apuimedo> (that would need doing our own ovo
14:11:11 <apuimedo> and adding hybrid bridge binding support
14:11:38 <apuimedo> yboaron: honestly I do not remember why we load it in main
14:11:53 <apuimedo> it may be related to building the binary or a limitation with pyinstaller
14:12:23 <irenab> apuimedo, shouldn't os-vif be backward compatible?
14:13:04 <apuimedo> irenab: that's what I thought
14:13:13 <apuimedo> but if I didn't misunderstand the code
14:13:15 <apuimedo> which I may
14:13:33 <apuimedo> the controller should be fixed for the new os-vif objects
14:13:41 <apuimedo> which I started doing on Friday night
14:13:58 <apuimedo> and the receiving end should be able to leverage the bc
14:14:08 <apuimedo> by asking for the old version of the object
14:14:10 <apuimedo> however...
14:14:25 <apuimedo> I did not find code in os-vif that translates to the old version
14:14:31 <apuimedo> so I have my doubts that it will work
14:14:37 <apuimedo> unless there is some magic I missed
14:16:12 <apuimedo> dulek: how well versed are you with OVO?
14:16:29 <apuimedo> IIRC it was used heavily in cinder
14:17:00 <dulek> apuimedo: Pretty okay. :)
14:17:27 <dulek> apuimedo: I'll take a look for compatibility code.
14:17:43 <apuimedo> dulek: could you take a quick look when you have a bit of time to see if the conversion of the ovo in the cni side will work
14:18:00 <apuimedo> i.e., create a vif OVO in the new form, serialize it
14:18:10 * dulek pulls the newest repo.
14:18:23 <apuimedo> and try to see if it can be made back into a primitive of the 1.0 version that cni expects
14:19:12 <irenab> apuimedo,so currently kuryr code is broken sich os-vif requirement was updated?
14:19:33 <apuimedo> irenab: yes, our requirements point to >= 1.7
14:19:38 <apuimedo> and 1.8 breaks us hard
14:19:42 <apuimedo> like really herd
14:19:44 <apuimedo> *hard
14:20:29 <dulek> apuimedo: There's no make_compatible method, so it cannot be backported by the object itself.
14:20:51 <dulek> Which is very frustrating, because what is the point of using o.vo then?
14:21:26 <apuimedo> dulek: that's what I thought
14:21:30 <apuimedo> that's plain useless
14:21:32 <apuimedo> xD
14:21:41 <apuimedo> honestly I got very mad when I saw that
14:21:57 <apuimedo> my WTF per minute increaased a lot between 12 and 3am last Fri
14:21:59 <apuimedo> xD
14:22:07 <apuimedo> so, what do you all think?
14:22:30 <yboaron> apuimedo,  u need to be in bed at 3 AM :-)
14:22:30 <dulek> I understand their explanation from the commit message. Though they've assumed that Nova and Neutron are the only consumers.
14:22:31 <apuimedo> do we file a bug on the lack of make_compatible and push the community for a 1.8.1 release
14:22:47 <apuimedo> yboaron: I wish, but I can't stand it when I don't know why things don't work
14:23:00 <apuimedo> or do we just make our own smalled ovo for vifs?
14:23:07 <dulek> apuimedo: I just wonder if make_compatible can work in a cross-object manner.
14:23:20 <apuimedo> dulek: I had told them that we used it back in atlanta
14:23:32 <apuimedo> dulek: why shouldn't it?
14:23:38 <apuimedo> I'm honestly asking
14:24:32 <irenab> apuimedo, what are the benefits to keep using os-vif?
14:24:36 <dulek> apuimedo: I mean data is moved between objects. If no ips field is provided for Subnet, then it would be hard to magically get the field value in make_compatible.
14:25:56 <apuimedo> irenab: to be able to use their ovs hybrid firewall driver
14:26:12 <apuimedo> and admittedly, now that they moved to pyroute2, the perf will be less bad
14:26:45 <apuimedo> dulek: shouldn't make compatible know about the needs to move it from vif.fixed_ips to vif.subnet.ips ?
14:27:06 <apuimedo> irenab: getting rid of it is a bit more work
14:27:10 <apuimedo> but has two advantages
14:27:19 <apuimedo> we can probably have a smaller vif annotation
14:27:24 <dulek> apuimedo: Ah, we want VIF.make_compatible, not Subnet.make_compatible. Yeah, that's possible to be done.
14:27:30 <apuimedo> which we'll make sure to have make_compatible for
14:27:51 <apuimedo> and we need to add support for hybrid plug
14:28:01 <apuimedo> but we get rid of the privsep (which we definitely do not need)
14:29:17 <irenab> apuimedo, is there a bug on kuryr side for the breakage?
14:29:32 <apuimedo> irenab: no. I was not in the mood to file it
14:29:36 <apuimedo> I'll file it when the meeting ends
14:29:44 <apuimedo> irenab: thanks for the reminder :-)
14:29:48 <irenab> May I suggest to add there the options to fix the issue (the 2 options you presented)?
14:30:19 <irenab> I think I will need some time to dive into details to provide my opinion
14:30:47 <apuimedo> irenab: very well, thanks!
14:30:49 <apuimedo> ok, next
14:31:01 <apuimedo> danil: what's the status on your sriov efforts?
14:31:13 <apuimedo> did you see ltomasbo's multipools patch?
14:31:14 <danil> I have some questions about SRIOV patches in kuryr-kubernetes project (https://review.openstack.org/#/q/status:open+project:openstack/kuryr-kubernetes+branch:master+topic:bp/kuryr-kubernetes-sriov-support-refactor).
14:31:19 <apuimedo> https://review.openstack.org/528345
14:31:28 <apuimedo> danil: go ahead
14:31:42 <danil> yes, I've seen  ltomasbo's multipools patch. It looks good to me.
14:32:07 <danil> I fixed cni part in my patches, but the main problem is in design of MULTI-VIF support. As I understand, current design corresponds to merged design proposal (https://review.openstack.org/#/c/513715/). I can't understand clearly, what I have to change in "multi-vif driver -> other drivers" interaction.
14:33:11 <apuimedo> what do you mean?
14:33:45 <irenab> danil, I think now it is very specific multi-vif driver, that handles sr-iov and requested subnets cases
14:34:38 <irenab> It is not extendable to other cases
14:34:39 <danil> but I thought it was described in design proposal
14:35:04 <danil> so, I have to collaborate with ltomasbo's multipools patch?
14:35:36 <apuimedo> danil: irenab: for me it is fine if it is specific to sriov
14:35:55 <apuimedo> ltomasbo's is for making the default
14:36:01 <apuimedo> binding
14:36:17 <apuimedo> being able to be set on a per node basis
14:36:17 <yboaron> danil, are we going to support SR-IOV for both BM and nested  cases ?
14:36:18 <apuimedo> IIUC
14:36:18 <irenab> Maybe this is ok for now, just probably need to change the driver name to something more sr-iov specific
14:36:47 <apuimedo> danil's approach helps in being able to add sriov devices to pods
14:37:02 <danil> irenab, do you mean to change multivif driver name?
14:37:18 <apuimedo> irenab: doesn't it allow pods with multiple vifs?
14:37:21 <irenab> danil, yes, since it is not real multi-vif in a generic sense
14:37:26 <apuimedo> I think the name is fine then
14:37:27 <danil> apuimedo, yes. And drivers interaction
14:37:59 <apuimedo> but ltomasbo's driver should be per-node-vif-driver
14:38:04 <apuimedo> or som,ething
14:38:20 <irenab> apuimedo, there is an active discussion in k8s net sig on multi network support, so eventually it will make sense to align with the approach
14:38:45 <apuimedo> irenab: no question about that
14:38:52 <apuimedo> that's THE WAY!
14:39:05 <yboaron> apuimedo, that's right ,  ltomasbo's idea is single VIF  driver per node
14:39:06 <apuimedo> but allowing sriov on the meantime as extra vifs
14:39:09 <apuimedo> is nice
14:40:13 <irenab> agreed
14:41:49 <irenab> danil, I will recheck the pathes and try to suggest better name. I am ok on direction till we converge with k8s net sig proposal
14:41:56 <apuimedo> good
14:42:01 <apuimedo> anything else danil?
14:42:08 <danil> irenab, good, thanks
14:42:18 <danil> no, thats all
14:42:21 <danil> thanks
14:42:29 <irenab> I do not have SR-IOV nics, so someone need to verify. apuimedo would you be able to do it?
14:42:47 <apuimedo> irenab: I think so
14:42:53 <irenab> thanks
14:43:01 <apuimedo> yboaron: have you used sriov before?
14:43:10 <yboaron> yes
14:43:37 <apuimedo> yboaron: then I'll get you some BM to try it out :-)
14:43:58 <yboaron> apuimedo,  I'm the happiest person in globe !!
14:44:35 <apuimedo> yboaron: good!
14:44:37 <dulek> yboaron: And it's on blue monday! Nice!
14:44:37 <apuimedo> :-)
14:45:17 <apuimedo> dulek: os-vif made me blue friday instead
14:45:26 <apuimedo> what else do we have for the meeting today?
14:45:41 <kaliya> apuimedo, all, hi (Fabrizio)
14:45:54 <kaliya> apuimedo: I'm doing some research in the scope of https://blueprints.launchpad.net/kuryr-kubernetes/+spec/nested-dpdk-support , do you know what's the status exactly?
14:46:03 <apuimedo> kaliya: nice to see you!!!
14:46:29 <apuimedo> kaliya: now that's a bp I didn't see in a long time!
14:46:48 <apuimedo> the status is we'd like to see it worked on, but it hasn't had an implementer in forever
14:46:57 <kaliya> let's resurrect it!
14:47:02 <apuimedo> kaliya: intel abandoned it
14:47:07 <kaliya> I saw some fancy presentation by Intel, but seems it's not worked in practice
14:47:19 <kaliya> I see
14:48:10 <apuimedo> kaliya: with Intel together we presented the nested macvlan in the barcelona summit
14:48:18 <apuimedo> did they do one on dpdk?
14:48:24 <dulek> kaliya: Looks like it was being driven by Intel networking team. I can try to find you a contact to ask about it.
14:48:27 <apuimedo> I know they worked on it
14:48:35 <kaliya> now k8s is adding some resource management features allowing to theoretically enable dpdk (i.e. hugepages in beta)
14:48:36 <apuimedo> after that
14:48:39 <kaliya> ya thanks dulek
14:48:45 <apuimedo> kaliya: that's right
14:48:51 <apuimedo> but how will that play with nested
14:48:52 <kaliya> apuimedo: https://dpdksummit.com/Archive/pdf/2017Userspace/DPDK-Userspace2017-Day2-13-DPDKUserspace%20Summit20170927.pdf
14:49:01 <apuimedo> as in pod on VM getting dpdk going
14:49:16 <apuimedo> ah, yes, kural was working on it too
14:50:06 <apuimedo> kaliya: do you have some demo or use case in mind?
14:50:31 <kaliya> not really, just collecting ideas for now:)
14:51:27 <apuimedo> right
14:51:37 <apuimedo> well, if there is any other thing you have in mind
14:51:41 <apuimedo> let us know ;-)
14:51:55 <kaliya> ok I will ask help in channel for sure
14:52:06 <kaliya> I guess the research is for perf resons - for now
14:53:17 <kaliya> that's all I had to say for now, ty
14:53:32 <apuimedo> good
14:53:37 <apuimedo> welcome kaliya!
14:53:38 <dulek> kaliya: You can ask sean-k-mooney about it, I think he's based in the same office, the person who proposed the BP.
14:54:16 <apuimedo> does anybody have anything else?
14:54:17 <kaliya> thanks dulek
14:54:20 <apuimedo> 6 minutes remaining?
14:54:23 <yboaron> kaliya, BTW fo performance , when SRIOV will be supported by kury-k8s , you can run DPDK in container's VNF
14:55:27 <kaliya> ok yboaron
14:56:21 <apuimedo> #topic general
14:57:05 <apuimedo> #info there will be a keynote on kuryr https://devconfcz2018.sched.com/event/DJZ2/openshift-openstack-integration-hugh-brock-and-friends
14:57:09 <apuimedo> at devconf.cz
14:57:18 <apuimedo> ltomasbo: and myself will be part of the presenting team
14:59:21 <apuimedo> alright
14:59:25 <apuimedo> closing
14:59:33 <apuimedo> THank you all for participating!
14:59:35 <apuimedo> #endmeeting