20:00:17 #startmeeting kolla 20:00:19 Meeting started Mon Nov 24 20:00:17 2014 UTC and is due to finish in 60 minutes. The chair is sdake. Information about MeetBot at http://wiki.debian.org/MeetBot. 20:00:20 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 20:00:22 The meeting name has been set to 'kolla' 20:00:23 #topic rollcall 20:00:27 hi folks \o/ ! 20:00:27 hi 20:00:27 here 20:00:36 hey 20:00:56 larsks around? 20:01:03 Yup! 20:01:07 cool 20:01:13 #topic milestone #2 - release today 20:01:38 https://blueprints.launchpad.net/kolla/milestone-2 20:01:56 looking over that list, we hve 2 in code review, 2 not started, 1 nearing code review 20:02:13 kube-trove-container will that make milestone #2? 20:02:20 I wseem to recall rhallisey indicating it was busted upstream 20:02:24 sdake, ya 20:02:33 ya its busted or ya i twill make i t? :) 20:02:42 it's busted 20:02:56 what is busted? 20:03:22 I talked to the guy who is writing a plugin for packstack 20:03:39 he is hardly able to deploy 20:03:52 rhallisey: a plugin for packstack to do what? 20:03:55 mostly because it is in a bad state 20:03:58 for trove? 20:04:01 i think in this case we should trust but verify - eg in the next cycle milestone #3, try to write our own version 20:04:02 for trove 20:04:04 got it. 20:04:05 sorry 20:04:25 maybe it doesn't work well for packstack but would work well for kolla 20:04:43 sounds good rhallisey? I have pushed it to milestone #3 then 20:04:44 it's not that packstack/puppet is the problem 20:04:54 he was saying that there was no one working on it 20:05:06 trove has no upstream? 20:05:08 and he was hitting bugs from trove every step of the way 20:05:31 sdake, I believe it does, but I think the participation is lacking 20:05:44 ok well thats a bit of a problem for openstack in general 20:05:46 lets do this 20:05:50 lets try to make it work for milestone #3 20:05:52 if it doesn't work 20:05:56 sdake, sure 20:05:58 lets blast the ML with the problems 20:06:05 along with bug reports 20:06:19 can't expect the trove upstream to mindread their way into fixing t he bugs without being told what they are :) 20:06:28 neutron - daneyon I saw your patch, but it needs a rebase 20:06:33 sdake, agreed :) 20:06:50 sdake: correct. I need to rebase neutron and nova-network patches. i will do that later today. 20:07:00 cool 20:07:01 I also need to rebase 20:07:11 larsks: both patches require the heat-kube PR i submitted. 20:07:12 horizon is in "needs code review" but I didn't see the patch in the review queue 20:07:29 sdake: I got nothin'. I'm not sure why the bp has that status. 20:07:30 larsks: let me know if you need me to make any changes to the kube-heat PR to get it accpeted. 20:07:52 daneyon: i will try to revisit that today. i've been focused on non-kolla things for the past week. 20:07:52 sdake, 'Horizon container implementation' 20:07:57 daneyon: sorry! 20:08:04 sdake, not there for you? 20:08:10 larsks: no worries at all. i know the feeling. 20:08:14 rhallisey do you ahve a link? 20:08:22 https://review.openstack.org/#/c/135773/ 20:08:33 cool that leaves swift and sahara 20:08:36 sahara should be done today 20:08:46 i've also been locked into working on magnum for the last week to get things rolling there 20:09:00 so haven't spent much time on containrizations :) 20:09:00 nice 20:09:17 cool thing about a magnum implementation is then we have an easy pat hto tripelo integration 20:09:37 so given that we are all in the "need couiple more days to finish" 20:09:41 all, it may be a good idea for others to review my hat-kube PR and provide feedback or just be aware of the changes #link https://github.com/larsks/heat-kubernetes/pull/8 20:09:42 and thanksgiving is thursday/friday 20:09:51 should we jsut shoot for wednesday for a release? 20:10:04 wed Nev 26th 20:10:10 that provides 2 days 20:10:24 to sort out the pR,s rebases, etc 20:10:36 +1 20:10:56 sounds good 20:10:59 * larsks abstains 20:11:02 cool 20:11:08 larsks can you sort ou tt hat PR for daneyon by then? 20:11:11 I think he is blocked on that 20:11:24 or does a release just before the break loose its wow factor??? 20:11:26 See my comment above @ 15:07:51 20:11:49 I think with the break nobody is going to be looking at a new release... 20:12:06 yeah agreed on waiting until after the break 20:12:15 Dec 2nd it is then 20:12:18 that's true 20:12:32 then that gives us the whole break to do more work... not. 20:12:48 I'd just like to get what is in the blueprint queue done by edec 2 ;) 20:12:58 agreed 20:13:06 #topic open items 20:13:11 so normally I'd discuss milestone #3 20:13:17 but lets wait until our next meeting to see where that stands 20:13:20 given that christmas is coming up 20:13:22 anjd the new year 20:13:29 i think dec will be a pretty light month for us 20:13:35 downside of starting a project in november :) 20:13:44 normally IS tart in april, but it had to be done when it had to be done :) 20:14:07 any open discussion folks woould like to have? 20:14:40 nope, lets just get ML2 knocked out. 20:14:43 I have one item... 20:14:55 larsks is on deck fire away 20:15:24 The "flannel" project now has a vxlan backend. I want to look at that as a replacement for my own hacked up thing in the heat templates. 20:15:42 Not directly kolla related, I guess, but I wanted to mention it. 20:15:49 cool 20:15:50 It looks like the atomic folks are going to go with flannel, too. 20:15:51 sounds handy 20:16:04 (For kubernetes networking) 20:16:30 then i also need to make sure the docker-spotter stuff used for multi-interface networking works w/flannel too. 20:17:06 daneyon: I will ping you before I move anything into master. 20:17:13 sounds like flannel might be a solid bp for milestone #3 20:17:43 larsks: i assume flannel does not have a docker multi-interface solution. Do you know??? 20:17:56 larsks if you are upt o it, might consider filing a blueprint against m3 for it so folks know who is doing what 20:18:01 daneyon: no, it does effectively the same thing I was doing with linkmanager 20:18:08 (but using the kernel vxlan module rather than OVS) 20:18:16 sdake: I will do that. 20:18:22 thanks larsks 20:18:30 +1 for using kernel over OVS 20:19:03 larsks: wouldn't it be easy to mod linkmanager to do the same though? 20:19:27 daneyon: well, maybe, but I would rather use a project like flannel with actual maintainers and use beyond our little corner of the woods... 20:19:39 +1 to that 20:20:20 what about trying to get a better solution in k8s? 20:20:48 any discussion about using linkmanager as a basis for multi-host networking in k8s? 20:21:13 it seems linkmanager is very much inline with the k8s vxlan stuff. 20:21:50 daneyon: I'm not sure that linkmanager is really any different from flannel in terms of functionality (other than being less well written). 20:22:03 #link https://github.com/GoogleCloudPlatform/kubernetes/blob/master/docs/ovs-networking.md 20:22:09 Hold on, let me find a docker issue that is interesting to this... 20:22:33 Okay: 20:22:51 Read through this to see where docker is thinking of going in terms of more flexible networking support... 20:22:53 https://github.com/docker/docker/pull/8216 20:23:14 I will bet that any kube changes are going to wait on that. 20:23:26 ("That" meaning "the whole question of docker networking getting resolved"). 20:23:35 #link https://github.com/docker/docker/pull/8216 20:23:37 There. 20:23:58 i'm all over the different docker proposals for networking that have surfaced over the last 2 weeks, including the one you mention. it appears the 8216 pull is hitting a dead end with shykes. 20:24:24 daneyon: Right. But the discussion there re: the future of networking (e.g., the use of docker plugins) is I think the relevant part. 20:24:59 The vxlan link @ https://github.com/GoogleCloudPlatform/kubernetes/blob/master/docs/ovs-networking.md is pretty much what I used as a reference when writing linkmanager :) 20:25:05 docker is getting ready to make some changes to networking using a plugin model and possible add default networking using OVS or kernel vxlan + add'l tools 20:25:24 That's what the vagrant setup does...but using flannel gets you to approximately the same place, other than the kernel/ovs difference. 20:26:07 with all that is going on with docker networking, what is the k8s team doing? It would be good for them to incorporate something like linkmanager. 20:26:55 I don't know. The k8s upstream folks seem focused largely on integration with GCE, in which these solutions are not necessary. But I have not followed any upstream discussions around this point... 20:27:27 since k8s is a big part of what we're doing (at least for the time being, I just want to make sure what ever networking change we decide is consistent with the direction of the k8s project. 20:27:46 daneyon that makes sense 20:27:59 on that ponit and magnum, it apperas magnum may end up being a wrapper around k8s 20:28:11 sdake: \o/ 20:28:13 so what is good for k8s is good for magnum from what I can tell 20:28:20 i would like to see step 1 that we create a proposal PR with the k8s repo. 20:28:57 that suggests using a tool (either flannel or a form of linkmanager) to support their ovs/vxlan networking use case. 20:29:13 daneyon: not linkmanager. 20:29:18 daneyon: no no no no 20:29:19 I think it's important that we have an open discussion with the k8s team to understand where k8s networking is going. 20:29:20 :) 20:30:03 I'm fine with going flannel, just want to avoid making another change in direction in weeks or months if the k8s team is headed in a diff direction. 20:30:04 open discussion 20:30:09 * sdake tears flesh from bones 20:30:14 haha 20:31:04 does it make sense to open a proposal PR with k8s team similar to the model Docker has created? 20:31:15 daneyon: similar to which model? 20:31:49 let me find the link, but Docker has started to put together some steps for submitting proposals to the docker project. 20:33:13 this allows us to create a PR with the title Proposal: XYZ Networking and our ideas to expand multi-host k8s networking using flannel. If they disagree, then it gives us an indication that they are headed in a diff direction. 20:33:54 docker proposal #link https://github.com/docker/docker/blob/master/CONTRIBUTING.md#design-and-cleanup-proposals 20:34:04 daneyon: I think that is in general a good idea, but I guess I would start just by asking on the mailing list if there are already existing plans in that direction. 20:35:01 sounds like a good first step. do you want me to do that or you? 20:36:39 * sdake votes daneyon as the sacrifial lamb since your the networking guru here :) 20:36:45 I don't have a strong preference...how about you do it, and I will comment. 20:36:52 you can actually have a conversation back and forth :) 20:36:55 will do 20:37:02 daneyon: Cc: me on the post... 20:37:17 will do 20:37:34 cool well I thin kwe bea tthe networking future into the ground, is there any other open topics folks would like to discuss? 20:37:45 I'm all out. 20:38:14 are you ok if i ask the question on the google-containers irc channel? 20:38:59 \wfm 20:39:04 irc is good too 20:39:07 daneyon: I would slightly prefer the ml, if they have one. 20:39:17 ya ml is good - but they use google groups iirc 20:39:26 Eh, whatever. Ask on IRC :) 20:39:37 OK, I'll start there. 20:39:40 IRC 20:40:06 cool any o ther open topics? 20:40:17 if not, i'll end the meeting in 60 seconds :) 20:40:49 #endmeeting