14:01:00 <apuimedo> #startmeeting kuryr
14:01:01 <openstack> Meeting started Mon Jan  2 14:01:00 2017 UTC and is due to finish in 60 minutes.  The chair is apuimedo. Information about MeetBot at http://wiki.debian.org/MeetBot.
14:01:02 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
14:01:04 <openstack> The meeting name has been set to 'kuryr'
14:01:13 <apuimedo> Hi and welcome everybody to the first 2017 Kuryr meeting
14:01:27 <apuimedo> Sorry for the lack of announcement of there not being meeting last week
14:01:34 <apuimedo> who's here for the meeting?
14:01:40 <irenab> hi
14:01:52 <vikas_> o/
14:02:54 <apuimedo> it seems it's a cores only meeting today :-0
14:03:00 <apuimedo> holidays hit hard :-)
14:03:01 <irenab> :-)
14:03:08 <apuimedo> alright then
14:03:12 <apuimedo> #topic kuryr-lib
14:04:27 <apuimedo> #info We should to cut a new kuryr release due to https://review.openstack.org/#/c/414766/ which is needed by https://review.openstack.org/#/c/410403/
14:04:48 <apuimedo> vikas_: irenab: any objection about sending a request for a new release?
14:05:04 <apuimedo> It should not affect kuryr-libnetwork nor kuryr-kubernetes
14:05:06 <irenab> no objection
14:05:16 <vikas_> apuimedo, no objection
14:05:19 <apuimedo> very well
14:05:46 <apuimedo> #action apuimedo to send a request for a new kuryr-lib release so fuxi can re-use kuryr-lib's keystonauth code
14:05:57 <apuimedo> anything else on kuryr-lib?
14:06:31 <vikas_> master pyroute2 for setting ns fd url?
14:06:58 <vikas_> apuimedo, raisng upper-constraints
14:07:10 <apuimedo> I was going to tackle that on kuryr-kubernetes, but let's take it here
14:07:12 <apuimedo> :-)
14:07:21 <vikas_> not sure if this is the correct section to bring that up
14:07:29 <apuimedo> #info apuimedo sent an email to svinota about cutting a new release of pyroute2
14:07:49 <irenab> vikas_: wha tis the issue you are talking about?
14:07:50 <apuimedo> #action apuimedo to raise pyroute2 upper-constraints once pyroute2 has a new release
14:08:01 <apuimedo> irenab: sorry. I should have put the context
14:08:04 <apuimedo> just a sec
14:08:29 <apuimedo> #link https://github.com/svinota/pyroute2/issues/317
14:08:33 <vikas_> irenab, in latest pyroute2 release it does not allow to set ns fd if it is provided in url form
14:09:06 <vikas_> irenab,  https://github.com/svinota/pyroute2/commit/85cbcd7ca188c2779436450e7ab9aed24d2ce0a3
14:09:09 <apuimedo> all the commits in the issue are related to fixing the namespace handling as needed for kuryr-kubernetes and nested
14:09:13 <vikas_> irenab, this is the fix
14:09:24 <apuimedo> vikas_: that is the main patch, but he also tweaked some timeouts
14:09:27 <irenab> so its actually to skip certain version
14:10:04 <irenab> I just think we should be careful when raising the upper constrains to new releases
14:10:28 <apuimedo> irenab: it's about getting a bug fix
14:10:40 <apuimedo> it's gonna be a bugfix release, not a 5.x
14:10:53 <irenab> apuimedo: ok, got it
14:10:57 <apuimedo> ;-)
14:11:02 <apuimedo> #topic kuryr-libnetwork
14:12:15 <apuimedo> #info mostly cleanups and fixes these past two weeks on kuryr-libnetwork
14:12:53 <apuimedo> #action apuimedo to review https://review.openstack.org/#/c/414659/ and https://review.openstack.org/#/c/415363/
14:13:29 <apuimedo> #action ltomasbo to rebase and rework https://review.openstack.org/#/c/402462/
14:13:47 <apuimedo> After that patch we should already support container-in-vm in master :-)
14:13:53 <apuimedo> Anything else on kuryr-libnetwork?
14:14:03 <irenab> yes
14:14:29 <irenab> apuimedo: do we have devtack reated patch for setting up the environment and some HOWTO?
14:14:43 <irenab> for the nested containers
14:15:31 <vikas_> irenab, nope
14:15:38 <apuimedo> no. We should, as I suggested to vikasc for kuryr-kubernetes, have it included in either the user docs or in the readme
14:16:00 <vikas_> apuimedo, +1, i am going to do that for kuryr-k8s
14:16:07 <irenab> vikas_: please consider to add it, so we can try it out
14:16:12 <apuimedo> #action ltomasbo to add documentation about simple deployment and exercising the container-in-vm code in kuryr-libnetwork
14:16:19 <apuimedo> thanks vikas_
14:16:22 <vikas_> irenab, definitely
14:16:24 <irenab> thanks
14:16:28 <apuimedo> #topic kuryr-kubernetes
14:17:08 <irenab> I plan to push an augment to the devref to cover for services part
14:17:14 <apuimedo> #action vikasc to add documentation about simple deployment and exercising the container-in-vm code in kuryr-kubernetes patch https://review.openstack.org/#/c/410578/
14:17:24 <apuimedo> irenab: that's great!
14:17:35 <apuimedo> I will push today the code I did last week
14:17:55 <irenab> apuimedo: tests?
14:17:56 <apuimedo> it adds some C code for generating a container without requiring internet connectivity for kuryr-kubernetes tests
14:18:23 <irenab> apuimedo: sounds great
14:18:33 <vikas_> interesting!
14:18:39 <apuimedo> then I'll add (though needs a bit more work) a helper I've been working on for the fullstack gates
14:18:50 <apuimedo> #info we added a voting devstack installation gate
14:19:20 <irenab> apuimedo: ovs hybrid?
14:19:28 <apuimedo> irenab: I suggest you add a gate that does the same for dragonflow+kuryr-kubernetes
14:19:45 <apuimedo> irenab: yes
14:19:54 <irenab> apuimedo: I will check if we should add it in df or kuryr-k8s
14:19:59 <irenab> what do you suggest?
14:20:16 <apuimedo> irenab: my impression is that as long as all the components are open source, we can probably have multiple installation gates in kuryr-kubernetes
14:20:41 <irenab> apuimedo: ok, will check it
14:20:42 <apuimedo> although I suggest you to have the job also in dragonflow, so that we check both that we don't break for dragonflow and dragonflow doesn't break for us
14:21:00 <irenab> apuimedo: I do not think kuryr can break DF
14:21:05 <vikas_> apuimedo, +1 on multiple installation gates
14:21:13 <irenab> unless we do something terribly wrong
14:21:44 <apuimedo> irenab: we could be tempted to use something that is not standard but ovs ref impl. specific
14:21:47 <apuimedo> that's the only reason
14:21:55 <apuimedo> but hopefully we'd catch that in review anyway :P
14:21:58 <irenab> apuimedo: ok
14:22:22 <irenab> apuimedo: do you have the patch for adding the gate for ref implementation?
14:22:30 <apuimedo> sure
14:22:36 <apuimedo> let me get it for you
14:23:28 <apuimedo> #link https://review.openstack.org/#/c/404191/
14:23:36 <apuimedo> #link https://review.openstack.org/#/c/413715/
14:23:40 <apuimedo> irenab: ^^
14:23:43 <apuimedo> these both
14:23:52 <apuimedo> you'd need two patches as well I think
14:23:55 <irenab> apuimedo: thanks!
14:24:06 <apuimedo> #info vikasc submitted a patch for container-in-vm!
14:24:19 <apuimedo> It's all starting to come together :-)
14:24:51 <apuimedo> we'll probably want to make some resource usage use drivers instead, but it's good to get it in
14:25:05 <apuimedo> the top priority right now is the functionality tests
14:25:18 <apuimedo> though
14:25:18 <apuimedo> so that's on me
14:25:32 <irenab> apuimedo: services code is WIP, so this one is also in priority
14:26:07 <apuimedo> irenab: yes. But ivc_ is on PTO, so we're waiting for him to do the split when he comes back :-)
14:26:20 <irenab> once I push the devref , I think we may get more peopel to contribute
14:26:23 <vikas_> apuimedo,sorry, i could not get your comment regarding "worker_nodes_subnet" variable. I asked my query there on the patch
14:26:33 <apuimedo> irenab: the other thing that I have on my list is the file based /run binding info for the deletion flow
14:26:44 <apuimedo> vikas_: ok, I'll answer it there
14:26:50 <vikas_> thanks
14:27:07 <apuimedo> anything else on kuryr-kubernetes?
14:27:14 <irenab> apuimedo: maybe we can report each item, also the config change, as bugs so if someone wants to pick it, he will be able to
14:27:26 <irenab> he/she
14:27:27 <apuimedo> (this is shaping up to be a record fast meeting)
14:27:37 <apuimedo> irenab: that's a good point
14:27:43 <vikas_> irenab, +1
14:28:14 <apuimedo> irenab: do we send an email to the ML with the items to pick up? We could draw from the etherpad
14:28:31 <irenab> apuimedo: if you won’t get to it, ping me, will do it tomorrow morning
14:29:15 <apuimedo> irenab: very well. Tomorrow I'll work weird hours, but if you are available at 7utc I can ping with you to discuss this and other things :-)
14:29:15 <irenab> apuimedo: I think eather to manage from the launchpad, but open to etherpad option as well
14:29:30 <apuimedo> irenab: we're moving away from launchpad
14:29:35 <apuimedo> there's that... How is it called
14:29:35 <irenab> apuimedo: 7 utc is mine 10:00?
14:29:40 <apuimedo> stories or something
14:29:50 <apuimedo> 9 IT
14:29:56 <irenab> apuimedo: wors for me
14:30:00 <irenab> works
14:30:00 <apuimedo> cool
14:30:12 <apuimedo> irenab: did you hear about these stories thing?
14:30:18 <irenab> nope
14:30:25 <irenab> not in this context :-)
14:30:45 <apuimedo> storyboard
14:31:10 <irenab> it was raised few releases ago, so now actually moving to it?
14:31:13 <apuimedo> https://wiki.openstack.org/wiki/StoryBoard
14:31:23 <apuimedo> I have to check
14:31:51 <apuimedo> before we start using launchpad, I want to make sure we will not have to put all in launchpad and then manually migrate. If storyboard is ready, we can probably start with that
14:32:14 <irenab> apuimedo: the tool is not that important, lets use what will work for us
14:32:50 <apuimedo> irenab: TC allowing :P
14:32:52 <vikas_> looks like trlloboard
14:32:59 <apuimedo> #link https://storyboard.openstack.org/#!/page/about
14:33:07 <apuimedo> #topic open discussion
14:33:20 <apuimedo> Alright! Anything else in general?
14:33:36 <irenab> just wishes for a good new year :-)
14:34:00 <vikas_> Happy new year to all!!
14:34:08 <apuimedo> indeed
14:34:09 <vikas_> :)
14:34:14 <apuimedo> Happy new year to you all!
14:34:34 <apuimedo> and thanks for joining today!
14:34:38 <apuimedo> #endmeeting