16:00:18 #startmeeting Kosmos 16:00:19 Meeting started Tue Oct 6 16:00:18 2015 UTC and is due to finish in 60 minutes. The chair is mugsie. Information about MeetBot at http://wiki.debian.org/MeetBot. 16:00:20 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 16:00:23 The meeting name has been set to 'kosmos' 16:00:26 O/ 16:00:28 o/ 16:00:40 give people a few minutes to file in ... 16:00:57 Walking into office myself. Post flu shot. 16:01:02 o/ 16:01:14 dougwig: ouch. I had to stop getting them 16:01:33 o/ 16:01:36 o/ 16:01:46 i think thats quorum 16:01:51 #topic Action Items from last week 16:02:02 ALL Review arch spec 16:02:11 #link https://review.openstack.org/#/c/223663/ 16:02:23 there was a flurry of reviews yesterday :) 16:02:31 I started a trend 16:02:37 so we can call this done I think ... 16:02:40 yeah, of -1s 16:02:45 :D 16:03:03 #topic Architecture 16:03:06 Well, we should talk about the pools 16:03:17 #link http://docs-draft.openstack.org/63/223663/3/check/gate-kosmos-specs-docs/2e30f04//doc/build/html/specs/liberty/sysarch.html 16:03:27 yeah, that was in the sub items for the arch 16:03:57 for those who didnt see my last comment on https://review.openstack.org/#/c/223663/ 16:04:07 One question that has occurred to me ... 16:04:07 Do we need pools? 16:04:07 My understanding is that pools are to allow multiple (IP L3 port numbers, not neutron) ports on a single LB. 16:04:10 For 99% of GLB solutions we just route traffic to an IP for *all* port numbers (by the very nature of GLB - it is usually DNS, or in some cases anycasting) 16:04:13 So, can we simplify this, by adding members directly to a lb? Or am I sleep deprived and missing something? 16:04:56 mugsie: the pool is a good spot to collect the lb algorithm, hang monitors, etc. 16:05:17 I was wondering about the relationship between pool and monitor 16:05:22 you can do that directly in the front-end object, yes, but then you can't reuse pools 16:05:38 sure, but my question is, how would multiple pools work? or do we make it a single pool per lb? 16:05:57 dougwig: re use is a good point 16:06:27 It seems like monitors should be a child of the pool 16:06:47 In the reuse case you would have multiple monitors hitting the endpoints 16:06:59 so, adding a pool_id to the loadbalancer,. and removing the join table, and move monitors to the pools? 16:07:20 that'd be my vote, yes. 16:07:29 My vote would be move monitor to pools 16:08:00 johnsom: and keep multiple pools per LB? 16:08:33 At the moment I can't think of a good use case for multiple pools per lb 16:08:58 i would go M:1 for lb:pool, which implies pool_id in lb. i don't see much use yet for M:N there. 16:09:07 cool. 16:09:10 I guess only if you want to monitor some endpoints differently than others, but that is strange 16:09:16 any other thoughts from everyone? 16:09:23 johnsom: that'd be a second pool, i'd think. 16:09:50 if I get these up by end of day today, can we try and merge this week? 16:09:58 Yes 16:10:01 (unless there is more issues of course) 16:10:07 the GSLB that we use in the real use case has mostly 1-1 bwtween loadbalancer and pool 16:10:10 If you don't see my vote, nag 16:10:17 ditto 16:10:22 will do 16:10:33 KunalGandhi: great. looks like we are converging 16:10:44 #topic Billing Model 16:11:12 so, last week people brought up the idea of "billing per DNS request" 16:11:37 Yes 16:11:48 I dont think we will have a complete idea this week, but can people think about if this is the only model? 16:12:12 as if we want to do that, we will need to go annoy the designate ptl 16:12:20 and he is a real pain to deal with :) 16:12:47 billing per load balancer, billing per regional vip ? 16:12:48 we really need our operators to speak up on this one. i don't think enterprises or vendors care much. 16:13:02 (designate made a policy decission last year *not* to support DNS query stat collection) 16:13:22 mugsie: can you share background on why not? 16:14:06 cost of doing the actual collection, cost of transforming the data, and the complexity of matching DNS Request logs to projects 16:14:38 by running something in front of bind to collect the data, it can halve the through put of thaty DNS server 16:14:55 I guess there are two billing options that come to mind for GSLB: 1. flat rate (you have one) 2. per query processed. Are there others? 16:14:57 i can see that logging could be more expensive than a udp query. 16:15:07 and for designate there was a massive complexity in how we would do it for multiple DNS servers 16:15:21 how does route 53 bill? i can look it up if no one knows off the top of their head. 16:15:33 flat + queries 16:15:38 afaik 16:15:52 wouldn't monitoring queries be dependent on the dns server backend? 16:15:59 elarson: yup 16:16:03 zones + health checks + queries + geo queries 16:16:06 had to google it 16:16:39 sounds like it would be up to an operator then to find a way to do that then 16:17:05 for example proxy in front with logs that get pushed and analyzed 16:17:23 yeah, but designate would have to have a consistant API for us to collect that data into Kosmos, or they would have to add it to the kosmos bill later 16:17:45 but, I think this does need further thought 16:17:53 indeed 16:18:31 come back to this in a week or so? 16:18:46 right, I'm saying it doesn't seem to be something supportable by the API. but +1 on more thinking about it 16:18:55 mugsie: maybe this is a good f2f topic for the summit. 16:19:02 yeah 16:19:03 pull in some designate folks. 16:19:32 yeah, i think we can get them in a room / hallway 16:19:40 #topic Open Discussion 16:19:44 pub... 16:19:59 on that note - who is going to be in Tokyo? 16:20:06 o/ 16:20:10 I will be attending 16:20:11 me 16:20:27 We do not have offical summit time, but we can rob tables in the hallway etc 16:20:53 cool. we should arange to sync during the week then 16:21:21 and I need to go hunt down the neutron PTL, and figure out midcycle dates - watch this space for that 16:21:26 agreed. or arrange an evening social thing. or both. 16:22:02 yeah, definitly 16:22:09 any other off agenda topics? 16:22:09 Sounds good. I also plan to have a small section in the LBaaS and beyond talk to introduce Kosmos 16:22:27 good. 16:22:39 we did a short intro of it at the silicon valley "summit" as well. 16:22:53 * elarson plans on eating lots of sushi... if anyone was curious ;) 16:22:55 great :) 16:22:58 Cool, slides to donate? 16:23:24 we did it etherpad style. 16:23:31 Ok 16:23:34 let me dig it out, for content at least. 16:25:15 OK, any other topics? 16:25:39 I have a few crazy ideas floating around, but I need to clarify them in my own head 16:25:50 scotch can help order thoughts. 16:26:12 +1 16:26:29 scotch?? Your telling an irish man to drink scotch? :P 16:26:40 dougwig is cruel 16:26:45 we make pretty good whiskey ourselves :D 16:26:49 if your country made better whisky, i'd say otherwise. 16:26:53 mugsie: fine, I'll drink it. 16:26:58 also for mid cycle can we combine that withe the L4-L7 midscycle? 16:26:58 :) 16:27:04 dougwig: harsh :) 16:27:12 xgerman: where is that? 16:27:19 TBD 16:28:15 OK. will sync with people on the mid cycle front 16:28:36 #action mugsie start mid cycle planning 16:28:53 ok, people want 30 mins back? 16:29:22 silence is agreement 16:29:24 Sounds good to me 16:29:28 #endmeeting