15:00:55 #startmeeting kuryr 15:00:56 Meeting started Mon Nov 9 15:00:55 2015 UTC and is due to finish in 60 minutes. The chair is apuimedo. Information about MeetBot at http://wiki.debian.org/MeetBot. 15:00:57 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 15:01:00 The meeting name has been set to 'kuryr' 15:01:19 Hello everybody and welcome to the first Mitaka cycle Kuryr meeting! 15:01:37 who's up for a quick meeting? 15:01:43 o/ 15:01:53 hi 15:02:27 sounds good :) 15:03:03 Sorry :) 15:03:08 thought its in an hour as clock changed 15:03:16 hi everyone :) 15:03:38 #info only cores present today. tfukushima, banix, gsagie and apuimedo 15:04:30 I'm glad you could make it to the meeting 15:04:57 and I want to start by saying that the Friday morning meetup was very enjoyable. Thanks ;-) 15:05:16 yep, was great to meet everyone 15:05:40 I also want to apologize for not having posted an agenda 15:05:52 basically I'd like to keep following up on the work items 15:06:13 gsagie is working on having devstack working 15:06:46 yeah, basically it will need to also install a default k/v store, as Docker engine installation doesnt come with a default one and its not working otherwise 15:06:52 #topic devstack 15:07:18 i hope to send something out tommorow but also will need the OVS binding part, as the example local.conf is going to be with the reference implementation 15:07:38 #info devstack needs to set un a default k/v store and set up Docker to use it. 15:07:50 gsagie: I guess you will do it with consul, right? 15:08:07 apuimedo: actually etcd is simpler for me 15:08:13 fine 15:08:17 but we can later add other options 15:08:32 #info: gsagie will set the default k/v store to be etcd 15:08:49 any objection from the tfukushima or banix on this point? 15:09:09 and of course to test it fully i will need the OVS binding part merged 15:09:22 is diga here? 15:09:30 no not really; haven’t used it with Kuryr but I am sure it will be fine 15:09:36 apuimedo: The key-value store should be transparent and anything can be fine for me. 15:09:45 perfect, etcd it is then 15:09:55 #topic bindings 15:09:58 tfukushima: yeah the plan is that it can be changed by configuration in the local.conf 15:10:13 so we can add consul quite easily 15:10:41 banix: I assume you have an ovs binding since you demoed it :-) 15:10:49 :) 15:11:04 yes I do; I offered to help diga as he has a patch on it 15:11:17 banix: that's what I wanted to ask 15:11:25 I haven’t heard back though 15:11:33 could you please help him get it this week 15:11:44 Yes I will reach out to him directly 15:11:52 if he does not respond I guess we'll have to move on 15:12:06 yes sure 15:12:16 and use either feiskyer abandoned patch or the work you used for the demo 15:12:23 nice 15:12:32 Would it be better to have the deadline? 15:12:50 tfukushima: I'm not sure where that'd be posted 15:12:51 i think we really only need the script and maybe pass the MAC (and optionally bridge) 15:12:53 in the binding 15:13:06 is there anything else? 15:13:08 gsagie: I'm wondering when I'll see a Dragonflow binding 15:13:19 apuimedo: the OVS one will fit that too :) 15:13:25 ah, cool 15:14:00 about the extra parameters 15:14:05 that ovs binding needs 15:14:09 gsagie: I think we want to have the option of having the hybrid OVS as well, for security groups. or may be that is the only thing we need? 15:14:38 not only, because OVN for example doesnt need it 15:14:43 but yeah thats a good point 15:15:05 banix: gsagie: I think that we don't need the hybrid ovs 15:15:11 if 15:15:13 of course 15:15:30 apuimedo: its needed for the reference implementation, if i understood correctly what you mean by "hybrid ovs" 15:15:32 neutron really manages to move ovs to use conntrack for security groups 15:15:53 apuimedo: yeah, but not sure when this will be merged, dont think its planned for Mitaka 15:15:59 apuimedo: well, is that going to happen soon? 15:16:02 oh. I thought it was 15:16:10 well. Let's figure it out 15:16:14 and if it isn't planned 15:16:18 yup 15:16:29 we have to do the funky linux bridge binding, of course :-) 15:17:13 apuimedo: I agree 15:17:18 you can add an action on me to find out when its planned 15:17:22 #action gsagie to check conntrack for security groups in the mitaka cycle 15:17:29 thanks gsagie 15:17:56 #action banix to work with diga on the ovs binding (with the hybrid as follow up patches if necessary) 15:18:39 vikasc_: hi! Joining the meeting? 15:18:47 apuimedo, hi 15:18:56 sorry for being late 15:19:06 no problem, glad you made it 15:19:15 #topic multi-node 15:19:45 #info vikasc_, banix and tfukushima have worked on this 15:19:50 what's the current state? 15:20:42 I confirmed I could ping from a host to another host with my setting where I have Docker 1.9.0 release. 15:21:29 tfukushima: master or some other patch necessary? 15:21:55 We need Vikas's validation patches. 15:22:20 Then, it's basically the same as master. 15:22:21 can you describe how the multi node is working? 15:23:04 Actually I tried with MidoNet and it's specific to it but I just launched two Docker instances in the different hosts. 15:23:25 #action apuimedo to review validation vikasc patches 15:23:52 banix did try it with ovs though, right? 15:23:55 what do you mean specific to Midonet? 15:23:57 or was it ovn? 15:24:05 it needs to communicate with the same Neutron right? 15:24:07 apuimedo: ovs 15:24:10 And I just pinged. Before that, I needed to configure them to be in the same tunnel zone, which is the concept specific to MidoNet. 15:24:13 do you mean the tunneling between hosts, tfukushima ? 15:24:38 Yes, GRE andVXLAN. 15:25:13 oh well... I would appreciate if we put some docs in the repo for each binding/vendor that we support 15:25:19 explaining how to set it up 15:25:20 I am more interested how we do it in Kuryr side, given that there is a Neutron solution deployed at both hosts what is needed in Kuryr? 15:25:55 gsagie: kuryr had to be configured in global mode, which vikasc rightly spotted 15:25:56 apuimedo: isnt the tunneling just a Neutron specific implementation? 15:26:06 and docker had to point to the kv in both machines 15:26:12 it needs to work regardless if we have containers or not 15:26:13 gsagie: with OVS, nothing beyond the binding is needed on the Kuryr side 15:26:21 gsagie: it is, that's why tfukushima said it was a midonet thing that he had to address 15:26:57 ok, and just to understand we running one kuryr server in this case? 15:27:17 gsagie: no. Always one per host 15:27:24 apuimedo, true 15:28:08 ok, so you added code that knows to recognize the same network for example and not re-create it in Neutron and so on in order to implement this 15:28:22 gsagie: that's handled by docker 15:28:31 recently 15:28:44 before Taku had to make a patch to prevent the re-creation 15:28:53 but they fixed the propagation 15:29:29 Instead, the networks are shared through the distributed datastore. 15:29:30 ahh ok, so basically its mostly testing ? 15:29:37 in Kuryr part 15:30:21 tfukushima, currently we running independent neutron on each node? 15:30:36 it has to be the same neutron 15:30:39 vikasc_: no one neutron service 15:30:45 #topic open discussion vikasc_ you could, but for most deployments a single neutron server would be the norm 15:30:52 (you can put more behind ha) 15:31:00 oops 15:31:05 :) 15:31:06 wrong command 15:31:06 vikasc_: No. Every Kuryr agent points to the same Neutron API in my setting. 15:31:21 #topic still multi-node 15:31:23 tfukushima, got it 15:31:55 ok. let's move on 15:32:01 k 15:32:16 tfukushima: did you give any look at connecting to existing nets? 15:32:29 (existing neutron nets) 15:32:36 apuimedo: No, not yet. 15:32:43 ok ;-) 15:32:59 Before that, we need to solve the IPAM and the API change in 1.9.0. 15:33:06 true 15:33:21 That's a huge gap for now. 15:33:22 #topic stabilization 15:33:27 i am working on null ipam driver , will be pushing for review soon 15:33:32 tfukushima: please, list the missing parts 15:33:46 #info vikasc_ is working on a null ipam driver 15:33:51 thanks vikasc_ ! 15:34:15 1. IPv4Data and IPv6Data in the request of /NetworkDriver.CreateNetwork 15:34:40 vikasc_: does that make it possible to use kuryr as is? 15:34:48 2. Doing something for IPAM driver (Vikas is already working probably) 15:34:49 yes banix 15:35:00 vikasc_: great 15:35:05 yes 15:35:24 our existing changes will make sense 15:35:26 3. /NetworkDriver.DiscoverNew and /NetworkDriver.DiscoverDelete (banix is looking at them?) 15:35:41 tfukushima: yes 15:36:03 I'm working on 1. now. It's taking some time because it's a big internal change. 15:36:40 working on 2 15:37:11 So I'm modifying Kuryr to allocate subnets on creating the Docker network instead of on creating endpoints. 15:37:18 #info tfukushima working on IPv4Data and IPv6Data in /NetworkDriver.CreateNetwork requests 15:37:30 tfukushima that's a welcome change :-) 15:38:01 Yes indeed. But they should have that in the first place. 15:38:08 yeah 15:38:39 we have to dance to their(docker) tunes :) 15:38:53 #info banix working on /NetworkDriver.DiscoverNew and /NetworkDriver.DiscoverDelete 15:39:02 vikasc_ indeed 15:39:29 #topic open discussion 15:39:41 does anybody have another topic to bring up? 15:40:05 remember that next week we run the meeting in the alternate time 15:40:10 external connectivity 15:40:12 I guess banix will chair it 15:40:45 vikasc_: can you give more context (for logging purposes)? 15:41:01 #link external network connectivity blue print https://blueprints.launchpad.net/kuryr/+spec/external-network-connectivity 15:41:04 apuimedo: sure 15:41:05 https://blueprints.launchpad.net/kuryr/+spec/external-network-connectivity 15:41:23 thanks tfukushima, vikasc_ 15:41:45 #action apuimedo to review the external network connectivity blueprint 15:41:51 same 15:41:55 sorry vikasc_. I didn't get around to it yet 15:42:00 its about creating the virtual router right? 15:42:07 let's discuss it online during the week 15:42:17 sure 15:42:25 gsagie, yes 15:42:30 (and of course we can discuss a bit now if more people have the right context) 15:42:35 vikasc_ : i think we need to imitate what magnum are doing 15:42:48 or at least be close to their implementation 15:42:48 gsagie, yes Gal 15:43:09 You already have the design ready in the blue print? 15:43:30 High level choices i have mentioned there on bp 15:43:36 i will make sure to go over it and give you feedback 15:43:43 gsagie: Could you give us the link of what Magnum is doing? 15:44:01 tfukushima: dont have it, i need to search it up and look 15:44:12 gsagie, thanks 15:44:15 about blueprints. (and sorry for going a bit off-topic) We should define what deserves a spec and what a blueprint 15:44:28 Ok. I'll search it. 15:45:22 going back to the multinode, does this mean that we have full integration with Swarm, or something else needs to be done? 15:45:24 gsagie, tfukushima through heat templates they create router and their and plumb external networking 15:45:38 i have little idea baout that 15:45:41 *about 15:46:07 vikasc_ : will take a look and we can talk about it online 15:46:16 gsagie, thanks gal 15:46:26 you can always also talk with danyeon from the Magnum team about it 15:46:53 gsagie: It's basically the same as the default overlay driver. So probably yes although I've never tried anything with Swarm. 15:47:14 But again, Kuryr is lacking the compatibility with the latest libnetwork. 15:47:14 I'll be trying swarm with kuryr this week 15:48:06 yeah assuming we stabilize it with latest libnetwork 15:48:07 ok thanks 15:48:11 yes. 15:48:17 Any other topic? 15:49:37 alright. Thank you all for the meeting and let's see if the EMEA folks are able to be on the next meeting :-) 15:49:41 #endmeeting