03:00:27 <tfukushima> #startmeeting kuryr
03:00:28 <openstack> Meeting started Tue Dec  1 03:00:27 2015 UTC and is due to finish in 60 minutes.  The chair is tfukushima. Information about MeetBot at http://wiki.debian.org/MeetBot.
03:00:29 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
03:00:31 <openstack> The meeting name has been set to 'kuryr'
03:01:21 <tfukushima> Hello, I'm expecting fewer attendees but who's up for the Kuryr meeting?
03:01:37 <fawadkhaliq> o/
03:01:42 <fawadkhaliq> hi tfukushima
03:01:43 <tfukushima> I hope I wan not the only person.
03:01:52 <fawadkhaliq> We are two for sure :-)
03:02:05 <tfukushima> fawadkhaliq: Here you are.
03:02:56 <tfukushima> https://wiki.openstack.org/wiki/Meetings/Kuryr#Meeting_November_30_.28December_1.29.2C_2015
03:03:35 <tfukushima> This is the agenda for today. Sorry for my disorganised management but I'll try my best.
03:03:47 <fawadkhaliq> looks like it's just two of us today
03:03:54 <vikasc> hi folks
03:03:56 <fawadkhaliq> ah
03:04:00 <fawadkhaliq> vikasc:  is here!
03:04:03 <tfukushima> Hi vikasc
03:04:03 <fawadkhaliq> hi vikasc
03:04:12 <vikasc> hi fawadkhaliq tfukushima
03:04:14 <baohua> hi im here
03:04:19 <vikasc> sorry for being late
03:04:25 <tfukushima> Hi baohua
03:04:37 <baohua> hi taku. thought it was the kuryr channel
03:05:21 <tfukushima> It's supposed to be here according to the wiki.
03:05:59 <tfukushima> Ok, anyways let's get started.
03:06:05 <baohua> sure
03:06:09 <vikasc> sure
03:06:22 <tfukushima> #topic General Action Items (from last week meeting)
03:06:49 <tfukushima> "apuimedo add docker network creation commands to devref"
03:07:27 <tfukushima> I think Toni is working on that. And I'm also investigating if it's possible to associate the existing networks.
03:07:51 <tfukushima> --opt or -o just works and we can give whatever we want.
03:07:59 <fawadkhaliq> nice!
03:08:11 <vikasc> tfukushima, can you please give example
03:08:32 <vikasc> can we tell ext-router name using --opt?
03:08:34 <tfukushima> vagrant@devstack:~/devstack$ sudo docker network create --driver=kuryr  --subnet 10.0.0.0/16 --gateway 10.0.0.1 -o foo=bar baz
03:08:44 <tfukushima> gives:
03:08:46 <tfukushima> {u'NetworkID': u'887a176e91e9c3b7484a38feea5aa032c3f052df74c1bd0727da7475e383daff', u'IPv4Data': [{u'Pool': u'10.0.0.0/24', u'Gateway': u'10.0.0.2/24', u'AddressSpace': u''}], u'IPv6Data': [], u'Options': {u'com.docker.network.generic': {u'foo': u'bar'}}}
03:08:56 <fawadkhaliq> vikasc: I think its a key/value pair so anything I guess
03:09:21 <tfukushima> We can pass multiple options with multiple -o.
03:09:21 <vikasc> fawadkhaliq, just want to confirm with tfukushima
03:09:51 <vikasc> tfukushima, cool
03:10:11 <tfukushima> e.g., -o foo=bar -o baz=qux
03:10:36 <tfukushima> But it works only for the networks.
03:10:37 <vikasc> tfukushima, got it
03:10:44 <vikasc> tfukushima, ahh
03:11:14 <tfukushima> I couldn't find the way to pass options for /NetworkDriver.CreateEndpoints  and /NetworkDriver.Join.
03:11:16 <vikasc> tfukushima, for external connectivity we can use this i guess
03:11:27 <tfukushima> Yes.
03:11:52 <tfukushima> vikas: ext-router They have -l or --label but they're for containers and they are not passed to the remote network driver.
03:12:30 <tfukushima> And we still need to figure out how we can map the Docker's NetworkID and Neutron's UUID.
03:12:50 <vikasc> tfukushima, hmm
03:13:40 <tfukushima> We could pass the name or the UUID of the networks like -o name=foo -o id=2eda7666-c0ed-40b1-8747-25e26c74b364 and retrieve the correspond networks from Neutron.
03:14:00 <baohua> and where to store the mapping info?
03:14:18 <baohua> both kuryr and neutron should be aware, i guess
03:14:19 <tfukushima> But we were storing Docker's NetworkID in the name of the Neutron networks and that was the mapping exactly.
03:14:47 <tfukushima> So we really need the tag feature Gal is proposing, I guess.
03:14:50 <fawadkhaliq> tfukushima: is the idea to somehow make UUIDs in both the worlds the same?
03:15:27 <baohua> if container supports utilizing the exixting uuid instead of creation, then we can make both the same.
03:15:43 <fawadkhaliq> that might require flexibility in libnetwork or in Neutron.
03:16:30 <tfukushima> fawadkhaliq: Actually Docker's "UUID" is not the legitimate UUID. It's a totally different representation from the regular one.
03:17:12 <tfukushima> I'd call it Docker's ID rather than "UUID".
03:17:23 <tfukushima> So they can't be the same.
03:17:24 <vikasc> tfukushima, +1
03:18:05 <tfukushima> UUID: 2eda7666-c0ed-40b1-8747-25e26c74b364, Docker's ID: 286eddb51ebca09339cb17aaec05e48ffe60659ced6f3fc41b020b0eb506d364
03:18:14 <fawadkhaliq> tfukushima: makes sense
03:18:35 <tfukushima> #link Neutron tag spec https://review.openstack.org/#/c/216021/
03:18:54 <baohua> does libnetwork have a id for its network entry?
03:19:12 <fawadkhaliq> thanks for the link
03:19:18 <fawadkhaliq> tags might work
03:19:32 <vikasc> tfukushima, thanks for the link
03:19:35 <tfukushima> Yes it does and they're passed in the requests.
03:19:59 <tfukushima> baohua: But another problem is libnetwork doesn't pass the name of the network.
03:20:41 <fawadkhaliq> tfukushima: not yet :-) we could perhaps propose it to be passed along to the remote driver routines?
03:20:43 <baohua> hmm, so could we push libnetwork for a update?
03:20:54 <tfukushima> So if you want to make the name of the network synced between Neutron and libnetwok, we need to pass the duplicated name -o name=foo.
03:21:22 <vikasc> tfukushima, nice idea
03:21:29 <fawadkhaliq> tfukushima: -o name=foo seems like a workaround to a limitation in the information available
03:21:29 <baohua> it works haha
03:23:10 <tfukushima> But what if there're multiple networks with the same name?
03:23:33 <fawadkhaliq> that's fine, name can be same.
03:23:51 <baohua> i think we use id for lookup
03:23:53 <vikasc> this is possible in neutron only i guess and not in libnetwork
03:24:43 <vikasc> baohua,  makes sense
03:25:14 <tfukushima> baohua: You mean the Docker's network ID?
03:25:52 <fawadkhaliq> so given gsagie's proposal on tags is approved, we could just use that to store the docker network ID and name from libnetwork maps to name in Neutron
03:26:02 <vikasc> tfukushima, in docker network names are unique only i think
03:26:23 <baohua> the assumption is if we can use kuryr to make same network id in both libnetwork and neutron. i think name is only for human read.
03:26:55 <baohua> so we may use different names
03:27:43 <tfukushima> We don't have the field where we can store Docker's network ID. That's why I told we needed Gal's tag proposal.
03:27:57 <fawadkhaliq> baohua: I am assuming you are referring to same network ID using the tagging mechanism gasgie proposed, right?
03:28:03 <tfukushima> If we use Neutron only through Kuryr, that's Ok.
03:28:07 <fawadkhaliq> tfukushima:  +1
03:28:18 <fawadkhaliq> and good point tfukushima
03:28:23 <fawadkhaliq> this only works with Neutron.
03:28:27 <baohua> yes
03:29:25 <tfukushima> Ok, anyways we need more discussion with the detailed doc. I'll come up with some soon.
03:29:44 <fawadkhaliq> my concern with -o approach for name is that user/client could pass different name in -o name=foo than the actual name in libnetwork and then that's an interesting situation.
03:29:50 <fawadkhaliq> tfukushima: +1
03:30:13 <baohua> yes, it seems only a workaround
03:31:41 <tfukushima> We need to figure out the better way. But it'd be the starting point.
03:32:08 <baohua> sure
03:32:14 <fawadkhaliq> tfukushima: agree
03:32:17 <tfukushima> Actually I'm not sure when the tag feature would be implemented.
03:32:30 <tfukushima> This could be a long way.
03:33:01 <tfukushima> So let's go to the next subtopic.
03:33:08 <vikasc> sure
03:33:45 <tfukushima> #action tfukushima and apuimedo write the spec for reusing the existing network.
03:34:02 <tfukushima> "banix to finish implementation of https://blueprints.launchpad.net/kuryr/+spec/kuryr-config"
03:34:37 <tfukushima> banix told me he was working on it and he would finish it this week.
03:34:44 <tfukushima> #link banix's config patch https://review.openstack.org/#/c/251532/
03:35:18 <tfukushima> I'll add you to reviewers.
03:35:42 <tfukushima> #info Please add reviewers when you submitted patches.
03:35:43 <vikasc> will review
03:35:49 <fawadkhaliq> thanks, I will review
03:35:54 <baohua> will review
03:36:08 <tfukushima> "check with kuba for an estimation on when we'll have conntrack in master"
03:36:40 <tfukushima> Does anyone know about it? I'm not familiar with the topic honestly.
03:36:45 <fawadkhaliq> yes
03:36:52 <fawadkhaliq> #link https://bugs.launchpad.net/neutron/+bug/1461000
03:36:52 <openstack> Launchpad bug 1461000 in neutron "[rfe] openvswitch based firewall driver" [Wishlist,Triaged] - Assigned to Jakub Libosvar (libosvar)
03:36:59 <fawadkhaliq> #link https://review.openstack.org/249337
03:37:13 <fawadkhaliq> its a WIP
03:37:21 <fawadkhaliq> but recently updated
03:37:26 <tfukushima> Good.
03:38:08 <vikasc> fawadkhaliq, why we are interested in this?
03:38:16 <vikasc> or how is it related to us
03:38:35 <fawadkhaliq> to not need to worry about hybrid networking model with linux bridges and OVS
03:38:46 <fawadkhaliq> for vif binding
03:38:51 <vikasc> okk
03:38:57 <vikasc> got i
03:38:59 <vikasc> got it
03:39:08 <vikasc> fawadkhaliq, thanks
03:39:43 <tfukushima> Any other updates on that subtopic?
03:40:05 <fawadkhaliq> nope, that seems like it.
03:40:13 <tfukushima> Ok.
03:40:21 <tfukushima> "irenab, tfukushima and banix to review https://review.openstack.org/#/c/241134/ and either make it change to disabled-not-configurable or approve"
03:40:39 <fawadkhaliq> merged! :-)
03:40:41 <tfukushima> The patch was merged already. Thanks vikasc.
03:40:54 <vikasc> tfukushima, thanks :)
03:41:08 <tfukushima> Ok, let's move the next topic.
03:41:18 <tfukushima> #topic Binding (Plug/Inplug)
03:41:44 <tfukushima> "diga to submit the ovs binding patch by ~ 2015-11-24"
03:41:50 <tfukushima> "Since no progress has been made and this work item is blocking other efforts, banix will upload a patch shortly"
03:42:04 <tfukushima> So banix told me he would take care of it and submit his patch.
03:42:22 <vikasc> i will be back in 5 mins
03:42:40 <tfukushima> "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"
03:42:58 <tfukushima> She's still working on it, I guess.
03:43:26 <tfukushima> #topic Devstack
03:44:05 <vikasc> hi
03:44:09 <tfukushima> So some devstack patches were merged and we have another one for the OpenStack CI.
03:44:13 <vikasc> dont know what i missed
03:44:37 <fawadkhaliq> vikasc: not much ;)
03:44:42 <tfukushima> #link devstack with Kuryr for the CI https://review.openstack.org/#/c/250604/
03:44:45 <vikasc> great :)
03:45:15 <tfukushima> #link Gal's devstack patch merged https://review.openstack.org/#/c/242838/
03:45:22 <fawadkhaliq> thanks, just reviewed
03:45:46 <tfukushima> #link Gal's fix for that https://review.openstack.org/#/c/250610/
03:46:08 <tfukushima> So I think we have the devstack env out of the box.
03:46:30 <tfukushima> Thanks Gal, vikasc for the vagrant work.
03:46:49 <tfukushima> #topic IPAM
03:46:50 <vikasc> tfukushima, my pleasure :)
03:47:20 <tfukushima> vikasc: Could you give us your updates on this topic?
03:48:19 <vikasc> ipam driver is almost complete except addressing few review comments.
03:48:30 <tfukushima> #link Vikas' IPAM patch https://review.openstack.org/#/c/248042/
03:49:03 <vikasc> one imp point is whether we should run this as single process with network driver or seperate
03:49:05 <tfukushima> #link A patch for /IpamDriver.ReleaseAddress https://review.openstack.org/#/c/251251/
03:50:15 <vikasc> Few changes are also needed in CreateEndpoint like removing subnet creation part and fetching port created by IpamDriverRequestAddress, that i will be completing shortly
03:51:17 <vikasc> https://bugs.launchpad.net/kuryr/+bug/1521111
03:51:17 <openstack> Launchpad bug 1521111 in kuryr "Add logic in /NetworkDriver.CreateEndpoint to use ipam created port" [Undecided,In progress] - Assigned to vikas choudhary (choudharyvikas16)
03:51:17 <tfukushima> I prefer to put the network driver and the IPAM driver together in the same process because it's simpler. We'd eventually make Kuryr containerised and it'd be easier in my opinion.
03:52:03 <tfukushima> vikasc: In that case /NetworkDriver.CreateEndpoint and /NetworkDriver.DeleteEndpoint would be almost empty but am I understanding correctly?
03:52:47 <vikasc> createendpoint will have logic to fetch port created by Ipam
03:53:17 <vikasc> and in case built-in ipam is used port will be created also
03:53:53 <tfukushima> vikasc: And does it associate with the given EndpointID?
03:54:10 <vikasc> in ipam there is no endpoint id info
03:54:28 <vikasc> but createendpoint wil update port with endpoint id
03:54:36 <tfukushima> I see.
03:54:53 <tfukushima> I need to take a look at your patch deeper.
03:55:10 <vikasc> i will appreciate that
03:55:17 <tfukushima> Ok, we have 5mins left. Let's move on.
03:55:21 <tfukushima> #topic External Network Connectivity
03:55:34 <vikasc> this createendpoint related changes i will push today or by tommorrow
03:55:36 <tfukushima> The last topic.
03:55:47 <tfukushima> Ok.
03:56:27 <tfukushima> As I told in the beginning we can pass anything with -o. So this would make it easier to implement this external network connectivity.
03:56:44 <vikasc> tfukushima, true
03:57:01 <tfukushima> vikasc: Any other updates?
03:57:17 <vikasc> nothing else from my side
03:57:25 <vikasc> one thing
03:57:49 <vikasc> are we looking at kubernetees and magnum networking also
03:58:14 <vikasc> should we be more attentive on these?
03:58:28 <baohua> i think neither has specific networking backend.
03:58:47 <tfukushima> Yes we're.
03:58:47 <baohua> they leverage existing mechanisms
03:59:01 <vikasc> but do we need some extra effort to support these on top of supporting plain docker
03:59:14 <fawadkhaliq> vikasc: we might have to
03:59:32 <tfukushima> Ok, we're running our time out.
03:59:35 <baohua> sure, there should be some
03:59:35 <tfukushima> #info tfukushima, fawadkhaliq, vikasc, baohua is in the meeting, BTW
03:59:52 <vikasc> thanks everybody
04:00:02 <fawadkhaliq> thanks
04:00:03 <fawadkhaliq> bye!
04:00:04 <baohua> thanks everyone, bye~
04:00:05 <tfukushima> Good. Thanks everyone. Let's have more discussion on #openstack-kuryr.
04:00:09 <tfukushima> #endmeeting