18:00:27 #startmeeting container-networking 18:00:29 Meeting started Thu Aug 27 18:00:27 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:31 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 18:00:33 The meeting name has been set to 'container_networking' 18:00:56 #link https://wiki.openstack.org/wiki/Meetings/Containers#Agenda 18:01:05 #topic roll call 18:01:09 o/ 18:01:15 o/ 18:01:17 o/ 18:01:18 o/ 18:01:22 o/ 18:02:08 Thank you dane_leblanc Tango suro-patz thomasem for joining 18:02:26 Lets wait until :05 for toher to join then we'll proceed 18:05:13 OK, let's move forward 18:05:16 #topic Review/Discuss Kuryr Design Spec 18:05:24 #link https://review.openstack.org/#/c/213490/ 18:06:23 Lets take until :15 for everyone to review the spec and reconvene 18:06:47 i'll be monitoring irc for any questions 18:07:12 But that doesn't mean I have all the answers ;-) 18:08:40 keep in mind the spec is a wip 18:09:44 So to visualize how we would use kuryr: would it be an option in the new --network-driver parameter? 18:10:13 as an alternate to something like "flannel" 18:12:53 Tango yes 18:12:59 and yes 18:13:06 Tango: That's what I would think, where magnum would then be issuing the 'sudo docker network create...' commands for Kuryr 18:13:19 and then pass any kuryr config params using labels 18:13:40 same approach for all network drivers 18:14:54 or the other option is to pass --network-driver libnetwork and specify libnetwork's native/remote driver using --labels 18:15:16 what option does the team prefer? 18:15:43 Sounds good, we probably need to experiment with it a bit to see what works 18:15:57 Tango agreed 18:16:22 anyone have question re: the kuryr spec? 18:16:37 i'm sure you need more time to dive into it 18:16:48 Please do so and provide you comments in the review 18:17:05 I'm a bit of a slow reader, so I'll just add comments as I see things. 18:17:17 They don't seem to mention performance, I wonder if that would be important to some users 18:17:25 as you can see from the spec, their are still a lot of questions that need to be answered and a lot of details that need to be sorted out. 18:17:41 However, I think it's headed in a good direction. 18:18:12 thomasem take your time. I just wanted to use this time to get the team moving forward with reviewing 18:18:25 yeppers 18:18:26 :) 18:18:43 Tango it should mention performance, so pls add a comment in the review 18:18:54 I'm wondering what the mental model is around handling OpenStack credentials here. 18:19:00 for the Magnum side of things 18:21:00 the spec references supporting Magnum use cases, where performance is a use case. However, it might be a good idea to be explicit in the spec 18:21:00 unless their is more discussion on the kuryr spec, I would like to move forward. 18:21:01 and I'll keep the kuryr spec on our agenda for next week b/c i think it's very important for us to stay involved. 18:21:01 #topic Review Kuryr Integration Brainstorming EtherPad 18:21:01 #link https://etherpad.openstack.org/p/magnum-kuryr 18:21:01 I have added a few add'l notes 18:21:25 the kuryr team called out keeping tabs on this etherpad during their irc meeting 18:21:54 the etherpad is a bit of a mess. It will get cleaned up soon. 18:22:38 thomasem their are some good notes related to auth in the kuryr integration brainstorming ep 18:22:46 looking now 18:22:51 thomasem thx 18:22:51 thank ya muchly! 18:23:17 lets have everyone review the etherpad until :35 18:23:30 I'll be monitoring irc for any questions 18:23:42 but let's try to keep as much as possible in the ep 18:24:19 pls put your handle under Contributors if you add to the ep 18:31:38 t- 4 min 18:36:14 OK, let's move on 18:37:05 We'll keep this topic for next week 18:37:40 i know we are all busy and it's nice having time during this meeting to dive into these efforts 18:37:48 #topic Review Action Items 18:37:58 * daneyon_ everyone to continue contributing to the kuryr/magnum networking integration etherpad 18:38:15 I have added to the ep and I know others have 18:38:19 pls continue to do so 18:39:02 Again, in the next week or 2, I'll start organizing the ep into actionable steps 18:40:04 #action danehans to take action next week on organizing the kuryr etherpad into actionable steps 18:40:13 an action for an action 18:40:16 crazy 18:40:21 * daneyon_ everyone review the kuryr design spec https://review.openstack.org/#/c/186617/ 18:40:35 I have reviewed and commented on the kuryr design spec 18:40:38 I know other have too 18:40:45 pls continue to do so. 18:40:57 those are the only actions from last week 18:41:01 #topic Open Discussion 18:41:15 I’ve been plugging away at the Magnum net spec bp’s and wip patches: 18:41:20 #link http://eavesdrop.openstack.org/meetings/container_networking/2015/container_networking.2015-08-20-18.00.html 18:42:33 daneyon_: Has anyone been able to step up to help cover that work? 18:42:34 i have a working setup where i can define --network-driver flannel or not specify a driver and the k8s coe uses flannel (b/c it's the default) using my wip patches 18:43:08 I have been turning my attention towards labels so we can pass in params to the driver 18:43:29 b/c without labels, only driver default settings will be applied 18:43:57 thomasem a few people have contacted me saying they are going to test the wip patches 18:44:04 Gotcha 18:44:08 It would be great if everyone could test 18:44:27 Will do 18:44:32 #action everyone test network-driver wip patches 18:44:38 #link http://eavesdrop.openstack.org/meetings/container_networking/2015/container_networking.2015-08-20-18.00.html 18:44:58 daneyon_: Great. Thanks. Just got some work moved off my plate recently, so going to take a stab at whether I can finally get some time to actually work on this stuff. 18:45:09 if you add to any of them, please make sure to include yourself as a co-author 18:45:11 And stop being *that* guy in the room. 18:45:31 adding the network-driver attribute was not too bad. Labels is a whole different story 18:45:41 lol 18:45:50 partially b/c magnum supports labels for pods 18:46:07 Well, are you wanting to include, like, validation and what-not for each driver? 18:46:09 1 moment pls 18:46:56 I am reviewing Glance code as a reference model for labels 18:47:25 Ah 18:47:36 Glance supports the --property attribute that appears to be very similar to what we're trying to accomplish with labels. 18:48:02 we need conductor to parse the labels being passed into heat parameters. 18:48:31 thomasem no worries 18:48:41 Heat has something similar also with --parameters 18:49:17 thomasem i would like to validate the driver being supplied. I believe someone provided a comment on that very topic 18:49:24 feel free to add 18:49:33 Gotcha 18:49:40 atm, i would like to keep my focus on the label support 18:49:54 Yeah... I mean even a straight pass through is better than nothing at this point. 18:49:59 Tango can you please provide a link 18:50:01 Fail-fast from validation is more a nice-to-have, really 18:50:06 :P 18:50:16 agreed 18:51:23 Tango if you can not find a link to what you;re referencing, pls send it to me by irc afterward 18:51:58 Yep, I used to work around this code in Heat 18:52:21 It will be easier to just pass along all the labels unparsed to heat and have heat fail the stack create if the labels are incorrect. But maybe I'm wrong.. just trying to investigate options 18:53:43 We are running near the end of the meeting. 18:53:54 Does anyone else have open discussion items? 18:54:10 Otherwise, we'll close early and get back to work :-) 18:54:38 OK 18:54:43 That's a wrap. 18:54:48 Have a great day! 18:54:57 Thanks! 18:55:14 #endmeeting