15:03:26 <apuimedo> #startmeeting kuryr
15:03:26 <openstack> Meeting started Mon Nov 23 15:03:26 2015 UTC and is due to finish in 60 minutes.  The chair is apuimedo. Information about MeetBot at http://wiki.debian.org/MeetBot.
15:03:27 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
15:03:30 <openstack> The meeting name has been set to 'kuryr'
15:03:42 <apuimedo> Hi all and welcome to yet another kuryr meeting
15:03:49 <apuimedo> who's up for the party?
15:03:49 <mestery> o/
15:03:53 <diga> o/
15:03:54 <vikas> o/
15:03:55 <fawadkhaliq> hello!
15:03:55 <banix> apuimedo: no; someone else had done that; I corrected it
15:04:09 <apuimedo> banix: cool, thanks
15:04:16 <apuimedo> let's check what happened later
15:04:19 <apuimedo> irenab: ?
15:04:43 <irenab> apuimedo: hey, sorry just joined
15:04:53 <apuimedo> :-)
15:05:19 <apuimedo> #info mestery diga vikas fawadkhaliq banix, irenab and apuimedo in the meeting
15:05:31 <apuimedo> I guess taku prefers the alternate time :P
15:05:38 <apuimedo> thank you all for joining
15:05:47 <mestery> thanks for running this apuimedo :)
15:06:08 <apuimedo> #info mestery was kind enough to register #openstack-kuryr as a separate channel
15:06:13 <apuimedo> let's hangout there
15:06:15 <mestery> yay!
15:06:21 <apuimedo> when not in meetings
15:06:25 <fawadkhaliq> awesome!
15:06:54 <apuimedo> #topic getting started
15:07:40 <apuimedo> it is clear that it's not very easy to get kuryr up and running for development nor for trying it out
15:07:48 <mestery> heh :)
15:07:56 <apuimedo> last week I was at dockercon demoing kuryr and I managed to do it with devstack
15:08:14 <apuimedo> doing some modifications to gsagie's devstack plugin
15:08:18 <fawadkhaliq> DevStack plugin ftw!
15:08:26 <banix> apuimedo: how was that received? May be can talk about it later
15:08:27 <apuimedo> #action get devstack plugin merged and finished this week
15:08:44 <apuimedo> I already got it working but I'm refinining it
15:09:00 <apuimedo> in principle I change it to make it work without nova, cinder, glance, etc
15:09:06 <apuimedo> what do you guys think?
15:09:22 <apuimedo> I was thinking of making nova and others optional
15:09:32 <fawadkhaliq> For minimal installs, yes, makes sense.
15:09:34 <apuimedo> for when you want to test interaction between VM and containers in networks
15:09:41 <irenab> apuimedo: in a view of our previous discussion, maybe we need to keep nova
15:10:00 <irenab> or at least if Horizon is enabled, have nova enabled as well
15:10:40 <apuimedo> irenab: good point, I'll test it and propose a follow up patch after gsagie's
15:10:58 <irenab> apuimedo: great, thanks
15:10:59 <banix> apuimedo: sounds reasonable; so we shouldprobably have a full flege OS install or the minimal needed for Kuryr: Neutron and Keystone?
15:11:00 <apuimedo> #action apuimedo to make devstack nova inclusion configurable in the sample local.conf
15:11:10 <banix> feldged
15:11:35 <apuimedo> banix: I think ajo will update the vagrant contrib to use the new devstack
15:11:49 <banix> great
15:11:52 <apuimedo> we should also improve the devref
15:12:01 <vikas_> apuimedo: agreed
15:12:08 <apuimedo> #action apuimedo add docker network creation commands to devref
15:12:37 <apuimedo> anything else about getting started issues?
15:14:06 <apuimedo> alright, moving on
15:14:15 <apuimedo> #topic blueprint maintenance
15:14:47 <apuimedo> banix: I approved https://blueprints.launchpad.net/kuryr/+spec/kuryr-config
15:15:02 <apuimedo> banix: you already sent a patch for this that was merged some time ago
15:15:27 <apuimedo> is there more work remaining before we can mark it as "implemented"
15:15:29 <banix> apuimedo: I will upload a final patch to make our script use config files when present shortly
15:15:37 <apuimedo> thanks
15:15:44 <banix> apuimedo: a bit more work to do
15:15:53 <apuimedo> #action banix to finish implementation of https://blueprints.launchpad.net/kuryr/+spec/kuryr-config
15:16:12 <apuimedo> diga: banix: what's the state on https://blueprints.launchpad.net/kuryr/+spec/vif-binding-and-unbinding-mechanism
15:16:46 <banix> diga: please comment
15:17:17 <diga> apuimedo: I am working on this, will submit next patch by
15:17:18 <diga> tomorrow
15:17:44 <diga> but I need to discuss about OVS hybrid binding
15:17:51 <apuimedo> #action diga to submit the ovs binding patch by ~ 2015-11-24
15:17:56 <banix> diga: lets get the basic in first
15:18:11 <banix> we can do the hybrid as a follow on
15:18:11 <diga> okay
15:18:16 <apuimedo> diga: hybrid binding is postponed until we know if mitaka will use conntrack
15:18:24 <diga> okay
15:18:32 <fawadkhaliq> apuimedo: on ovs conntrack
15:18:34 <apuimedo> diga: fawadkhaliq was checking with jlibosva about it IIRC
15:18:47 <diga> apuimedo: okay
15:18:48 <fawadkhaliq> Reached out in the mailing list and Kuba (libosvar) is working on the support. Here's a link to the bug ID with details. As it seems right now, it is expected to land in Mitaka.
15:18:54 <apuimedo> diga: you can find him on #openstack-neutron
15:18:57 <fawadkhaliq> #link https://bugs.launchpad.net/neutron/+bug/1461000
15:18:57 <openstack> Launchpad bug 1461000 in neutron "[rfe] openvswitch based firewall driver" [Wishlist,Triaged] - Assigned to Jakub Libosvar (libosvar)
15:18:57 <banix> apuimedo: we could still have hybrid without ovs conntrack; how we do it wth ovs driver right now
15:19:03 <diga> sure apuimedo
15:19:13 <apuimedo> banix: you mean setting the linux bridges?
15:19:20 <banix> apuimedo: yes
15:19:32 <apuimedo> I'll get ahold of kuba and ask him when he thinks it will be ready in devstack
15:19:36 <apuimedo> *master
15:19:44 <apuimedo> if it's early enough maybe it's not worth it
15:19:54 <apuimedo> banix: otherwise I fully agree
15:19:57 <apuimedo> thanks fawadkhaliq
15:20:21 <banix> apuimedo: agree. the effort for adding hybrid is very minimal; so not a big work item.
15:20:23 <apuimedo> #action check with kuba for an estimation on when we'll have conntrack in master
15:20:27 <apuimedo> true
15:20:32 <fawadkhaliq> banix: +1
15:21:05 <banix> Do we want to have a closer look at the os_vif api?
15:21:23 <apuimedo> banix: you mean the new library thing?
15:21:26 <banix> and see if we can use that rather than going on a different way?
15:21:26 <irenab> banx: I think so
15:21:28 <diga> apuimedo: fawadkhaliq: banix : thanks
15:21:35 <banix> apuimedo: yes
15:21:49 <apuimedo> I guess it's worth a shot
15:22:01 <irenab> I can take a look during the week
15:22:06 <apuimedo> anybody with the link handy?
15:22:10 <fawadkhaliq> yes
15:22:17 <apuimedo> https://review.openstack.org/#/c/193668/5/specs/mitaka/approved/os-vif-library.rst
15:22:20 <apuimedo> right?
15:22:21 <banix> apuimedo: that apimay be in flux but worth have a look and see iif we can use as is
15:22:27 <fawadkhaliq> #link  https://github.com/openstack/os-vif
15:22:35 <fawadkhaliq> its pretty much empty right now
15:22:56 <apuimedo> #action irenab to check re-usability of https://github.com/openstack/os-vif https://review.openstack.org/#/c/193668/5/specs/mitaka/approved/os-vif-library.rst
15:23:19 <apuimedo> it'd be nice if we can re-use it
15:23:29 <irenab> apuimedo: agree
15:23:45 <apuimedo> vikas: irenab: fawadkhaliq: thanks for the discussion at https://blueprints.launchpad.net/kuryr/+spec/external-network-connectivity
15:24:06 <apuimedo> #info some more discussion has been going on at https://blueprints.launchpad.net/kuryr/+spec/external-network-connectivity
15:24:28 <banix> a  bit more on what may be coming here: https://github.com/jaypipes/os_vif
15:24:46 <fawadkhaliq> ah I see. thanks banix
15:24:48 <apuimedo> banix: yes. I expect most of it to make it from there
15:25:06 <apuimedo> #link https://github.com/jaypipes/os_vif
15:25:21 <irenab> banix: I think there was also ethrpad from design summit, need to find it
15:25:22 <apuimedo> as I wrote, I basically agree with fawadkhaliq in that we should not perform the implicit creation
15:25:46 <banix> irenab: yes, linked on the wiki from last week meeting
15:25:47 <apuimedo> only that I think that external connectivity should be optional and we could just log when not configured
15:25:52 <apuimedo> or when not specified
15:25:57 <fawadkhaliq> apuimedo: agree
15:26:07 <apuimedo> and I think that it is something that belongs to a network
15:26:24 <apuimedo> the decision whether to connect to the external router
15:26:59 <apuimedo> anybody with a different view on that?
15:27:23 <irenab> apuimedo: you expect this requirement to be passed via tg?
15:27:29 <banix> apuimedo: the router is an existing router?
15:27:46 <apuimedo> apropos banix, did the network --opt finally make it to the docker 1.9 api?
15:28:01 <banix> apuimedo: yes
15:28:04 <apuimedo> banix: yes. I expect that just like one can set a default pool
15:28:14 <banix> I see
15:28:17 <apuimedo> one could also set a router for external connectivity
15:28:23 <apuimedo> and specify it
15:28:32 <apuimedo> by uuid or by name
15:28:34 <irenab> apuimedo: by talking to neutron directly?
15:28:49 <apuimedo> irenab: yes, this is environment configuration
15:29:29 <irenab> apuimedo: my question is regarding user actions. User uses both neuron and docker API?
15:29:32 <apuimedo> vikas: thoughts?
15:30:03 <apuimedo> I believe setting the external router is something for the admin
15:30:19 <apuimedo> specifying it when creating a network (which is docker api) belongs to the user
15:30:26 <irenab> Seems maybe we need spec for this blueprint, to make sure use case is captured
15:30:47 <apuimedo> I agree with having a spec
15:30:50 <fawadkhaliq> irenab: +1
15:31:11 <apuimedo> banix, vikas, mestery, diga ?
15:31:20 * irenab : sorry, have to go. Will check the log later
15:31:22 <fawadkhaliq> vikas: mentioned he will write a spec once discussion reaches a certain point. I think we are there :-)
15:31:35 <mestery> Seems like a spec would allow for more discussion here
15:31:52 <banix> irenab: agree; the work flow is important here; with —opt we can do whatever but we have to work it through
15:32:17 <banix> +1 yes we need more discussion
15:32:58 <apuimedo> #action vikas to move external connectivity to spec with the assumption of no default action
15:33:24 <apuimedo> that phrasing I just did was not the best :P
15:33:34 <apuimedo> I meant no router creation
15:33:39 <fawadkhaliq> lol
15:34:05 <apuimedo> #topic IPAM
15:34:08 <diga> apuimedo: I think user uses both docker & neutron api, we need more discussion on this thread
15:34:31 <apuimedo> diga: absolutely
15:34:53 <apuimedo> it's one of the great things of kuryr, that it puts the neutron api at the hand of the container user
15:35:07 <apuimedo> however, when the user does not touch it, we should have usable behavior
15:35:21 <diga> I will go through it once again & work with vikas on this
15:35:33 <apuimedo> I think we can close this bp https://blueprints.launchpad.net/kuryr/+spec/ipam
15:35:40 <diga> yep
15:36:16 <apuimedo> the ipam driver changed things enough that it deserves a new spec or bp
15:36:37 <diga> +1
15:36:51 <apuimedo> banix: irenab: mestery: fawadkhaliq: ^^
15:36:56 <fawadkhaliq> :-)
15:37:02 <banix> apuimedo: +1
15:37:06 <fawadkhaliq> +!
15:37:08 <fawadkhaliq> +1
15:37:09 <mestery> +1
15:37:14 <apuimedo> I liked the +!
15:37:18 <apuimedo> it's more assertive :P
15:37:30 <banix> yeah an excited +1!
15:37:32 <mestery> rofl
15:37:36 <fawadkhaliq> LOL
15:38:10 <apuimedo> there, obsoleted
15:39:28 <vikas> sorry folks, had some connectivity issue
15:39:40 <apuimedo> #action vikas tfukushima to work on the ipam as a spec or new bp
15:40:00 <apuimedo> vikas: any news about the ipam driver?
15:40:41 <vikas> apuimedo: ipam driver is ready rom design/approach perspective.This week i will be completing along with unit tests.
15:40:58 <apuimedo> vikas: great news!
15:41:07 <apuimedo> looking forward to review :P
15:41:17 <vikas> apuimedo: sure :)
15:41:34 <apuimedo> on a related topic
15:42:01 <vikas> apuimedo: https://review.openstack.org/#/c/248042/
15:42:09 <apuimedo> https://review.openstack.org/#/c/241134/
15:43:00 <apuimedo> I'd really like to get this merged, either as is, or removing the dhcp option for now and adding it only when we have the ipam driver ready
15:43:12 <fawadkhaliq> #link https://review.openstack.org/#/c/248042/
15:43:17 <apuimedo> as I feel this can be blocking people right now when using devstack with docker 1.9
15:43:29 <fawadkhaliq> apuimedo: +1
15:43:52 <apuimedo> vikas: oh, not ready for merge, but for code review... I'll definitely take a look :P
15:44:16 <banix> sounds reasonable
15:44:47 <apuimedo> I don't really mind one way or another banix, irenab, vikas
15:44:58 <apuimedo> I think fawadkhaliq feels the same way about it
15:45:07 <fawadkhaliq> exactly
15:45:21 <fawadkhaliq> since this a stop gap solution, I am okay with it.
15:45:29 <apuimedo> yup
15:45:29 <banix> apuimedo: well this can be just a stop-gap measure; it looks (and is) something not to do but i think we all agree on that
15:47:00 <apuimedo> #action irenab, tfukushima and banix to review https://review.openstack.org/#/c/241134/ and either make it change to disabled-not-configurable or approve
15:47:04 <apuimedo> :-)
15:47:15 <fawadkhaliq> apuimedo: +1
15:47:17 <apuimedo> #topic open floor
15:47:30 <apuimedo> Alright, we covered some ground today :-)
15:47:35 <apuimedo> who has more topics?
15:47:45 <banix> apuimedo: can you tell us a bit about how Kuryr was received at dockercon eu
15:47:53 <apuimedo> oh sure!
15:48:05 <fawadkhaliq> banix: +1
15:48:11 <apuimedo> there's two kinds of people in the audience
15:48:24 <apuimedo> those that run docker at home or in small environments for development
15:48:26 <banix> good ones, and bad ones!
15:48:28 <fawadkhaliq> good news and bad news kind of stuff? :-)
15:48:30 <apuimedo> those didn't see the point
15:48:46 <apuimedo> the people operating and with users liked the approach a lot
15:49:02 <mestery> cool!
15:49:08 <apuimedo> there was more than one that loved the idea of having OSt and containers in the same environment as well
15:49:24 <mestery> apuimedo: Even better :)
15:49:31 <fawadkhaliq> very nice!
15:49:33 <apuimedo> I think the isolation and api for routing, sg, fwaas, etc is really important
15:49:38 <apuimedo> alongside multi tenancy
15:49:55 <banix> yes indeed. cool.
15:49:58 <apuimedo> it sets kuryr apart from other container networking IMHO
15:50:05 <mestery> ++
15:50:18 <vikas> cool :)
15:50:19 <apuimedo> and more importantly
15:50:23 <apuimedo> the food was good
15:50:28 <apuimedo> :-)
15:50:34 <vikas> :D
15:50:34 <fawadkhaliq> ah the most important thing
15:50:36 <apuimedo> I was completely stuffed
15:50:53 <fawadkhaliq> :-)
15:51:01 <apuimedo> but, as I was saying in #openstack-kuryr earlier
15:51:16 <fawadkhaliq> thanks apuimedo mestery for setting this up!
15:51:19 <banix> agree; docker itself maybe going toward doing some of this but I think we still have a good value to add
15:51:21 <apuimedo> we need to work with kubernetes, mesos, swarm to interoperate
15:51:23 <fawadkhaliq> already on it!
15:51:35 <mestery> :)
15:51:37 <apuimedo> swarm should just work
15:51:44 <apuimedo> so somebody should just try it :P
15:51:52 <ttx> So it looks like there is an issue with the meeting schedule
15:51:56 <apuimedo> kubernetes is working on adding multitenancy
15:52:02 <banix> apuimedo: would be doing a demo with swarm hopefully very soon
15:52:05 <apuimedo> and we may be able to reuse cni
15:52:10 <fawadkhaliq> banix: nice!
15:52:17 <apuimedo> banix: great!
15:52:23 <apuimedo> make a video
15:52:30 <apuimedo> and put it on planet openstack ;-)
15:52:33 <banix> apuimedo: will do
15:52:37 <ttx> apuimedo: the ICS shows you at 0300 UTC tomorrow
15:52:41 <fawadkhaliq> apuimedo: for the times when demo fails? ;-)
15:52:54 <apuimedo> fawadkhaliq: you have to use the source, Luke
15:52:59 <fawadkhaliq> :D
15:53:06 <apuimedo> ttx: it seems we screwed up the time change
15:53:11 <apuimedo> that's our alternating time
15:53:15 <banix> ttx: the updated version got merged last week
15:53:19 <apuimedo> that was last week
15:53:31 <banix> ttx: we have themeetings on alternate days/times
15:54:00 <ttx> apuimedo: ok -- so should we alternate odd/even on the repository ?
15:54:06 <apuimedo> so yeah, we have to look at CNI and mesos ipam and isolators and make a bp
15:54:08 <ttx> or will you just have the meetign at the same hour next week ?
15:54:25 <banix> ttx: at some point someone (that I do not know) made the change on git to use only our 2nd time slot; probably then you picked up our current time slot
15:54:26 <apuimedo> ttx: next week is the 03:00 utc
15:54:31 <vikas> apuimedo: aure
15:54:37 <vikas> *sure
15:54:41 <banix> ttx: ours should be already reflected in the repo as odd/even
15:54:42 <apuimedo> :-)
15:55:02 <apuimedo> I'm going to try to look into it this week
15:55:18 <apuimedo> Any other topic?
15:55:26 <apuimedo> (5min remaining)
15:55:27 <ttx> banix, apuimedo: yeah, probably need to switch between odd and even
15:55:46 <apuimedo> #info kuryr was demoed from devstack at dockercon eu with routers, sg, etc
15:56:10 <banix> ttx: https://review.openstack.org/#/c/245868/
15:56:33 <banix> apuimedo: cool
15:56:39 <banix> the sessions were recorded?
15:56:48 <banix> apuimedo: do you have a link?
15:58:26 <apuimedo> meh... It seems the snow took my connection down for a moment
15:58:36 <apuimedo> did I miss something?
15:58:42 <fawadkhaliq> back just in time
15:58:43 <apuimedo> otherwise...
15:58:45 <ttx> banix: yes, this week is an even week, so this needs an additional change
15:58:59 <apuimedo> finishing in 3
15:59:02 <apuimedo> finishing in 2
15:59:05 <apuimedo> finishing in 1
15:59:06 <banix> ttx: ok will update
15:59:18 <apuimedo> #endmeeting