18:00:56 #startmeeting container-networking 18:00:57 Meeting started Thu Sep 10 18:00:56 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:58 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 18:01:00 The meeting name has been set to 'container_networking' 18:01:05 Agenda 18:01:10 #link https://wiki.openstack.org/wiki/Meetings/Containers#Agenda 18:01:32 The agenda has been slightly modified from our last 2 meetings. 18:01:42 #topic roll call 18:01:47 o/ 18:01:56 Ton Ngo 18:02:00 Stephen Wong 18:02:39 Thank you hongbin Tango s3wong for attending the meeting. 18:02:45 o/ 18:03:06 Looks like we have a light crowd and today's meeting should go quick. 18:03:20 thomasem thanks for joining. 18:03:30 #topic Discuss Kuryr Design Spec 18:03:36 o/ 18:03:50 instead of diving into the spec, i want to have a quick discussion on the spec. 18:04:02 Hey adrian_otto, thanks for joining. 18:04:16 * adrian_otto nods 18:04:30 In general, i think the Kuryr spec is getting close. 18:04:49 I'm getting ready to give it a +1 18:05:20 I think their is still grey area on what the project is trying to solve 18:06:03 Their appears to be a focus on Docker using libnetwork, but the spec contains several references to areas that fall outside of libnetwork's responsibilities. 18:06:39 did you call each out using in-line comments? 18:06:46 The spec is not meant to be perfect, but I think it has helped to shed light on the direction of Kuryr and the spec can be fine tuned in the future 18:06:56 adrian_otto I did 18:07:11 adrian_otto I think our group has done a good job of providing feedback on the spec 18:07:26 good 18:07:41 I think we've had at least 4-5 people provide comments and we have helped shape the spec throughout the 5+ patch sets 18:08:03 Does anyone have any questions or feedback on the spec? 18:08:48 I am awaiting for my feedback to get addressed in the latest patch set 18:08:58 my advice when you are about to vote on something like this is not if the spec is perfect, because it's not an implementation, but ask yourself are we better off with this, or without this? Is there anything in here I simply can't live with? 18:09:00 If and when it does, I am planning on providing a +1 vote. 18:09:16 I think unless something else pops up, the next patch should be good to go 18:09:20 and if it's pretty good, then let's merge it, and focus more energy on the implementation 18:09:56 I would like everyone to perform a review. Please indicate what you need for a +1 if you feel like something is missing 18:10:04 I do recognize this is not one of Magnum's repositories 18:10:05 otherwise, please provide your +1 vote 18:10:33 yes, thanks daneyon_ 18:11:16 adrian_otto agreed, I would just like to show our support for the spec. Several team members spent a good amount of time performing reviews, so let's bring this one to the finish line 18:11:31 and thanks again for taking the time to review the spec 18:11:40 I know we all have a lot on our plate 18:11:55 #topic Discuss Kuryr Integration Brainstorming EtherPad 18:12:01 #link https://etherpad.openstack.org/p/magnum-kuryr 18:12:42 I have a meeting schedule with gsagie on Monday to clean-up the ep and create actionable steps to move the integration forward. 18:13:02 I plan to keep the meeting between gsagie and I to get this job done. 18:13:15 Please speak up if you have issues with this approach. 18:13:34 The output will be an organized ep, filed bp's, etc.. 18:13:56 any questions or feedback on this topic? 18:14:15 ok, then let's move on. 18:14:20 #topic Discuss Magnum Container Networking Model Patches 18:14:30 I’ve been plugging away at the Magnum network spec patches: 18:14:33 #link https://review.openstack.org/#/c/214762/ 18:14:37 #link https://review.openstack.org/#/c/214909/ 18:14:40 #link https://review.openstack.org/#/c/215260/ 18:14:43 #link https://review.openstack.org/#/c/217888/ 18:14:56 I have a functioning environment using the patches 18:15:41 Do you have 5 BP's? 18:15:42 I can create a baymodel that uses the k8s coe, flannel network-driver and --labels to pass in flannel config parameters such as cid, subnetlen, use_vxlan 18:16:02 Tango... that's a good question :-) 18:16:11 I need to double check. 18:16:50 I have combined the client net-driver and labels into a single patch, so maybe that's why I'm missing one 18:16:59 Let me take 2 minutes to verify 18:17:21 ah ok, just making sure I didn't miss any :) 18:18:55 Looks like i combined the conductor and baymodel api work into a single patch 18:19:03 #link https://blueprints.launchpad.net/magnum/+spec/conductor-template-net-update 18:19:15 #link https://blueprints.launchpad.net/magnum/+spec/extend-api-network-attributes 18:19:28 sounds good 18:19:55 those 2 bp's = https://review.openstack.org/#/c/214909/ 18:19:57 #link https://review.openstack.org/#/c/214909/ 18:20:23 currently, all my work has focused on k8s 18:21:12 should i include mesos and swarm out of the gate or use separate patches to add net-driver and labels to those? 18:21:37 better in separated patch to make it easy to review 18:21:48 +1 18:22:03 I lean towards separate patches so the community can start kicking the tires. 18:22:41 adrian_otto do you have a preference? 18:24:56 #agreed net-driver and labels will initially support k8s and separate patches will be used to extend support to mesos and swarm. 18:25:21 ok, a little more info on the state of the patches.... 18:25:33 as i mentioned, net-driver and labels work 18:25:57 I am updating the net-driver code to perform validation of the net-sriver value (i.e. flannel). 18:26:42 so if the client supplied network-driver=foobar, the api will validate and provide an error back instead of heat providing the error during the stack create 18:26:52 please speak up if you have any issues with this. 18:27:17 as add'l drivers get supported, the validation will need to expand 18:27:53 So all drivers will be loaded when the conductor starts? 18:28:03 i am also going through the review comments of the different patch sets to make sure i address everyone's feedback... I was busy just trying to get things working first. 18:28:50 Tango all driver-related heat params will get initialized when conductor starts. 18:29:21 ok, so to add a new driver, we need to restart the conductor 18:29:51 here is an example: 18:29:55 #link https://review.openstack.org/#/c/217888/5/magnum/conductor/template_definition.py 18:30:46 as part of initialization, baymodel labels get loaded just like bay/baymodel attr's 18:31:29 Tango when net-driver validation is complete, the api services will need to get reloaded too 18:31:40 Tango make sense? 18:31:47 any issues with that? 18:32:24 ok, sounds reasonable, since we expect the cloud provider to do this work 18:33:19 it took me a while to fully wrap my head around how template_definition.py works 18:33:48 any other questions or concerns about the WIP patches? 18:34:00 I also need to updates some of the tests. 18:34:37 Since we agreed on not supporting swarm/mesos in these patches, I am hoping to remove WIP in the next 2 days. 18:34:59 #topic Review Action Items 18:35:02 why did we agree to that? 18:35:07 * daneyon_ everyone to spend additional time reviewing the kuryr design spec in more detail 18:35:55 I completed that ask, and submitted my vote. 18:36:43 adrian_otto scrolling back up, 1 moment 18:37:02 simplify the reviews 18:37:06 make them smaller 18:37:12 get the code merged quicker 18:37:25 get the community using the features quicker 18:37:33 then there should be a separate WIP review for each bay type 18:38:14 adrian_otto agreed. my intension is to create WIP reviews for the follow-on bay types (swarm and then mesos) 18:38:20 we can not, for example, only implement labels only in the k8s bay type without a concrete plan to also support hem in the other bay types as well. 18:38:48 I think porting the implementation to other bay types is easy 18:38:51 adrian_otto agreed. labels and network-driver will be supported in all. 18:38:58 once we agree how to do that in k8s 18:39:09 do we have a BP for each bay type, or one BP for all? 18:39:29 I think the general feeling was to make the reviews small, focused, etc.. 18:40:04 Trying to take down all 3 bay types in the current patches can mean lots of lines to comb through 18:40:12 yes, I like that, but I'm worried about losing sight of a consistent suer experience across different bay types. 18:40:37 I wanted to be sure we cover that base so we don't slip in a feature that does not get done in all the bay types 18:40:53 adrian_otto one BP for all... I need to double-check if the BP addresses the bay types... if not, i'll add it 18:41:08 ok, and are your linkt to that BP 18:41:20 partially implements 18:41:29 so when WIP is removed, I will make sure it indicated partially addressing the associated BPs 18:42:05 adrian_otto understood. I don;t see the job being done until network-driver and labels is supported across all the bay types 18:42:24 i'll make sure the reviews indicate partially addressing the BP's 18:43:07 for example, the commit message on https://review.openstack.org/217888 needs more explanation of that approach 18:43:21 adrian_otto completely agree the feature needs to address all bay types. You have my commitment that net-driver and labels will get implemented across all bay types 18:43:33 great, we are on the same page. you can move on now. 18:43:57 Unfortunately, many features are inconsistent across bay types right now. We will need several BPs to sync them 18:44:01 I don't want my name associated to half baked work products 18:44:43 adrian_otto all commit msgs will be updated when I remove WIP. 18:45:08 hongbin and adrian_otto this is a good point you bring up 18:45:26 Do you know off hand if this is a discussion topic for the DS? 18:45:36 If not, I +1 the topic 18:45:46 I willneed to look 18:45:59 what is DS? 18:46:07 Providing an inconsistent experience across bay types can provide users headaches 18:46:23 DS=design summit 18:46:31 daneyon_: I see 18:47:02 OK, back to the topic of action items 18:47:10 * daneyon_ everyone to spend additional time reviewing the kuryr design spec in more detail 18:47:19 we covered this a bit ago 18:47:32 pls perform your final review(s) 18:47:48 and indicate what you need to +1 the spec... otherwise +1 it ;-) 18:47:57 * daneyon_ everyone to review the kuryr/magnum integration etherpad in more detail. 18:48:31 ^ get your final thoughts, feedback, etc.. into the ep because gsagie and I are going to clean it up on Monday 18:48:43 * daneyon_ danehans work with gsagie to organize the integration ep before next meeting 18:49:09 ^ Again, this will be done on Monday. We will use next week's meeting to review the cleaned-up ep. 18:49:18 * daneyon_ everyone test network-driver wip patches 18:49:27 Pls speak up if you have tested the patches 18:49:55 I know dane_leblanc and 1 other person have successfully tested the patches, so I'm feeling pretty good about them. 18:50:07 * daneyon_ danehans to coordinate with kuryr team on a design summit session. 18:50:17 I spoke with gsagie about this action 18:50:57 They are still working through the details, but they are expecting to have a session at the DS and would like our participation. 18:51:10 I will carry this forward until we have something concrete 18:51:33 Are their session not overlapping with ours? 18:51:56 adrian_otto have the details been finalized for our DS sessions? 18:52:14 Tango I'm not sure. Is this what you have heard? 18:52:30 I don't know either, just checking 18:53:18 Tango: gsagie told me they are still working through the details of the DS sessions and could not provide any specifics or commitments. 18:53:46 ok 18:53:51 #action danehans to continue coordinating with gsagie on a combined kuryr/magnum design summit session. 18:54:05 that's it for action items 18:54:16 any questions on the action items? 18:54:41 otherwise we have just a few minutes for open discussion 18:54:48 #topic Open Discussion 18:55:14 I wonder if any thing news from the kuryr team 18:55:55 daneyon_: Do they have a meeting last week? 18:56:01 hongbin unfortunatly I was unable to attend the kuryr virtual sprint the last 2 days. 18:56:10 I see 18:56:28 Just wonder what is the sharp of the project 18:56:33 never mind 18:56:57 Looks like they met on Monday 18:56:59 #link http://eavesdrop.openstack.org/meetings/kuryr/2015/ 18:57:23 #action everyone to take a few minutes reviewing the 9/7/2015 kuryr meeting logs 18:57:38 hongbin thanks for bringing it up 18:57:46 Monday was a US holiday 18:57:59 and i've been trying to stay focused on bringing the WIP patches home 18:58:33 OK, so please take a few minutes to review the Kuryr meeting logs 18:58:46 Thanks for joining today's meeting! 18:58:58 #endmeeting