18:00:30 <daneyon_> #startmeeting container-networking
18:00:31 <openstack> Meeting started Thu Jun 25 18:00:30 2015 UTC and is due to finish in 60 minutes.  The chair is daneyon_. Information about MeetBot at http://wiki.debian.org/MeetBot.
18:00:32 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
18:00:35 <openstack> The meeting name has been set to 'container_networking'
18:00:39 <thomasem> o/
18:00:40 <thomasem> hello
18:00:44 <daneyon_> #topic roll call
18:00:48 <thomasem> Thomas Maddox
18:00:52 <Tango|2> Ton Ngo
18:00:54 <s3wong> Stephen Wong
18:00:56 <jjfreric> Jacob Frericks
18:00:58 <daneyon_> Hello danehans Daneyon Hansen here
18:01:13 <yapeng> hi, Yapeng Wu
18:01:18 <daneyon_> lets give a min or 2 for others to join
18:01:23 <hongbin> o/
18:01:32 <daneyon_> then we will get into our meeting topics
18:01:38 <SourabhP> hello, Sourabh Patwardhan here
18:02:15 <russellb> o/
18:02:30 <sicarie> o/
18:02:54 <daneyon_> Hello hongbin yapeng jjfrerics3wong Tango|2 thomasem SourabhP sicarie russellb Thanks to everyone for coming together to dive into Magnum networking
18:03:00 <shelleea007_> o/
18:03:04 <daneyon_> #topic Review the Native Docker Networking Blueprint
18:03:10 <daneyon_> #link https://blueprints.launchpad.net/magnum/+spec/native-docker-network
18:03:22 <daneyon_> Please take a few minutes to review the BP
18:03:39 <thomasem> I'm sad that I didn't get the chance to really dig into the etherpad, like I wanted.
18:03:48 <daneyon_> Also please pull up the associated etherpad #link https://etherpad.openstack.org/p/magnum-native-docker-network
18:04:03 <s3wong> daneyon_: so that is using Flannel, or the new SocketPlane based network-plugin from Docker?
18:04:19 <daneyon_> My first question to the team is highlighted in lines 5-10 of the etherpad
18:04:50 <daneyon_> s3wong right now the kube bay type uses flannel
18:05:04 <daneyon_> thomasem no worries
18:05:30 <daneyon_> i would like to get some feedback on the general language around the existing BP
18:06:28 <daneyon_> In the etherpad I pose the question of looking at the model for magnum networking, as apposed to a specific use case such as docker networking multi-host, flannel, etc..
18:06:37 <thomasem> Well, so, the BP suggests a focus on Docker Swarm
18:06:50 <thomasem> but iirc, we wanted to solve the Neutron integration natively for all bay types
18:06:52 <thomasem> is that correct?
18:07:00 <daneyon_> I think before we start plugging solutions into holes, it would be nice to dev a pluggable network model for Magnum
18:07:01 <s3wong> daneyon_: I think the etherpad language is better than bp's --- which suggested just using Docker Swarm
18:07:31 <daneyon_> thomasem not even so much for neutron integration, but just general networkin integration
18:07:54 <thomasem> hmmmmm
18:08:03 <daneyon_> i think a pluggable model that adheres to magnum/docker principles of being simple "batteries included but replacable"
18:08:34 <thomasem> I mean, the cookie-cutter solution could be the baytypes favorite overlay network
18:08:39 <thomasem> yeah
18:08:45 <daneyon_> s3wong and others I think it's important to add your vote on the BP language in the EP
18:09:02 <s3wong> daneyon_: OK
18:09:33 <SourabhP> Is there a preference to tackle swarm or kubernetes first ?
18:09:50 <daneyon_> Please provide your feedback on the BP language in the EP. I would like the group to come to an agreement on defining the BP.
18:10:54 <daneyon_> SourabhP What I suggest in the EP (lines 5-10) is that before we dive into specific integration, we look at the magnum code and see how we can make any container networking implmentation pluggable
18:11:14 <daneyon_> I see this as the first step but I amy ears are open to other uggestions
18:11:18 <thomasem> daneyon_: So, let me see if I understand correctly. This wording is intended to take it away from just a Docker Swarm thing, and look at networking overall for Magnum.
18:11:30 <thomasem> Like, we need to have a solution that works for all supported bay types
18:11:33 <thomasem> even if that means a plugin for each
18:11:40 <thomasem> but it needs to be consistent behavior
18:11:42 <thomasem> across the types?
18:11:52 <daneyon_> thomasem correct that is what I'm thinking, but I want to hear from the group
18:11:57 <s3wong> thomasem: that is how I interpreted it
18:12:04 <daneyon_> Whatever direction we take, I want to make it a group decision
18:12:08 <SourabhP> daneyon_: agreed, extensibility is quite important
18:12:28 <thomasem> Yes
18:12:41 <thomasem> okay, then I didn't misinterpret. :)
18:12:42 <thomasem> sweet
18:12:58 <daneyon_> SourabhP agreed that extensibility is important, but we need to also make sure ease of use is just as important
18:13:23 <Tango|2> is #4 an invitation to the team to add?
18:13:30 <daneyon_> 1 more minute to cast your vote for changing the BP language
18:13:47 <daneyon_> Tango|2 yes
18:13:51 <s3wong> daneyon_: no -1 so far, looking good :-)
18:13:55 <thomasem> daneyon_: Yeah. I think that's been a downside of a lot of OpenStack things - difficult to use, inconsistent between plugins, etc.
18:14:29 <daneyon_> pls add any add'l content as u see fit
18:14:32 <thomasem> general risks you take when adding in extensibility and thus creating a maintenance problem.
18:14:37 <daneyon_> do you think we are missing anything?
18:14:59 <daneyon_> my main point of the BP is that we look at the big picture before diving into specific fixes
18:15:05 <thomasem> yea
18:15:13 <Tango|2> +1 on that
18:15:16 <thomasem> Okey doke. Sorry if I'm diving into the weeds. :P
18:15:20 <daneyon_> and that we align with magnum principles, etc..
18:15:29 <s3wong> daneyon_: +1 --- hence the original bp language with an emphasis on Swarm should be changed
18:16:16 <daneyon_> #agreed that the Magnum networking BP language change to be more generic
18:16:25 <daneyon_> great
18:16:25 <SourabhP> How about aligning with Neutron? I think it’s important to do that, since that’s the key networking project in OpenStack.
18:17:17 <daneyon_> SourabhP I would like to keep the language general. For neutron or anyt other specifi implementations, I would like to start with the use case and then plug in the right solution for the use case
18:17:19 <hongbin> SourabhP: What exactly do you mean by aligning with Neutron?
18:17:22 * s3wong is wondering how Neutron constructs can fit into Kubernetes
18:17:43 <yapeng> daneyon_: agreed
18:17:46 <sicarie> +1 s3wong
18:17:48 <thomasem> s3wong: with a tenant network instead of an overlay network
18:17:51 <daneyon_> I would like to understand in detail how/why a Magnum networking backend (i.e. Flannel) has to integrate with Neutron or any others
18:18:13 <daneyon_> Not saying it should'nt... I just think this process helps lead us to good solutions
18:18:14 <SourabhP> thomasem: yes, that’s my point
18:18:32 <thomasem> Well, there's two main whys
18:18:34 <russellb> it's possible to use Neutron managed tenant networks as your networks for containers instead of creating overlays
18:18:41 <russellb> that's the main win
18:18:42 <daneyon_> I think it's important for us to create strong, detailed use cases
18:18:50 <thomasem> one is that we're double encapsulating with an overlay networking solution, meaning more network comms overhead
18:18:51 <russellb> primarily for network performance reasons
18:19:04 <daneyon_> with that point, pls use the use case section in the EP to create use cases
18:19:13 <thomasem> and two, is that it's not all that friendly trying to talk to other services on the networks that Neutron has.
18:19:18 <thomasem> okay
18:19:19 <daneyon_> and check back so you can see people's comments on your use cases
18:20:04 <daneyon_> #action everyone to review existing use cases, extend existing use cases, comment on use cases, respond, etc..
18:20:22 <daneyon_> #topic Collaborative brainstorm session in EtherPad
18:20:46 <daneyon_> lets take a few minutes to review the use case section of the EP
18:21:48 <daneyon_> pls also add your name next to your EP color so we know who's who
18:22:00 <daneyon_> or you can add your nic next to the lines you add
18:22:52 <daneyon_> In additional to the use cases, pls review the roles associated to the use cases and provide your input/feedback there also
18:33:26 <daneyon_> 5 more minutes for EP collab and then we will get into open discussion back in the orc meeting
18:34:21 <thomasem> daneyon_: does that make more sense?
18:34:32 <thomasem> my answer to your comment/question
18:34:57 <daneyon_> thomasem +1 on the revised language
18:35:07 <daneyon_> and i think that's a great use
18:35:09 <daneyon_> case
18:35:27 <thomasem> great
18:35:31 <daneyon_> users will need to migrate apps and the use case you provided is essential for that
18:35:53 <daneyon_> additionally, not all app services will be containerized
18:36:23 <thomasem> yeah, that needs to be expected
18:36:35 <thomasem> DBaaS will not be a part of your cluster, however you're probably still going to want to use it
18:36:38 <thomasem> and talk over your own network, even
18:36:39 <daneyon_> containerized services should be able to seemlessly communicate with VM-based apps in Nova, bare metal apps not running in a cloud, other clouds, etc..
18:36:40 <thomasem> if possible
18:37:13 <thomasem> So, we'd need some way to attach your cluster to your network, and allow communication to happen without a bunch of hubub
18:38:54 <thomasem> :P consider it merged with 2.4
18:39:25 <sicarie> Has thought been given to security groups or a similar feature? Or will this be delegated to the network?
18:40:02 <thomasem> in most cases it's already handled to some degree by the COE
18:40:05 <thomasem> iiuc
18:40:07 <daneyon_> sicarie I have given some thought to it, but it would be good if you could create a use case to support it in the EP
18:40:14 <thomasem> With Docker you have to expose ports
18:40:18 <thomasem> and so on
18:40:31 <daneyon_> sicarie I think their is a use case that can be created for each of the 3 roles
18:41:04 <daneyon_> #topic Open Discussion
18:41:19 <daneyon_> I hope everyone is back from the EP session
18:41:54 <daneyon_> Would anyone like to have an open discussion?
18:42:41 <thomasem> Well, I unfortunately am booked as usual. I'm expecting another month before I'll be able to devote much time to Magnum networking things.
18:42:50 <thomasem> =[
18:42:56 <daneyon_> I would.... Pls see line 30 in the EP
18:43:04 <hongbin> daneyon_: How about ask ppl to vote on each user cases?
18:43:16 <daneyon_> I would like to establish a date for submitting the spec for review
18:43:34 <daneyon_> hongbin not a bad idea
18:43:34 <thomasem> meaning the day we have a spec to work off of?
18:43:39 <s3wong> daneyon_: that would be a general spec, instead of specific spec for Swarm, Kubernetes...etc
18:43:41 <s3wong> ?
18:43:51 <daneyon_> i was thinking of giving people a day or two to think though use cases
18:44:02 <daneyon_> lets do both
18:44:29 <Tango|2> I think the challenge is to break things down into small chunks and work through them in a common direction.
18:44:38 <daneyon_> everyone pls add comments +1/-1 vote to use cases. Owners of the use case, pls respond to people's questions/comments.
18:45:03 <daneyon_> Tango|2 agreed
18:46:12 <daneyon_> s3wong it will be a general spec. It will support the language we agreed to in lines 5-10 of the EP
18:46:43 <s3wong> daneyon_: OK --- July 25 is a good goal in this case
18:47:51 <daneyon_> Tango|2 getting back to your point of breaking things down, pls use the proposed change section in the EP to provide details. Pls also make sure the proposed change links back to the use case #
18:48:28 <daneyon_> We have 3 votes on establishing 7/25 as the day to submit the spec
18:48:38 <daneyon_> others pls cast your vote
18:48:51 <thomasem> that's the day before my birthday
18:48:51 <Tango|2> daneyon_: got it
18:49:24 <thomasem> So, it's like we'll be getting me a fresh new spec for my birthday.
18:49:36 <daneyon_> thomasem could u ask for a better present ;-)
18:49:40 <Tango|2> Tango|2: we can change to 7/26 :)
18:49:43 <thomasem> I could not.
18:49:48 <thomasem> LOL
18:50:14 <daneyon_> 7/25 it is
18:50:39 <daneyon_> #agreed 7/25 is the date to submit the Magnum networking blueprint
18:51:02 <daneyon_> any other brief open discussion?
18:51:18 <daneyon_> otherwise we'll do a quick review of the action items
18:51:23 <s3wong> daneyon_: submit spec?
18:51:55 <daneyon_> #agreed correction... 7/25 is the date to submit the Magnum networking spec on blueprint
18:52:13 <Tango|2> Should we continue the IRC meeting?
18:52:17 <daneyon_> #agreed correction #2... 7/25 is the date to submit the Magnum networking spec not blueprint
18:52:35 <daneyon_> Tango|2 good point
18:52:51 <daneyon_> all pls see line 38 in the EP and cast your vote
18:53:00 <Tango|2> good for high bandwidth exchange.
18:53:36 <s3wong> daneyon_: weekly?
18:53:48 <daneyon_> If we agree to continue, we will work though the scheduleing details
18:53:49 <thomasem> yeah, I guess that's the question
18:53:52 <thomasem> oh okay
18:54:02 <thomasem> There's definitely value in focusing on it
18:54:14 <thomasem> just not sure we'll have enough material weekly until the spec is finalized and work is underway
18:54:18 <thomasem> imo
18:54:18 <daneyon_> seems like peopple so far would like to keep the mojo flowing
18:55:10 <daneyon_> thomasem good point
18:55:31 <thomasem> Then again, we could consider each meeting an opportunity to continue dedicated work on the spec.
18:55:44 <thomasem> So, I'm fine with either, the more I think about it... I think we'll probably wind up debating what things look like and so on.
18:55:54 <s3wong> thomasem: +1, that would be the motivation
18:56:09 <daneyon_> If we keep the meetings going, would everyone be cool with taking a 2 week break and getting back together on 7/16 to drive home the spec?
18:56:22 <daneyon_> Or maybe the week earlier?
18:56:26 <daneyon_> same time and place
18:56:39 <thomasem> either works for me, honestly.
18:56:52 <Tango|2> Oh right, next week is near the July 4th holiday.
18:56:52 <s3wong> daneyon_: fine either way
18:56:55 <yapeng> fine with me.
18:56:57 <thomasem> I'll just have to carve some time out to meditate on magnum networking.
18:57:25 <daneyon_> we may not be able to get a answer during the meeting, so please use the EP to add your thoughts about continued meetings
18:57:38 <daneyon_> Tango|2 myself and most of the US will be taking time off
18:57:50 <daneyon_> thomasem me too
18:58:18 <SourabhP> 7/16 is good
18:59:06 <Tango|2> +1 on 7/16.  I will be off also.
18:59:10 <daneyon_> I added time/date info for our next meeting on line 41 of EP
18:59:21 <thomasem> thanks daneyon_
18:59:34 <s3wong> daneyon_: cool
18:59:45 <daneyon_> Thanks everyone. Please keep adding to the EP and ping each other on irc
18:59:48 <s3wong> daneyon_: one minute
18:59:49 <yapeng> daneyon_:looking good.
18:59:54 <daneyon_> until then, talk to u on 7/16
19:00:01 <thomasem> Cheers!
19:00:04 <daneyon_> #endmeeting