18:00:05 <daneyon_> #startmeeting container-networking
18:00:05 <openstack> Meeting started Thu Sep 17 18:00:05 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:06 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
18:00:08 <openstack> The meeting name has been set to 'container_networking'
18:00:26 <daneyon_> Agenda
18:00:32 <daneyon_> #link https://wiki.openstack.org/wiki/Meetings/Containers#Agenda
18:01:08 <daneyon_> I'll give everyone a minute to review the agenda
18:01:27 <daneyon_> #topic roll call
18:01:31 <daneyon_> o/
18:01:36 <Tango> Ton Ngo
18:01:41 <s3wong> Stephen Wong
18:01:44 <eghobo> o/
18:02:12 <daneyon_> Thank you Tango s3wong eghobo for joining
18:02:18 <daneyon_> #topic Discuss Kuryr Design Spec
18:02:23 <daneyon_> #link https://review.openstack.org/#/c/213490/
18:02:33 <daneyon_> I have just given my +1 vote to the spec
18:02:53 <daneyon_> I think it's in good shape and thanks to gsagie for putting a ton of effoert into it
18:03:34 <daneyon_> I think it was well worth going through the process. I have a much better understanding of what kuryr is and is not, along with near-term/long-term dev activities
18:03:43 <daneyon_> I hope the rest of the groups agrees
18:03:52 <Tango> +1
18:04:12 <Tango> I think it was a good exercise for the Kuryr team also
18:04:24 <daneyon_> I would like to take this time for everyone to perform a quick review of the spec and cast your vote.
18:04:56 <daneyon_> If you cast a -1, please be very clear on what you need from gsagie for a +1 vote and follow up with the spec
18:05:35 <daneyon_> #action everyone who votes on the kuryr design spec to continue tracking the spec to completion by voting.
18:05:44 <daneyon_> Tango agreed
18:06:39 <daneyon_> I'll give the team until :15 to reconvene, please take this time to review and vote on the spec.
18:13:34 <daneyon_> t- 2 minutes
18:14:19 <hongbin> o/
18:15:02 <daneyon_> I see Tango has casted a vote. eghobo and s3wong do you need more time to review and cast a vote?
18:15:30 <eghobo> yes, I would like to think a little
18:15:34 <daneyon_> hongbin I have asked the team to review the kuryr spec and cast a vote. If -1, pls provide a detailed comment on what is needed for your +1 vote
18:15:48 <s3wong> daneyon_: I am good
18:15:52 <daneyon_> I am asking this of the team, b/c the kuryr team is looking for our support.
18:16:23 <daneyon_> It is very important to them that the magnum community is on board with the direction of the project.
18:16:39 <daneyon_> hongbin do you need a link to the spec?
18:16:51 <daneyon_> thank you s3wong
18:16:52 <hongbin> daneyon_: no. I am good
18:16:58 <hongbin> thx
18:17:09 <daneyon_> hongbin great... thank you.
18:18:47 <hongbin> I think their spec is good. I cannot find anything unstatisfied
18:19:00 <daneyon_> eghobo no problem, I don't want you to feel rushed. Take the time you need, I just ask that if -1 the spec to please provide a detailed comment on what is needed for your +1 vote. As you can see the spec has been in action for a while. Thanks!
18:19:21 <daneyon_> hongbin agreed, that's why it finally got my +1 ;-)
18:20:07 <daneyon_> hongbin take the time you need to review, just please cast your vote and if -1 the spec to please provide a detailed comment on what is needed for your +1 vote. Thanks!
18:20:14 <daneyon_> lets proceed
18:20:21 <daneyon_> #topic Discuss Kuryr Integration Blueprint
18:20:25 <daneyon_> #link https://blueprints.launchpad.net/kuryr/+spec/containers-in-instances
18:21:03 <daneyon_> although the bp is named container-in-instances, IMO the details of the bp cover the main points oof Magnum integration.
18:21:04 <hongbin> daneyon_: I have +1
18:21:31 <daneyon_> The bp details were derived from the integration ep that we put together
18:21:40 <daneyon_> #link https://etherpad.openstack.org/p/magnum-kuryr
18:22:15 <daneyon_> I would like to give the group until :30 to review the contents of the bp.
18:22:46 <daneyon_> If you have any questions or concerns, please use the meeting irc to communicate
18:28:14 <daneyon_> t- 2 minutes
18:30:08 <daneyon_> I suggest subscribing yourself to the blueprint if you intend to stay involved with integrating magnum and kuryr.
18:30:37 <daneyon_> Any questions or concerns regarding the kuryr integration bp?
18:31:22 <daneyon_> I would expect the details of this blueprint to get broken-out into smaller bp's for the different tasks.
18:31:26 <hongbin> daneyon_: do you have the link to the integration bp?
18:31:38 <daneyon_> #link https://blueprints.launchpad.net/kuryr/+spec/containers-in-instances
18:32:15 <Tango> brand new one
18:32:20 <hongbin> daneyon_: Oh, this one. Sorry I saw that
18:32:38 <daneyon_> in hindsight, I should have chosen a different name. Let me update the name real quick
18:33:18 <Tango> yeah the name is not obvious
18:33:37 <daneyon_> give me 2 min to update
18:34:00 <daneyon_> done
18:34:03 <daneyon_> go ahead a refresh
18:34:07 <daneyon_> and
18:34:28 <hongbin> yes, it is better :)
18:34:39 <daneyon_> lets proceed with our agenda
18:34:43 <daneyon_> thx hongbin
18:34:51 <daneyon_> #topic Discuss Magnum Container Networking in Swarm Bay Type Issue. Details were posted to the mailer.
18:35:00 <daneyon_> #link https://etherpad.mozilla.org/QB349WdtL8
18:35:21 <daneyon_> I will give everyone until :40 to review the link
18:36:16 <hongbin> daneyon_: I think the default value of discover_url is configurable
18:36:39 <hongbin> Maybe a solution is to define the default discovery_url for each bay in config file
18:36:40 <daneyon_> hongbin that is correct
18:36:49 <daneyon_> but the issue is bigger than that
18:37:38 <daneyon_> hongbin can you take another look at my explanation and let me know if you understand the issue I'm facing?
18:38:05 * hongbin reading
18:40:35 <daneyon_> in general, swarm uses the discovery_url. If I simply implement flannel for the swarm bay type, flannel will contend with swarm for the discovery_url, b/c flannel required etc and magnum has implemented the public discovery mechanism for bootstrapping the etcd cluster.
18:40:43 <Tango> daneyon_: The options are not numbered, I can guess, but do you want to number them?
18:41:31 <Tango> I would vote for #2 also, having one discovery
18:41:35 <daneyon_> essentially swarm and etcd's public discovery mechanisms will contend with one another b/c how discovery_url was implemented
18:41:52 <daneyon_> Tango, will do
18:42:14 <daneyon_> the formatting of the ep messed up the formatting of the email that went out.
18:42:16 <daneyon_> 1 sec
18:43:06 <hongbin> daneyon_: for option #2, is the implementation hard or easy?
18:43:19 <hongbin> or I should say, what need to change?
18:43:36 <daneyon_> ok, the formatting should be good now
18:43:52 <Tango> Thanks
18:44:18 <daneyon_> hongbin I think the implementation is a 3-4 out of 10 difficulty rating.
18:44:54 <hongbin> then, I have no problem of that.
18:44:58 <daneyon_> hongbin what needs to change is using a different discovery mechanism for the swarm bay type
18:45:11 <daneyon_> let me clarify...
18:45:39 <daneyon_> swarm would use etcd instead of Docker's public (Docker Hub) discovery service.
18:46:16 <hongbin> daneyon_: yes, switch the discovery method should not be a problem in my view, but better ask andrew's advice
18:46:24 <hongbin> andrew is the author of swarm bay
18:46:48 <daneyon_> The swarm Heat template would stand-up an etcd cluster (just like it does for a k8s bay type) as part of orchestrating the swarm bay type. The swarm manager/agent service would be configured to use the etcd cluster vip instead of the public discovery service
18:47:29 <daneyon_> hongbin I tried pinging amelton on irc yesterday. I'll try again today
18:48:07 <daneyon_> I will proceed with option #2 unless anyone from the group or amelton has objections.
18:48:52 <hongbin> daneyon_: one thing, for the case that there is a private cloud and it has no external internet access
18:49:10 <hongbin> is that anyway to solve the discovery problem in flannel?
18:49:54 <daneyon_> hongbin with my proposal, etcd will still use it's public discovery mechanism.
18:50:26 <daneyon_> we can certainly change that with etcd, but I would like to file a seperate bp for that use case
18:51:01 <daneyon_> my focus right now is to make sure flannel networking (using network-driver and labels) works across all bay types.
18:51:21 <hongbin> yes, we can worry the case later
18:51:34 <hongbin> the private cloud case
18:51:37 <daneyon_> but i do like the option of moving all discovery away from public and keeping it inside the bay.
18:52:09 <hongbin> agree, public discovery service is optimal
18:52:17 <daneyon_> unless their are anymore questions regarding the discovery issue, let's move on.
18:52:27 <daneyon_> #topic Review Action Items
18:52:34 * daneyon_ danehans to continue coordinating with gsagie on a combined kuryr/magnum design summit session.
18:52:52 <daneyon_> I have not discuss the DS with gsagie, let's move the action item fwd.
18:52:59 <daneyon_> #action danehans to continue coordinating with gsagie on a combined kuryr/magnum design summit session.
18:53:04 * daneyon_ everyone to take a few minutes reviewing the 9/7/2015 kuryr meeting logs
18:53:17 <daneyon_> I have reviwed the logs from last week's meeting.
18:53:32 <daneyon_> Hopefully everyone else has too ;-)
18:53:37 <daneyon_> #topic Open Discussion
18:54:05 <daneyon_> Here is my WIP patch for the swarm work
18:54:07 <daneyon_> #link https://review.openstack.org/#/c/224367/
18:54:24 <daneyon_> I need to post an update, b/c/ I have made a ton of changes since then
18:54:39 <daneyon_> This is just for the Heat template portion of the work.
18:55:10 <daneyon_> As I have done with k8s, I will be posting other patches for the conductor, etc.. work
18:55:22 <daneyon_> anyone have a topic for discussion?
18:55:47 <daneyon_> If not, then we'll wrap things up a few minutes early.
18:56:06 <daneyon_> Thanks everyone for attending!
18:56:15 <daneyon_> #endmeeting