18:30:13 #startmeeting container-networking 18:30:14 Meeting started Thu Nov 12 18:30:13 2015 UTC and is due to finish in 60 minutes. The chair is daneyon_. Information about MeetBot at http://wiki.debian.org/MeetBot. 18:30:15 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 18:30:18 The meeting name has been set to 'container_networking' 18:30:32 Agenda 18:30:36 #link https://wiki.openstack.org/wiki/Meetings/Containers#Agenda 18:30:55 i'll give everyone a minute to look at the agenda 18:31:08 #topic roll call 18:31:12 o/ 18:31:14 Adrian Otto 18:32:07 Hey adrian_otto! 18:32:14 maybe time to wind down the subteam? 18:32:20 Looks like it might be just you and I. 18:32:26 Might not be a bad idea 18:32:40 seems that we are in implementation mode now, so less discussion needed 18:33:06 However, it will help the project if we can get more people participating in networking features of Magnum. 18:33:13 Let me know what ideas you have. 18:33:24 true 18:33:33 reach out to those who have attended in the past, and let them know when meetings are coming up 18:33:47 i'm in the process of breaking up patch #link https://review.openstack.org/#/c/224367/14 18:33:54 o/ 18:33:58 sorry late 18:34:22 I thought i had the 1st review ready, but i have a merge conflict b/c of recent changes. I should have it tee'd up in a little while. 18:34:33 hi eghobo 18:35:31 adrian_otto should we ask community members if they want to continue sub team meeting during the general Magnum meeting? 18:36:16 sure, we can ask there. I'd also encourage you to follow up with previously active participants individually to get a sense from them 18:36:38 adrian_otto: I'll do that. 18:37:06 adrian_otto do you want to add the agenda topic to the magnum meeting or should i? 18:37:27 please add it 18:37:31 o/ 18:37:34 will do 18:37:53 Hi hongbin 18:37:58 o/ (sorry I'm late, forgot to update my calendar for the DST) 18:38:04 Hey 18:38:37 Well... I was thinking of wrapping up the meeting since it was just adrian_otto and I, but it looks like we have an audience. 18:38:44 thanks everyone for joining 18:39:08 and sorry for messing up my calendar the last week. 18:39:24 I was on vacation anyway last week 18:39:24 wish we didn't have DST changes :-) 18:39:35 Tango welcome back 18:39:46 i'll move quickly 18:39:54 but i'm a slow typer ;-) 18:40:04 #topic Review and Discuss Magnum Networking Design Summit 18:40:08 #link https://etherpad.openstack.org/p/mitaka-magnum-network 18:40:48 In general I was very pleased with the attendance of the networking DS session 18:41:03 and I thought we had a lot of good discussion 18:41:36 We had a fair bit of discussion related to this patch 18:41:44 #link https://review.openstack.org/#/c/241866/ 18:42:27 Is Angus Lee in attendance? 18:43:11 Does the group agree that it's a good idea for the flannel driver to continue to support overlay methods? 18:43:24 I missed the discussion because of a conflict with my talk. But this patch seems like a great idea based on our performance measurement. 18:43:38 daneyon_: it depends ;) 18:43:41 It removes one level of overlay encapsulation 18:43:55 Tango agreed. I have wanted to add the host-gw mode, but have been to busy with implementing the CNM 18:44:22 My only thought is how to present the option to the user 18:44:25 However, I would like to keep the existing overlay options for flannel. 18:44:46 My vote is for option #2 18:44:54 let's make it work first, and make it faster next. 18:45:12 Right, we probably want to expose all the options and make it easy to specify them 18:45:19 adrian_otto: +1 18:45:52 daneyon_: I still believe we should drop vxlan 18:45:55 step one is just to have sensible defaults that work 18:46:02 then make the options so you can change them 18:46:18 Currently it's working with the udp and vxlan options with udp as the default, we want to add the gw option 18:46:18 and then revisit what the defaults should be based on all available choices 18:46:21 eghobo: not sure if I agree for the dropping of vxlan 18:46:42 eghobo: Possibly, udp is the option that I want to drop if we have to drop one 18:46:52 adrian_otto agreed. However, supporting option #2 should be easy. If someone in the community wants to implement #2, you'll get my support. However to adrian_otto's point, we need to get the CNM implemented across all bay types and distros 18:46:54 why drop vxlan? 18:47:08 and I could definitely use help in that department 18:47:38 Tango agreed. I would like to lave existing options. Again, I'm all for #2. 18:47:54 adrian_otto: can anyone explain how it's going to work with Neutron ;) 18:47:57 later on we can drop config options based on feedback from magnum users 18:48:02 I would agree too with #2 18:48:22 i don't see having the 3 flannel backends burdening the project, devs or users. 18:48:32 eghobo: it's really independent of neutron 18:48:33 eghobo: with k8s, I don't think we have full clarity on neutron integration to eliminate the overlay 18:48:50 all, please provide your comments in the review. 18:48:56 daneyon_: CNM? not sure that Kub folks even have plans for that 18:49:01 i would like to move on since we are short on time 18:49:07 but at a conceptual level we should be able to do the functional equivalent of kuryr for k8s 18:49:24 I mean the Magnum CNM.. look at the specs DIR 18:49:31 #topic Discuss Docker 1.9 Networking 18:49:34 #link http://www.meetup.com/Docker-Online-Meetup/events/226522306/ 18:49:42 I just finished attending the ^ event 18:49:46 Tango, adrian_otto: it's exactly my point neutron deal with vxlan and we use it ;) 18:50:02 For the most part, it's the same libnetwork stuff. 18:50:22 I did not see or hear anything that was not presented in previous webinars 18:50:25 something like hw-gw doesn't care about underlying network 18:50:46 A couple things I noticed is: routing between nets and supports for continuers to attach to multiple nets. 18:50:48 I did not fully understand the IPAM solution 18:50:54 I have not seen these features of libnetwork before 18:50:55 it sounded hardwired to me 18:51:02 but he said it was pluggable 18:51:30 I'll need to look at the code b/c I have no idea how libnetwork is passing packets between L3 domains. 18:51:58 probably just using host routing and a container that's in multiple network namespaces 18:52:04 adrian_otto agreed. I know libnet recently implemented pluggable ipam. 18:52:29 daneyon_: also keep in mind, Kub folks not really in libnetwork support yet 18:52:30 In general, I think it's good for everyone to review libnetwork since it has gone though some recent changes. 18:52:52 eghobo understood, kube has it's own pluggable model. 18:53:59 eghobo in a way host-gw does care about the underlying network. Ex> all flannel nodes must be on the same L3 domain. 18:54:04 daneyon_: yes and they have a lot of concern about libnetwork implementation ): 18:54:22 any questions about libnetwork 1.9? 18:54:33 daneyon_: you mean L2, right? 18:54:38 moving on then 18:54:55 So should we move to Docker 1.9 yet? 18:55:26 why not? 18:55:26 Tango that's a good question 18:55:48 unless I missed something, libnetwork is still experimental in 1.9. 18:56:10 but it may be worth it, so we can gain experience. 18:56:14 There was mention about new volume support in 1.9, so it may be good to catch that as well 18:56:26 however, i know getting magnum prod ready is a priority 18:56:51 adiran_otto i'll pose the question as an agenda item for the magnum meeting. 18:57:31 Tango agreed. I think it comes down do we want to be on the cutting edge or stability. adrian_otto will have a big voice in this one. 18:58:04 fyi I am breaking up this patch: https://review.openstack.org/#/c/224367/14 18:58:18 it included a lot of stuff and was tough on reviewers. 18:58:46 You will be seeing several patches from me in the coming days and hopefully CNM for swarm will be implemented. 18:59:29 Whoever added mesos support to magnum, I would love to get your help implementing cnm for mesos :-) 18:59:39 sure 18:59:58 time to wrap up. Feel free to carry over the conversation to the magnum irc channel 19:00:07 Thx for attending!!! 19:00:13 #endmeeting