16:01:34 <dougwig> #startmeeting gslb
16:01:35 <openstack> Meeting started Tue Jun  2 16:01:34 2015 UTC and is due to finish in 60 minutes.  The chair is dougwig. Information about MeetBot at http://wiki.debian.org/MeetBot.
16:01:36 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
16:01:39 <openstack> The meeting name has been set to 'gslb'
16:01:42 <dougwig> #topic Intro
16:01:50 <dougwig> hiya folks, who all is here for the GLB meeting today?
16:01:51 <xgerman> o/
16:01:54 <Kiall> Heya
16:01:54 <mugsie> o/
16:01:57 <jmcbride> o/
16:01:57 <timsim> o/
16:02:00 <dougwig> #chair Kiall
16:02:01 <openstack> Current chairs: Kiall dougwig
16:02:07 <KunalGandhi> o/
16:02:10 <vivek-ebay> o/
16:02:26 <rjrjr_> o/
16:02:27 <Kiall> Not too bad a turnout :)
16:02:50 <Kiall> dougwig: want to get things started?
16:02:59 <Santosh_NS> Hi All
16:03:00 <dougwig> nice.  anyone have an agenda, or should we just discuss use cases/interests of those attending?
16:03:18 <Kiall> I reckon we start with Intros, since lots of people here don't know each other..
16:03:37 <mugsie> KunalGandhi: you sent the inital email - do you have an overview of what you were thinking?
16:03:42 <KunalGandhi> Yes.. we can go over the interests and use cases.. we might want to start with a GLB intro
16:03:48 <Kiall> I'll go first.. Kiall, PTL for the Designate DNS service.
16:03:55 <KunalGandhi> ok
16:04:10 <Kiall> (with HP btw ;))
16:04:18 <mugsie> Graham: designate-core
16:04:30 <vivek-ebay> Vivek from eBay/Paypal. work on LBaaS solution
16:04:32 <KunalGandhi> Go ahead Kiall..
16:04:32 <timsim> Tim: designate-core (Rackspace)
16:04:37 <dougwig> i'm dougwig, services rep for neutron and lbaas, and also representing A10, so watch me juggle my open-source and vendor hats.
16:04:55 <KunalGandhi> Kunal Gandhi from eBay/PayPal. LBaaS solution
16:05:01 <jmcbride> Joe McBride, Rackspace
16:05:03 <johnbelamaric> John Belamaric from Infoblox
16:05:11 <Kiall> xgerman: still on? ;)
16:05:19 <xgerman> yep
16:05:24 <rjrjr_> Ron from eBay/PayPal.  Work on Designate.
16:05:38 <xgerman> German, HP, Octavia core, work on LBaaS
16:06:16 <mugsie> ok then, KunalGandhi do want to give the overview? I think that is everyone
16:06:18 <Kiall> Okay, Intro's out of the way! KunalGandhi / dougwig - as mugsie said, you guys kicked this off - so want to give some intro on you're initial thoughts/ideas/use-cases?
16:06:33 <dougwig> #topic Use cases
16:06:34 <Santosh_NS> Santosh Citrix NetScaler
16:06:38 <KunalGandhi> I can start.
16:06:39 <dougwig> KunalGandhi: want to get this started?
16:08:18 <KunalGandhi> So as mentioned in the email, we would like to work with the community on adding GLB API's to LBaaS.
16:09:00 <Kiall> #link http://lists.openstack.org/pipermail/openstack-dev/2015-May/064617.html
16:09:01 <KunalGandhi> So currently we added API's to our home-grown solution, which includes managing GLB entities like Global Name, Pools and Members on the Global Load Balancer
16:09:05 <barclaac> Do you have any ideas on what you'd like the API to look like?
16:09:11 <dougwig> a quick level-set on global server load-balancing (GLB or GSLB), which is basically the front-end being DNS, and the back-end being the more traditional load-balancing stuff of health-monitoring, performance monitoring, geo-location, fastest connection, lightest loaded, highest cost, etc..
16:09:20 <dougwig> does that differ from what anyone else is expecting?
16:09:53 <Kiall> dougwig: sounds about right to me.
16:09:56 <barclaac> We should also make sure that we could handle geo-lb based on either src IP or BGP reachability of the DNS server
16:09:57 <KunalGandhi> The GLB entities also has some LB like stuff - health monitoring etc
16:10:05 <ekarlso> o/ btw
16:10:14 <barclaac> not saying we'd implement but don't have the API be incapable
16:10:16 <KunalGandhi> @barclaac .. I agree
16:10:50 <Kiall> since barclaac missed the intro's.. Alex is dev manager for the HP DNS and LB teams.
16:11:13 <barclaac> Kiall puts up with me so well ;-)
16:11:32 <KunalGandhi> So i wanted to understand the designate side of this.. Can someone help me explain that ?
16:11:49 <Kiall> KunalGandhi: sure.. I guess I can explain where I see Designate fit here.
16:12:06 <KunalGandhi> @Kiall .. ok.
16:12:07 <mugsie> KunalGandhi: I feel that (at least initially) there won't be much custom Designate work
16:12:31 <mugsie> i think the API will orchestrate GSLB via the Designate API
16:12:55 <mugsie> using what we have currently
16:13:00 <Kiall> So, as dougwig mentioned.. GSLB typically starts with DNS out front - often embedded in the GSLB platform itself. This is done to allow for automation on the DNS zones where, in a typical IT environment, the best automation you can do on DNS is a ticket with IT.
16:13:22 <KunalGandhi> So the main GLB API to do health monitoring, geo-lb, etc would sit in LBaaS right ?
16:13:32 <Kiall> DNS zoned for GSLB tyically have a very low TTL, 5 min or under, and list out all the GSLB frontends. Sometimes combined with Geo-IP.
16:13:39 <barclaac> I'm thinking it's a new endpoint.
16:13:44 <dougwig> let's worry about where the endpoint lives later, and just talk about what each piece is likely doing right now.
16:13:47 <barclaac> I'm not sure the neutron API server would want to know that
16:13:48 <Kiall> dougwig: ++
16:14:22 <mugsie> KunalGandhi: Geo-IP is on the designate road map, but not in this cycle ... there is a lot of work to do around it
16:14:41 <Kiall> So, as far as Designate is concerned, ideally, the LBaaS piece which provides monitoring, multi region LB endpoints etc, is simply a client to Designate.
16:15:06 <dougwig> mugsie: i think the first step is an interface; designate doesn't have to implement it all.
16:15:15 <mugsie> dougwig: ++
16:15:19 <xgerman> ++
16:15:21 <KunalGandhi> @dougwig .. so the LBaaS Piece is responsible for Global entities and Health monitoring etc.. what would the designate piece reponsible for ?
16:15:27 <Kiall> i.e. it would be manipulating the zone as needed, similar to how traditional GSLB products do it with their "internal DNS" servers.
16:15:49 <mugsie> KunalGandhi: serving the DNS entries, and updating the zone
16:16:08 <xgerman> but DNS would need to monitor the health of the regional LBs?
16:16:11 <KunalGandhi> @mugsie .. makes sense
16:16:37 <KunalGandhi> xgerman: GLB's will be able to monitor the reginal LB's
16:16:43 <mugsie> xgerman: that should be part of the GLB service
16:16:47 <xgerman> ok
16:16:52 <mugsie> ah, what KunalGandhi said :)
16:16:54 <KunalGandhi> xgerman: It might also depend on vendor impl as well..
16:16:59 <Kiall> mugsie: ++, I see GSLB's requirement to have a DNS server embedded as fix for DNS servers not having a "standard API"
16:17:12 <Kiall> Which, in the context of OpenStack, we have via Designate.
16:17:25 <dougwig> putting on my a10 hat, we offer three operating modes at the dns level.  the first is being the DNS master, the second is being a delegated master, and the third is being a proxy in front of the DNS master, munging packets on the fly.  designate could do any or all of those in this context.
16:18:29 <mugsie> ok. We could do the first 2 today, but not the 3rd
16:18:50 <KunalGandhi> @dougwig .. where does GLB fall under this ?
16:18:53 <dougwig> the third is for retrofitting into legacy deployments, so i'd wager it's way less relevant here.
16:18:58 <Kiall> Okay, everything there bad the proxy layer effectivly exists in Designate. I suspect that proxy layer is an unusual usecase, or something to bring to the next Designate specific meeting?
16:19:02 <mugsie> but, for the GSLB to work properly, we should be the a master
16:19:16 <xgerman> ok
16:19:16 <mugsie> s/the//
16:19:32 <xgerman> so GSLB drives designate and LBaaS
16:19:43 <mugsie> xgerman: yup, i think thats what we are linking
16:19:47 <mugsie> thinking*
16:20:44 <mugsie> right. The question is then is GSLB a global service (like keystone) that orchestrates all of this?
16:20:53 <Kiall> Let's circle back a tad, the typical GSLB model looks like this DNS -> GLB(s) -> Regional LB(s). It's clear where the first and last piece lives, Designate and Neutron-LBaaS/Octavia respectivly. The new piece is that guy in the middle, right?
16:21:04 <mugsie> or is there another delpoyment model i am missing?
16:21:39 <KunalGandhi> xgerman: so the LB entity management sites in LBaaS and the zone management would be in deisgnate.. we need to decide on the where the orchestration sits
16:21:48 <xgerman> yep
16:22:02 <KunalGandhi> ok. do we need a separate service for that ?
16:22:06 <xgerman> and GLSB needs to monitor health to adjust records
16:22:10 <mugsie> or, to ask another question: what is the MVP for this, and the timescale we want to commit to?
16:22:23 <ekarlso> q' would this be something we could present into the NFV working group as a potential usecase there to ?
16:22:30 <ekarlso> nfv / telco rather
16:22:31 <dougwig> the pools and monitoring end up looking a lot like lbaas, so i could see it separate or leveraged as part of that.
16:22:39 <xgerman> +1
16:22:45 <KunalGandhi> +1
16:22:56 <xgerman> Labs could be more generalized
16:23:00 <xgerman> LBaaS
16:23:26 <mugsie> ok, let me try and summerise then:
16:23:31 <Kiall> I suspect things look similar from a model point of view, but the current LBaaS implementations as far as I know rely on haproxy/netscalers/etc to actually implement the monitoring piece.
16:23:36 <dougwig> i think you end up with either 1) a third project, or 2) a way for designate to consume monitoring events, or 3) a way for lbaas to consume/modify dns events.
16:23:58 <KunalGandhi> So the MVP should at least have the LBaaS side to manage the regional VIP's in LBaaS and their zones in deisgnate
16:24:02 <mugsie> there will be a service (or a part of lbaas) that monitors regional LBs and chnages DNS records in designate according to the results?
16:24:35 <xgerman> I think we can leave monitoring out for the MVP
16:24:46 <mugsie> even better :P
16:25:08 <mugsie> but in general does ^ sound right?
16:25:11 <KunalGandhi> xgerman: ok so just regional VIP and linking them together in GLB
16:25:11 <samuelbercovici> hi everyone
16:25:16 <xgerman> hi Sam
16:25:23 <Kiall> xgerman: so, as one of the LBaaS guys in the room - what do you see as the MVP? Same question to KunalGandhi/dougwig, who kicked this off.
16:25:55 <xgerman> I think orchestrating the DNS entries, the LBs, etc. would be my MVP
16:26:02 <dougwig> xgerman: i'm not sure i'd leave out monitoring, otherwise you're just at round robin DNS.
16:26:15 <Kiall> dougwig: yea, that's my thought too, which is why I'm asking :)
16:26:36 <KunalGandhi> I think we at least need a service that can create GLB entities and have designate manage the zones for it..
16:26:47 <mugsie> xgerman: remember it could leverage the monitoring done in lbaas / octavia ...
16:26:54 <dougwig> Kiall: i'd see an api interface, a cli, a global vip with a pool, some crude form of monitoring that, and then modifying zones for creation and monitoring.
16:26:55 <KunalGandhi> @dougwig +1.. I think we might need monitoring of the VIP's at least
16:26:57 <xgerman> yeah, I really took Minimum to heart :-)
16:27:17 <Kiall> To me, the MVP is an API where you define GLBs, their DNS names, and their target backends/regional LB's. As these are created/updated/go up/go down, DNS is updated.
16:27:18 <samuelbercovici> can we start by working in a use case document? same as we did when starting LBaaS v2?
16:27:24 <KunalGandhi> @dougwig .. +1 on that.
16:27:52 <mugsie> samuelbercovici: that sounds like a good idea
16:27:57 <KunalGandhi> @samuelbercovici ... Yes..that would good..
16:28:00 <dougwig> samuelbercovici: we briefly covered that early, but not in depth, and that'd be a good idea.
16:28:06 <xgerman> +1
16:28:10 <mugsie> how was it done for v2 lbaas? Google Doc / etherpad?
16:28:20 <xgerman> Google Doc
16:28:25 <samuelbercovici> Google doc. but anything goes
16:28:27 <dougwig> perhaps if one person started a use case doc for folks to edit, and another took a stab at a "traditional" gslb type interface we might use, we could discuss those?
16:28:40 <KunalGandhi> dougwig: I can start that.
16:28:41 <mugsie> can we action someone to create one and share it with the group?
16:28:52 <dougwig> KunalGandhi: which one?
16:29:03 <KunalGandhi> # action Use Case..
16:29:15 <samuelbercovici> I think that a use cases document should be started first.
16:29:19 <mugsie> and when we get that in place, we can circle back? I think a few use cases would really help the discussion
16:29:28 <dougwig> ok, works for me.
16:29:46 <samuelbercovici> we can then prioritize and based in this design and api
16:29:49 <mugsie> ++
16:29:52 <Kiall> #action KunalGandhi produce initial draft UseCase google doc / etherpad.
16:29:57 <KunalGandhi> #action use case..
16:30:07 <Kiall> dooh, doubled up :)
16:30:23 <dougwig> let's put a timeline around that.  KunalGandhi, when do you think you can have that kicked off and ready for input?
16:31:06 <KunalGandhi> @dougwig .. Can we do this next week at the same time ? I will have something ready before that..
16:31:30 <dougwig> yes.  and then another week for input/feedback/discussion, at which point we dive into the technical?
16:31:40 <mugsie> sounds good
16:31:44 <xgerman> +1
16:31:59 <Kiall> Yea, sounds good.
16:32:18 <dougwig> great.  anything else we want to discuss in the meantime today?
16:32:29 <KunalGandhi> @dougwig .. I think once agree upon the use cases and MVP then we can dig into the technical aspect of it.. maybe the following week ?
16:32:57 <KunalGandhi> No.. I think that is it..
16:32:58 <Kiall> dougwig: I'd be interested to hear barclaac explaire more about his BGP use case ;)
16:33:10 <samuelbercovici> this is how we did the use cases - https://docs.google.com/document/d/1Ewl95yxAMq2fO0Z6Dz6fL-w2FScERQXQR1-mXuSINis/mobilebasic?pli=1
16:33:12 <KunalGandhi> I will send out the link to the Google doc sometime next week
16:33:21 <xgerman> awesome
16:33:27 <dougwig> barclaac and angus should get in a room.  we'd have a self-aware skynet just via bgp.
16:33:29 <KunalGandhi> @samuelbercovici .. Thank you for the link
16:33:34 <barclaac> Sure. You don't want to use BGP to get to the LB because if the weights change you'll have missing connection state.
16:33:36 <Kiall> dougwig: lol..
16:33:52 <barclaac> If you use BGP at the DNS level then you made your choice and the connection will be consistent for a single LB.
16:34:21 <dougwig> lbaas is having a mid-cycle july 15-17 at hp's seattle office. by any chance can any of the designate folks attend?
16:34:25 <KunalGandhi> Thanks guys for joining the meeting..
16:34:53 <mugsie> i will see dougwig
16:34:54 <Kiall> barclaac: Okay, so it's entirely on the DNS side, rather than doing BGP/ECMP etc for the GLB -> Regional LB?
16:35:53 <dougwig> #topic Open discussion, BGP, and final thoughts...
16:35:58 <barclaac> Exactly. Each LB will only have the state for the connections that it's handling. If we send those packets to a different data center the LB (hopefully) will reset the connection because it won't have any state for the packets.
16:36:33 <xgerman> yeah, that’s my understanding as well
16:36:44 <xgerman> lbs between datacenter don’t share state
16:37:00 <barclaac> Well we could ;-) but it would be really expensive.
16:37:04 <Kiall> right.. Yea. State replication cross region isn't something we should aspire to ;) Was just curious if your thoughts were around BPG usage outside of the DNS piece. It sounded like that was what you were suggesting.
16:38:09 <Kiall> Okay, I'm out of Q's then, KunalGandhi thanks for offering to write up the first pass @ use cases, can you email a link to the list once done? (tagged [Designate][LBaaS] so the Designate folks see it)
16:38:27 <KunalGandhi> @Kiall .. yes
16:38:34 <dougwig> anything else from anyone?
16:38:49 <Kiall> Nope, Not from me.
16:39:03 <dougwig> ok, let's all get back to our mornings.  thank you, all.
16:39:08 <KunalGandhi> Nothing from my side
16:39:16 <samuelbercovici> bye all.
16:39:20 <mugsie> o/
16:39:23 <KunalGandhi> Thank you everyone
16:39:26 <dougwig> #endmeeting