14:02:25 <apuimedo> #startmeeting kuryr
14:02:26 <openstack> Meeting started Mon Oct 10 14:02:25 2016 UTC and is due to finish in 60 minutes.  The chair is apuimedo. Information about MeetBot at http://wiki.debian.org/MeetBot.
14:02:28 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
14:02:30 <openstack> The meeting name has been set to 'kuryr'
14:02:43 <apuimedo> Welcome to yet another Kuryr meeting
14:02:45 <mchiappe> o/
14:02:47 <janonymous> o/
14:02:49 <ltomasbo> o/
14:02:49 <apuimedo> Who's here?
14:02:50 <ivc_> o/
14:02:52 <tonanhngo> o/
14:02:52 <limao> o/
14:02:53 <garyloug> o/
14:02:53 <yedongcan> o/
14:03:00 <apuimedo> Nice
14:03:15 <apuimedo> Welcome everybody
14:03:46 <apuimedo> #topic kuryr-lib
14:04:06 <lmdaly> o/
14:04:55 <apuimedo> #info apuimedo finishing the cni patch addressing ivc's comments
14:05:36 <apuimedo> #info limao got Kuryr library to openstack requirements
14:06:24 <apuimedo> As part of his effort to get testing with master and released version of Kuryr lib to Kuryr libnetwork
14:07:18 <apuimedo> Anything else on Kuryr lib (I'm taking the meeting on the go, so I have to take things of the top off my head)
14:07:52 <mchiappe> well
14:08:18 <apuimedo> Go ahead
14:08:31 <mchiappe> after testing the code lmdaly has found a little issue on the veth creation
14:08:49 <mchiappe> but maybe we can discuss it later on the other channel
14:09:14 <apuimedo> Probably a regression from my patch. Ok let's get to it later on the channel
14:09:26 <mchiappe> regarding kuryr-libenetwork I have a few question I would like to discuss with you all on a few design decision
14:09:32 <mchiappe> decisionS
14:09:35 <apuimedo> #topic kuryr-libnetwork
14:09:45 <mchiappe> but I don't want to hijack the meeting :)
14:09:48 <apuimedo> Let's move to that then
14:09:53 <mchiappe> ok cool
14:10:23 <mchiappe> to main concerns are around the best way to deal with the IPAM allocations
14:10:40 <apuimedo> #info limao got the jobs merged for the extra tests with master kuryr-lib
14:10:59 <apuimedo> He found some issue and sent the patches for it
14:11:09 <mchiappe> in ipam_request_pool, for the nested use case, some info on the existing pool has to be passed in by the docker user
14:11:17 <apuimedo> #action apuimedo to review
14:11:30 <apuimedo> Which info?
14:11:45 <mchiappe> the subnet in particular
14:12:20 <apuimedo> I planned to have that as a ipvlan/macvlan drivers configuration
14:12:22 <mchiappe> basically when running in the nested mode the docker user should reuse the already neutron allocated pool
14:12:42 <apuimedo> When you deploy the vm, you configure which subnet it uses
14:13:48 <mchiappe> on the neutron side?
14:14:13 <apuimedo> No, on the Kuryr.conf of the libnetwork driver
14:15:17 <mchiappe> so, the user won't need to specify any optional parameter, kuryr will take those from the config file, is that what you mean?
14:15:24 <apuimedo> Right
14:15:44 <apuimedo> That's the idea I had other people feel welcome to chip in
14:15:48 <mchiappe> but is it really necessary to specify these parameters in the first place?
14:16:13 <apuimedo> No, it could be inferred
14:16:23 <apuimedo> Probably
14:16:33 <mchiappe> yes, I'm not sure whether we can leave room for other options
14:16:46 <mchiappe> but I'm not sure are there either
14:17:38 <apuimedo> Let's take it to the channel
14:17:38 <mchiappe> when you run in nested mode if I'm not wrong you have no option, you must join the same network the VM is already part of
14:17:47 <mchiappe> sure :)
14:18:09 <apuimedo> For ipvlan and macvlan yes
14:18:23 <apuimedo> For neutron trunk you can choose
14:18:39 <apuimedo> And have ports from different subnets
14:18:49 <apuimedo> So it is per driver
14:19:39 <apuimedo> #action define the ipvlan macvlan subnet configuration or detection
14:19:50 <apuimedo> Anything else on Kuryr libnetwork
14:19:56 <mchiappe> In case of ipvlan/macvlan, which EndpointOperationalInfo should be returned?
14:20:43 <apuimedo> Fabricated
14:21:09 <mchiappe> apuimedo: ok
14:21:47 <apuimedo> #topic Kuryr-Kubernetes
14:22:06 <apuimedo> Ivc, Vikas, you both here?
14:22:21 <ivc_> apuimedo, yes
14:23:06 <apuimedo> #info ivc took some more patches out of wip
14:23:37 <apuimedo> Did you get closer to the context less design (didn't get time this morning to check)
14:24:07 <apuimedo> ?
14:24:16 <ivc_> apuimedo, yes, there would be no 'generic' context
14:24:33 <ivc_> at least not in the first batch of patches
14:24:42 <apuimedo> Great
14:25:07 <ivc_> i'll still add a 'network configuration' structure to store pod subnet / service subnet
14:25:12 <apuimedo> As I said earlier, I'll address your comments on my patch later today
14:25:30 <apuimedo> That is okay
14:25:58 <apuimedo> If it's well defined and let's us for both the bare metal and nested, it well be good
14:26:50 <apuimedo> ivc, anything else we should be taking care of on k8s side?
14:27:09 <ivc_> nope
14:28:33 <apuimedo> Alright
14:28:40 <apuimedo> #topic General
14:29:21 <apuimedo> Open discussion
14:29:44 <apuimedo> #chair ivc
14:29:44 <openstack> Warning: Nick not in channel: ivc
14:29:45 <openstack> Current chairs: apuimedo ivc
14:30:12 <apuimedo> #chair ivc_
14:30:12 <openstack> Current chairs: apuimedo ivc ivc_
14:30:28 <lmdaly> apuimedo, any update on driver features for libnetwork? :)
14:30:33 <apuimedo> Please ivc_ finish the meeting, I gotta go
14:31:04 <ivc_> apuimedo, ok
14:32:33 <ivc_> lmdaly, what 'drivers' are we talking about, we now have some in 'kuryr-lib'?
14:33:45 <lmdaly> yes the other part to the kuryr-lib ones so that an ipvlan 'driver' will be in libnetwork for updating the allowed address pairs on the host port
14:36:14 <ivc_> lmdaly, i'm not aware if anyone is working on that now
14:37:44 <lmdaly> ivc_ ah okay