14:01:30 <apuimedo> #startmeeting kuryr
14:01:31 <openstack> Meeting started Mon Sep 19 14:01:30 2016 UTC and is due to finish in 60 minutes.  The chair is apuimedo. Information about MeetBot at http://wiki.debian.org/MeetBot.
14:01:33 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
14:01:35 <openstack> The meeting name has been set to 'kuryr'
14:01:45 <apuimedo> Hello! Who's here for the kuryr meeting?
14:01:50 <vikasc> o/
14:01:53 <limao_> o/
14:01:54 <tonanhngo> o/
14:01:56 <lmdaly> o/
14:02:21 <ivc_> o/
14:03:06 <apuimedo> #info vikasc, limao_, tonanhngo, lmdaly, ivc_ and apuimedo present
14:03:15 <apuimedo> Thank you for joining
14:03:23 <apuimedo> #topic kuryr-lib
14:03:42 <apuimedo> https://wiki.openstack.org/wiki/Meetings/Kuryr#Meeting_September_19th.2C_2016
14:04:02 <apuimedo> #topic kuryr-lib: REST/rpc
14:04:34 <apuimedo> #info vikasc has some patches for it already
14:04:38 <irenab> apuimedo: will partially attend
14:05:02 <apuimedo> lmdaly: I would like to understand if the approach vikasc is pushing works for the PoC you have
14:05:02 <vikasc> apuimedo, https://review.openstack.org/#/c/342624/
14:05:37 <vikasc> apuimedo, this is the first patch toi be reviewd
14:05:43 <vikasc> *to
14:05:44 <janonymous> o/
14:06:24 <apuimedo> welcome janonymous
14:06:34 <apuimedo> #link https://review.openstack.org/#/c/342624/
14:06:40 <pablochacin> o/
14:06:47 <apuimedo> welcome pablochacin
14:07:19 <apuimedo> vikasc: lmdaly: we have to make it in a way that is configurable with both approaches, address/pairs and trunk/subport
14:07:33 <apuimedo> vikasc: did you introduce such a config option already?
14:07:43 <vikasc> apuimedo, not yet
14:08:38 <vikasc> apuimedo, i have introduced, a configuration option to tell if baremetal or nested-containers
14:08:48 <apuimedo> I'm aware
14:08:54 <apuimedo> I think we can merge that one
14:09:13 <vikasc> apuimedo, it is like one more variable applicable with nested-containers
14:09:25 <apuimedo> #action apuimedo to review and possibly merge https://review.openstack.org/362023
14:09:41 <apuimedo> #action vikasc to add a second config patch for selecting the container-in-vm approach
14:10:14 <apuimedo> the same setting should be used for both the host side and the VM side
14:10:15 <vikasc> apuimedo, so to answer your question.. not added yet this new configuration option in nested-containers case.
14:11:09 <apuimedo> very well
14:11:11 <vikasc> apuimedo, by host side you mean on master node?
14:11:12 <apuimedo> we'll get to that
14:11:18 <apuimedo> vikasc: right
14:11:31 <vikasc> apuimedo, yeah..right
14:11:42 <hongbin> o/
14:11:59 <apuimedo> vikasc: possibly we can run more than one master node and have them HAed with corosync-pacemaker
14:12:07 <apuimedo> welcome hongbin
14:12:09 <vikasc> apuimedo, in my current understanding rpc patches will work for ip/macvlan approch as well
14:12:21 <apuimedo> good
14:12:36 <apuimedo> #action apuimedo irenab to review all the rpc patches
14:12:54 <apuimedo> #topic kuryr-lib: specs/devref
14:13:04 <vikasc> apuimedo, i need to rebase rpc patches.. i was updating rest patches only by now
14:13:26 <vikasc> apuimedo, will do
14:13:43 <vikasc> apuimedo, we should review first kuryr-lib repo patches
14:13:46 <apuimedo> #info after going through the mailing list for a week, I think the option that generates the larger consensus is to keep the specs on openstack/kuryr and to put devrefs close to the code, i.e. in the repo where the implementation will go
14:13:57 <apuimedo> vikasc: absolutely
14:14:56 <vikasc> apuimedo, i will understand from you HA scenario offline
14:15:13 <apuimedo> vikasc: sure, we can discuss it later
14:15:17 <apuimedo> #topic kuryr-libnetwork: credential selection
14:15:54 <apuimedo> #info: Keystone v3 support was merged, but Kuryr will still prefer cloud.yaml auth options over kuryr.conf, as it was doing up until now
14:16:04 <apuimedo> banix brought my attention to it
14:16:21 <apuimedo> and we should try reverting that preference in a way that doesn't break fullstack/rally tests.
14:16:53 <banix> apuimedo: how is this done? i mean where is this being done?
14:17:38 <apuimedo> banix: let me link it
14:18:21 <apuimedo> #link https://github.com/openstack/kuryr-libnetwork/blob/master/kuryr_libnetwork/controllers.py#L74-L76
14:18:34 <apuimedo> first it goes to the cloud yaml in line 74
14:18:46 <apuimedo> otherwise it goes to getting it from kuryr.conf in L76
14:18:58 <apuimedo> it's possible that just swapping those lines fixes it
14:19:28 <banix> isee; now i remember; was done for the gate job at the time i think
14:20:01 <banix> will try after the call and let you know; may be can fix it before the release?
14:20:49 <apuimedo> very well
14:20:54 <apuimedo> banix: that would be ideal
14:21:06 <banix> sure
14:21:11 <apuimedo> #action banix to test swapping the lines
14:21:29 <apuimedo> #info there is a new trello board to track work on Kuryr https://trello.com/b/1Ij919E8
14:21:49 <apuimedo> #info committers to kuryr can ping me for being added as members to the trello team
14:22:18 <apuimedo> #topic: kuryr-libnetwork: release
14:22:56 <apuimedo> #info apuimedo sent a patch to get the kuryr-lib requirement in requirements.txt but it was rejected due to global requirements freeze
14:23:15 <apuimedo> #action apuimedo to request an exception. Which should be granted since nobody else depends on it.
14:24:08 <apuimedo> #topic: kuryr-libnetwork: container-in-vm
14:24:23 <apuimedo> well, we covered most of it in the kuryr-lib topic
14:24:39 <apuimedo> vikasc: anything to add that is kuryr-libnetwork specific?
14:25:02 <vikasc> apuimedo, i think thats pretty much all
14:25:07 <apuimedo> very well
14:25:16 <apuimedo> #topic kuryr-libnetwork:general
14:25:37 <apuimedo> #info dongcanye got a patch merged for adding endpoint operation info
14:26:03 <apuimedo> banix: have you tried kuryr with the new swarm?
14:26:20 <banix> won’t work
14:26:29 <apuimedo> :/
14:26:39 <banix> new swarm is tied to Docker Overlay driver
14:26:50 <banix> they say this will be fixed in 1.13
14:26:52 <apuimedo> banix: it can't use any remote/ipam drivers?
14:26:58 <banix> no
14:27:02 <banix> as in 1.12
14:27:02 <vikasc> :D
14:27:06 <apuimedo> good Lord
14:27:10 <apuimedo> that is disappointing
14:27:17 <apuimedo> banix: do you know when 1.13 is coming?
14:27:23 <banix> if you use the new swarm; not sure if you can disable it
14:27:38 <apuimedo> #info Docker 1.12 swarm mode is not compatible with Kuryr, expected to be fixed on 1.13
14:28:08 <banix> not sure; in a couple of months? :)
14:28:28 <vikasc> apuimedo, would it make sense to add this under "limitations"?
14:28:33 <apuimedo> (屮ﾟДﾟ)屮
14:28:42 <banix> i think so
14:28:50 <apuimedo> yes, please
14:28:52 <apuimedo> let's do that
14:28:57 <banix> sure
14:29:11 <apuimedo> #action banix to update *limitations* with the swarm issue
14:29:11 <vikasc> apuimedo, i can do this
14:29:15 <apuimedo> oops
14:29:18 <vikasc> np
14:29:37 <apuimedo> banix: vikasc: whoever feels like doing it. I put banix since he can maybe add the backstory links
14:29:48 <vikasc> sure
14:30:06 <apuimedo> Finally, I want to draw attention to the multitenancy story for kuryr-libnetwork
14:30:29 <apuimedo> banix: do I remember it properly that we do not receive any env var on enpoint joining request?
14:31:03 <apuimedo> but we can on the other hand receive network operation options
14:31:11 <apuimedo> on network commands
14:31:19 <banix> yes
14:31:44 <banix> but the options are limited to network create only if my info is not outdated
14:32:05 <apuimedo> that's what I remember as well
14:32:15 <banix> which may be good enough
14:32:34 <banix> we had done some work around multi tenancy; let me revisit and get back to you all
14:32:38 <apuimedo> banix: what I was thinking was, that when users create the networks, they provide keystone auth info
14:33:10 <apuimedo> and then, when joining a network, we do not check, but match on Docker's network uuid
14:33:27 <apuimedo> we find the network that has the docker network uuid tag
14:33:38 <apuimedo> and create the port there, and bind
14:34:17 <banix> yes thats an option
14:34:21 <apuimedo> banix: please, check that workaround and let us now on #openstack-kuryr ;-)
14:34:25 <apuimedo> moving on
14:34:30 <apuimedo> #topic kubernetes: devstack
14:34:49 <apuimedo> #info apuimedo started WIP patch for kubernetes devstack
14:35:01 <apuimedo> #link https://review.openstack.org/371432
14:35:27 <apuimedo> it consists on running etcd3, kubernetes-api, kubernetes-controller-manager and kubernetes-scheduler all in docker containers
14:35:43 <apuimedo> raven, kubelet and CNI on the bare metal
14:36:05 <apuimedo> I still have some issues with run_process and docker run, but I think I'll be able to solve it soon enough
14:36:27 <apuimedo> after that, we can start having gates when we add new kubernetes integration code
14:36:37 <vikasc> apuimedo, thanks for the great effort!!!
14:36:46 <apuimedo> you're welcome
14:36:55 <devvesa> +1
14:36:58 <apuimedo> any question on the kubernetes devstack?
14:37:03 <apuimedo> devvesa: nice to see you
14:37:17 <devvesa> thanks. I've been late today
14:37:23 <apuimedo> no problem
14:37:30 <apuimedo> you made it in time for your section
14:37:42 <devvesa> So the -1 Workflow on the devstack patch means that it fails?
14:37:46 <apuimedo> yes
14:37:51 <vikasc> why raven in bm?
14:37:55 <apuimedo> it's for me to tell people that I need to fix stuff
14:38:00 <pablochacin> apuimedo: the usual concern about the future of hyperkube
14:38:05 <devvesa> I prefer a WIP on message commit
14:38:12 <apuimedo> vikasc: so that you can edit code while developing and you don't need to regenerate a container for it
14:38:16 <devvesa> because I understood that it was not meant to be merged
14:38:29 <vikasc> apuimedo, cool
14:38:30 <apuimedo> pablochacin: hyperkube doesn't seem to be going away, if it does, though
14:38:50 <apuimedo> we'll use an all in one binary
14:38:55 <devvesa> last time i download the last version released on the hyperkube container (1.3.7)
14:38:58 <apuimedo> I'll set up a job somewhere that compiles it
14:39:01 <apuimedo> and downloads it
14:39:02 <devvesa> so they kind of maintain it
14:39:16 <hongbin> apuimedo: i think you want to make the version of hyperkube configurable
14:39:19 <apuimedo> devvesa: both gcr.io and quay.io are maintaining their own versions of it
14:39:27 <apuimedo> hongbin: I made it configurable ;-)
14:39:41 <apuimedo> https://review.openstack.org/#/c/371432/3/devstack/settings
14:39:50 <apuimedo> the devstack design is
14:40:08 <hongbin> apuimedo: looks good
14:40:10 <apuimedo> you can enable disable each service and point your local.conf to existing services if you have them
14:40:22 <apuimedo> and you can also specify etcd/hyperkube versions and origin
14:40:38 <apuimedo> (in case somebody prefers quay's more than gcr
14:40:40 <apuimedo> for example
14:40:53 <irenab> apuimedo: it requires a bit of documentation, since too many options can be confusing
14:41:02 <apuimedo> irenab: good point
14:41:24 <apuimedo> #action apuimedo to make a local.conf.sample with a lot of comments that explain the options
14:41:28 <irenab> apuimedo: or blog :-)
14:41:32 <vikasc> apuimedo, +1
14:41:46 <apuimedo> irenab: if you can, review the patch reminding me to add that to local.conf.sample
14:41:50 <pablochacin> apuimedo: do you know what magnun project is doing? they also need kubernetes, right?
14:41:54 <irenab> apuimedo: sure
14:42:03 <apuimedo> pablochacin: you have here the best person to answer that
14:42:06 <apuimedo> hongbin: ^^
14:42:12 <pablochacin> :-/
14:42:24 <vikasc> :)
14:42:42 <hongbin> magnum does something similiar (pull docker image for kube components)
14:43:05 <hongbin> kubelet is provided by the os
14:43:07 <apuimedo> Ideally, we should have a container registry in infra
14:43:21 <apuimedo> that can be used for jobs, kolla, official OpenStack containers, etc
14:43:29 <apuimedo> but I think that's not ready yet
14:43:53 <apuimedo> #topic py3 asyncio progress
14:44:00 <apuimedo> devvesa: pablochacin: any news on that front?
14:44:17 <devvesa> apuimedo: the expected ones this week: 0
14:44:30 <banix> by the way, i think we will have kuryr in kole by the next release
14:44:44 <devvesa> sorry but we have been busy in other stuff
14:45:02 <irenab> banix: Kolla?
14:45:06 <apuimedo> devvesa: very well. That's perfectly understandable
14:45:10 <apuimedo> yes
14:45:13 <banix> yes
14:45:25 <apuimedo> I'll put an #info in open discussion about it :-)
14:45:37 <apuimedo> I should have done it in the kuryr-libnetwork topic
14:45:41 <apuimedo> I'm in the moon
14:45:46 <banix> sorry for digression
14:45:52 <apuimedo> #topic kubernetes: py2/3 eventlet
14:46:23 <devvesa> apuimedo: sorry if you already said it, but... any news on the CNI plugin?
14:46:30 <devvesa> s/plugin/driver
14:46:44 <apuimedo> devvesa: nope, finishing devstack first, so I can have it gated
14:46:55 <apuimedo> #info ivc_ pushed a devref that designs a very different approach than the one apuimedo's devref was pushing for
14:46:56 <devvesa> perfectly understandable :)
14:47:06 <apuimedo> We had a videochat discussion (video available on demand)
14:47:35 <banix> link please
14:48:02 <apuimedo> #action devvesa vikasc pablochacin irenab to review https://review.openstack.org/#/c/369105/
14:48:56 <apuimedo> also, ivc_ started implementing one of it's first pieces, the port provider
14:48:57 <ivc_> just a note, https://review.openstack.org/#/c/369105/ is wip and i'm hoping to update it soon with more recent information
14:49:17 <apuimedo> #link https://review.openstack.org/#/c/370284/
14:49:22 <apuimedo> thanks ivc_
14:49:33 <apuimedo> ivc_: any other news?
14:49:44 <ivc_> yup cleaning up other parts
14:50:01 <ivc_> and sort of refactoring the service/endpoints dependencies issue
14:50:13 <apuimedo> ivc_: can't wait to see about that in the devref
14:50:15 <apuimedo> :-)
14:50:29 <ivc_> actually there's no more dependency issue :)
14:50:45 <ivc_> so i'm removing all the junk code related to it now
14:51:26 <ivc_> got it sorted out by applying lbaas pool annotation to endpoints instead of service
14:51:27 <apuimedo> ivc_: now I'm even looking forward to seeing it more
14:51:50 <apuimedo> interesting
14:52:21 <irenab> ivc_: using lbaasV2?
14:52:27 <ivc_> irenab yes
14:52:31 <apuimedo> so until you see endpoint event with annotation, you send it to /dev/null
14:52:35 <irenab> great
14:52:50 <apuimedo> nice idea
14:52:50 <ivc_> apuimedo yup
14:53:12 <apuimedo> ivc_: but it pisses me off. Why didn't I think about doing it like that....
14:53:21 <apuimedo> anyway, let's move on
14:53:24 <ivc_> apuimedo ")
14:53:27 <apuimedo> #topic open discussion
14:54:24 <banix> here are related patches regarding Kuryr integration in Kolla: https://review.openstack.org/#/c/298894/  https://review.openstack.org/#/c/364662/  https://review.openstack.org/#/c/370382/
14:54:58 <apuimedo> #info huikang scored a big buzzer beater for Kuryr getting it inside Kolla's newton release just as the clock was expiring. I can't thank enough all the efforts from huikang, sdake, inc0 and Jeffrey
14:55:20 <banix> +1
14:55:23 <apuimedo> it will be very nice for kuryr-libnetwork development to be able to use kolla instead of devstack :-)
14:55:48 <vikasc> macvlan v/s ipvlan
14:56:11 <apuimedo> #info In order to be on more consumer ready kolla usage, we should have RPM/deb packages and add kolla code to consume those as well
14:56:21 <apuimedo> right
14:56:41 <apuimedo> limao_: vikasc: lmdaly please, explain about the macvlan/ipvlan. I gotta run
14:56:47 <apuimedo> #chair banix
14:56:48 <openstack> Current chairs: apuimedo banix
14:56:58 <apuimedo> banix: please finish the meeting
14:57:03 <banix> k
14:57:09 <irenab> 3 mins left
14:57:30 <apuimedo> #info limao made a very nice document manually testing the ipvlan proposal with macvlan https://lipingmao.github.io/2016/09/18/kuryr_macvlan_ipvlan_datapath_poc.html
14:57:36 <apuimedo> (even using ipam)
14:58:02 <vikasc> Only pro in using ipvlan seems to be the limit on number of virtual interfaces before interface enters promiscous mode
14:58:53 <limao_> ipvlan need more high kernel version
14:58:55 <limao_> http://hicu.be/macvlan-vs-ipvlan
14:59:11 <limao_> a blog about pro and con
14:59:28 <hongbin> yes, i would say the requirement of high kernel version will cause problem
14:59:34 <irenab> limao_: thanks for sharing
14:59:37 <limao_> maybe we can consider support both ipvlan and macvlan
14:59:45 <vikasc> IMO, promiscous mode should not be as major concern as latest kernel requirement
14:59:50 <banix> #info a blog about pro and con : http://hicu.be/macvlan-vs-ipvlan
15:00:07 <lmdaly> I see no issue with the possibility of introducing a macvlan option
15:00:14 <banix> running out of time; should perhaps end now and continue on kuryr channel if need be
15:00:19 <banix> #endmeeting