03:02:02 <tfukushima> #startmeeting kuryr
03:02:03 <openstack> Meeting started Tue Jun 28 03:02:02 2016 UTC and is due to finish in 60 minutes.  The chair is tfukushima. Information about MeetBot at http://wiki.debian.org/MeetBot.
03:02:04 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
03:02:06 <openstack> The meeting name has been set to 'kuryr'
03:02:48 <tfukushima> Who's up for the Kuryr weekly meeting?
03:03:12 <tango> o/
03:03:21 <limao> o/
03:04:56 <vikasc> tfukushima, ping
03:05:15 <tfukushima> #info tango, limao, vikasc and tfukushima are present
03:05:56 <tfukushima> Hi folks, let me start with the overlapping IPAM issue
03:06:25 <tfukushima> #topic Overlapping IPAM
03:07:18 <tfukushima> So I can see patches submitted by vikasc. I reviewed some.
03:07:41 <tfukushima> #link kuryr patches https://review.openstack.org/#/q/project:openstack/kuryr
03:08:09 <vikasc> tfukushima,  due to recently merged "neutron prt active" patch of banix, some of the unit tests are failing
03:08:47 <tfukushima> vikasc: His patch was failing or his patch makes your patch failed?
03:08:50 <vikasc> tfukushima, I am working on fixing those
03:09:13 <vikasc> tfukushima, his patch made my patch test cases failed :)
03:09:21 <vikasc> tfukushima, which were under review
03:09:34 <tfukushima> Ok, that's unfortunate. :-/
03:09:44 <vikasc> tfukushima, to be precise, he added one more parameter to _get_fake_port api
03:09:57 <tfukushima> I see.
03:10:05 <vikasc> tfukushima, i suspect that is causing trouble, looking into it
03:10:43 <tfukushima> Good. I'll continue reviewing your patches as well.
03:10:50 <vikasc> thanks tfukushima
03:11:11 <tfukushima> vikasc: Any update on the pull request against Docker upstream?
03:11:26 <vikasc> tfukushima, unfortunately  no
03:11:53 <tfukushima> It seems they were busy to add new features like embedded Swam to 1.12. :-p
03:12:19 <vikasc> tfukushima, probably yes
03:13:02 <tfukushima> Anyways, take it easy. Making their CI happy would make the merge more possible, I guess.
03:13:51 <vikasc> tfukushima,  i will work on fixing test cases, initially i was hoping some signal from them. But your point makes more sense on fixing CI
03:14:27 <vikasc> tfukushima, once my current patches in Kuryr are in good shape will work on docker PR test cases
03:15:09 <tfukushima> vikasc: Yeah, at that point they'd take your pull requests seriously because they're (probably) too busy to look at every patch.
03:15:44 <vikasc> tfukushima, agreed, broken CI may also be one more reason for extra delay
03:16:36 <vikasc> tfukushima, I too was thinking on similar lines, and now after your suggestion  adding this to my TODO list
03:17:10 <tfukushima> vikasc: Thanks. Do you have any other updates you might want to share?
03:17:38 <vikasc> tfukushima, not on ipam, I want discussion on nested-vm/refactoring
03:18:06 <tfukushima> Ok, let's move to that topic.
03:18:12 <vikasc> tfukushima, thanks
03:18:21 <tfukushima> #topic Netsed VM/containers
03:18:37 <tfukushima> vikasc: Please go ahead.
03:19:14 <vikasc> tfukushima, i was discussing this with some of teammates over irc as well as on ml.
03:19:30 <vikasc> tfukushima, please give me a moment , i will share ml link
03:20:08 <vikasc> http://lists.openstack.org/pipermail/openstack-dev/2016-June/098209.html
03:20:08 <tfukushima> Please take your time. :-)
03:20:45 <tfukushima> #link [openstack-dev] [Kuryr] Refactoring into common library and kuryr-libnetwork + Nested_VMs http://lists.openstack.org/pipermail/openstack-dev/2016-June/098209.html
03:21:23 <vikasc> tfukushima, shall we have a very small break, so that all can be sync going through ml link?
03:22:05 <tfukushima> Sure. Let's have 5 mins break then.
03:22:12 <vikasc> tfukushima, +1
03:26:09 <vikasc> nested-vm spec did not have implementation level details. So i want to share, discuss and get validated my thi nking with all team members
03:26:16 <vikasc> *thinking
03:27:24 <vikasc> logic from current libnetwork which makes neutron calls can be moved to kuryr-controller.
03:28:09 <vikasc> current kuryr will be modified to make calls to kuryr-controller for any network related services
03:28:27 <vikasc> kuryr-controller is responsible for:
03:28:40 <vikasc> 1. making calls to other openstack services
03:28:58 <vikasc> 2. allocating segmentation id for containers on each vm
03:29:00 <tfukushima> vikasc: What kind of neutron calls would move? Like _get_networks_by_attrs and others?
03:29:36 <vikasc> tfukushima,  yes.. all neutron apis like get_port, create_subnet etc
03:30:09 <vikasc> tfukushima,  Otherwise we will have to store credentials on each vm
03:31:47 <tfukushima> Sorry for interrupting. Please go on if you didn't finish it yet.
03:32:38 <vikasc> tfukushima,  kuryr part running on each vm will be responsible only for:
03:33:28 <vikasc> 1. configuring local (inside vm) backened(ovs or midonet) for containers traffic tagging
03:33:55 <vikasc> 2. vif binding
03:34:44 <vikasc> But for anything related to neutron or allocation of tags will be done by central kuryr-controller
03:36:02 <vikasc> central kuryr-controller, apart from talking to neutron and per-vm tags allocation , will also be responsible for configuring ovs on compute machine for traffic untagging
03:36:23 <vikasc> tfukushima, my first iteration is done :)
03:37:02 <vikasc> tfukushima, not sure how much clear i was :)
03:38:28 <tfukushima> vikasc: Ok, so how the component on each VM (kuryr-agent?) talk to the centralized kuryr-controller?
03:38:52 <vikasc> tfukushima,  how about rest calls?
03:39:05 <vikasc> tfukushima,  just like a client
03:39:27 <tfukushima> Oh, I guessed it'd be done through RPC or something.
03:39:38 <vikasc> tfukushima, since it has to react to calls from libnetwork
03:40:41 <tfukushima> Ok, anyways I got the point.
03:40:42 <vikasc> tfukushima,  initially i was thinking of rpc but then rest calls was making more sense
03:41:24 <vikasc> tfukushima, so if get some improvements suggestion , i will update the current nested-vm spec
03:42:30 <tango> vikasc: is the agent talking to the controller now?
03:42:48 <vikasc> tfukushima, you mean in current code?
03:42:57 <tango> right
03:43:08 <vikasc> tfukushima, no..
03:43:11 <tfukushima> vikasc: tango is not me. :-)
03:43:20 <vikasc> oh, sorry
03:43:42 <tango> np :)
03:43:57 <vikasc> tango,  no.. currently agent/client/driver talks directly to neutron
03:44:28 <tango> ok, so what does the controller do now?
03:44:40 <vikasc> tango, there is no controller :D
03:45:01 <tango> ah ok, me learning Kuryr :)
03:45:06 <vikasc> tango,  everything is in libnetwork driver only
03:45:15 <vikasc> tango,  np :)
03:45:19 <tfukushima> I guess he meant kuryr/controller.py.
03:45:59 <vikasc> tango,  current controller.py has all linetwork api handling methods
03:46:35 <tfukushima> It'd delegate the actual Neutron API calls to the centralized "kuryr-controller". That's the idea I got from the discussion.
03:46:53 <vikasc> tfukushima,  +1
03:47:14 <tango> ok, I think I get the idea
03:47:48 <vikasc> tfukushima, would you suggest to update the nested-vm spec with the approach discussed here or should i wait more for inputs on ml
03:47:53 <vikasc> or irc or meetings
03:48:35 <vikasc> tfukushima, i discussed with gal also. He was also a bit positive about the approach. What would you suggest
03:48:50 <tfukushima> libnetwork requires only the remote driver to provides the HTTP APIs and its concern is just the interface of the input/output from/to Docker. Currently kuryr/controller.py calls the Neutron API directly by itself but there'd be more nodes and you'll get more responsibility for their configurations. So we want to have the centralized "kuryr-controller" to handle all the Neutron API calls.
03:49:32 <vikasc> tfukushima, exactly, nicely put
03:49:56 <tango> Thanks Taku, that's very helpful
03:50:24 <tango> vikasc: if you are going to update the spec, please also update the part about Magnum's API for container, which has been removed.
03:50:47 <vikasc> tango, sure.. I will take care
03:51:40 <vikasc> tfukushima, do you see any big hole in approach?
03:51:46 <tfukushima> So internally either RPC or REST API call works anyways for the way to communicate with kuryr-controller.
03:52:13 <vikasc> tfukushima, +1
03:53:41 <tfukushima> My personal preference is to make the communication done through the RPC with Protocol Buffers/gRPC but I'm not sure if it's possible in OpenStack world.
03:54:09 <tfukushima> I don't know how other OpenStack projects are handling the RPC needs.
03:54:09 <vikasc> tfukushima, lets add this as options in spec
03:54:46 <tfukushima> At least, I can't find protobuf library in global-requirements.txt: https://github.com/openstack/requirements/blob/master/global-requirements.txt
03:55:13 <tfukushima> Maybe they're just using AMQP for that.
03:55:21 <vikasc> tfukushima, i also think so
03:56:02 <vikasc> tfukushima, only 5 mins left
03:56:40 <tfukushima> Anyways I totally agree on the big idea. We need to investigate and think about the communication methods. I prefer RPC for the internal communications since it's considered private.
03:56:58 <tfukushima> But REST/HTTP API works as well.
03:57:06 <tfukushima> Ok, let's wrap it up.
03:57:17 <vikasc> tfukushima,  I would add these as alternatives
03:57:27 <vikasc> tfukushima, one more quick point
03:58:23 <vikasc> tfukushima, all this work will be applicable for k8s integration also, whatever we have today in kuryr-k8s-integration spec it is control path only.
03:59:09 <vikasc> tfukushima,  should we add one more section there for data path and refereing to nested-vm spec
03:59:24 <vikasc> *nested-container
03:59:49 <tfukushima> vikasc: Yes, exactly. We can reuse this mechanism for future-added components as well.
04:00:05 <tfukushima> Yes, I will add the description for that.
04:00:14 <tango> I have a really quick question, just to clarify:  is the openvswitch agent required on all nodes in the Swarm cluster?
04:00:27 <vikasc> tfukushima, exactly for any COEs.. please provide your opinion on ml also.
04:00:34 <vikasc> tango, you also please :)
04:01:06 <tango> vikasc: certainly
04:01:19 <tfukushima> tango: Yes if you're using Open vSwitch under your controller.
04:01:20 <vikasc> tfukushima, tango, there is lot of work left. :)
04:01:39 <tango> ok thanks
04:01:56 <tfukushima> Ok, guys we're running out our time.
04:02:09 <vikasc> tango,  ovs-agent is required on all compute machines for configuration of untagging part
04:02:47 <tango> Thanks for confirming
04:03:10 <vikasc> tango,  please note that traffic on vm's trunk port will come with different tags, now tag to subport mapping will be handled/configured by ovs-agent
04:03:52 <vikasc> tfukushima, done :)
04:04:11 <tfukushima> Good. So let's finish our meeting.
04:04:23 <tfukushima> Sorry for my disoganization this time. :-/
04:04:43 <vikasc> tfukushima, np :)
04:04:51 <tango> Good thing nobody is trying to kick us out :)
04:05:02 <vikasc> :D
04:05:09 <tfukushima> Yeah.
04:05:24 <tfukushima> limao: If you want to discuss something, we can do that in #openstack-kuryr channel.
04:05:39 <limao> yeah，thanks
04:05:50 <tfukushima> Alright, thanks for attending guys.
04:06:03 <tfukushima> #endmeeting