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