16:00:13 <dougwig> #startmeeting gslb
16:00:14 <openstack> Meeting started Tue Jun  9 16:00:13 2015 UTC and is due to finish in 60 minutes.  The chair is dougwig. Information about MeetBot at http://wiki.debian.org/MeetBot.
16:00:16 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
16:00:18 <dougwig> #chair Kiall
16:00:18 <openstack> The meeting name has been set to 'gslb'
16:00:19 <openstack> Current chairs: Kiall dougwig
16:00:26 <dougwig> Kiall: hiya
16:00:36 <mugsie> #link https://docs.google.com/document/d/1016shVnPaK8l8HxMpjADiYtY2O94p4g7JxjuIA-qv7w/edit?usp=sharing
16:00:39 <Kiall> mugsie and barclaac should be joining too.. Anyone else about?
16:00:43 <mugsie> use case doc ^
16:00:57 <dougwig> ty, was just digging for that.
16:01:02 <dougwig> #topic Use cases
16:01:22 <dougwig> i don't see kunal here this morning.
16:01:28 <johnsom> o/
16:01:34 <Kiall> FYI - I'm only just getting a link to that doc, so just reading now..
16:01:54 <dougwig> ditto
16:03:23 <Kiall> Looks like Kunal joined
16:03:47 <KunalGandhi> Hi All
16:03:59 <KunalGandhi> Hi Kiall
16:04:11 <dougwig> KunalGandhi: hiya.  we were just reading your doc quickly.
16:04:30 <KunalGandhi> dougwig: ok cool..
16:04:53 <KunalGandhi> For folks who dont have the link to the doc.. https://docs.google.com/document/d/1016shVnPaK8l8HxMpjADiYtY2O94p4g7JxjuIA-qv7w/edit
16:05:36 <dougwig> folks should jump in with comments or other use cases.  if we can agree on that doc today, we can move forward to a draft api.  if folks need more time, then we can probably end early and let folks digest.
16:05:45 <KunalGandhi> I have put together an initial draft of use cases based on my understanding of gslb
16:06:04 <Kiall> dougwig: Q - Can you expand on what you mean by the least connection strategy?
16:06:10 <Kiall> sorry - KunalGandhi*
16:06:39 <mugsie> dougwig: I think we need to agree on how we are going to orchestrate things before we move to an API ..
16:06:51 <mugsie> i.e. how thin a layer GSLB will be
16:06:54 <Santosh_> Hi All
16:08:14 <Maha_> Hi All
16:08:40 <KunalGandhi> @Kiall ... sure.. the GSLB will return the public VIP on the regional LB that has the fewest connections
16:08:54 <mugsie> KunalGandhi: that doc is set to view only
16:09:02 <mugsie> (we cannot comment / edit atm)
16:09:12 <dougwig> mugsie: that'd be fine.  speaking personally, a rough and quick api would let me see what we need to build, which would help me figure out orchestration, not the other way around. but whatever works.
16:09:34 <Kiall> KunalGandhi: So, I guess I'm considering the latency on making a change to the VIPs return (limited by DNS TTL, say 60 sec realisticially) vs the rate at which each regional LB's connection count might change
16:09:36 <KunalGandhi> mugsie: ok.. let me change the permission so that everyone can comment on it.
16:10:39 <mugsie> dougwig: true, that is a good way of finding missing bits alright
16:10:45 <Kiall> i.e. is least connections something feasible to do?
16:10:51 <dougwig> Kiall: i'd expect that to be more along the lines of 'least connection at lookup', i.e., some level of session persistence.  not constant zone tweaking.
16:11:47 <KunalGandhi> @mugsie .. I have changed the permission so that anyone with a link can comment
16:12:09 <mugsie> dougwig: I would be afraid of it being a constant swing back and forth if we did that way - or is that an issue?
16:12:12 <KunalGandhi> You might have to refresh the page to start commenting
16:12:35 <Kiall> dougwig: Okay, I get where your going with that. Actually implementing that would be a nightmare tho, and most "normal" DNS server has that easy hook point.. But, it makes more sense now :)
16:12:57 <blogan> hi, sorry im late
16:13:02 <Kiall> do not have that easy hook point*
16:13:23 <dougwig> Kiall, mugsie: i think it's safe to leave that off v1, personally.  :)
16:14:05 <mugsie> dougwig: ++
16:14:07 <KunalGandhi> @Kiall.. Ok.. Please put that as a comment on the doc..
16:14:09 <Kiall> Yea, lots will be off V1 .. But wanting to understand the thinking :)
16:15:55 <Kiall> Okay - I think it pretty much all makes sense
16:16:26 <Kiall> (Left 2 comments where I see some potential issues coming in, but those would "tomorrow problems"
16:16:51 <johnsom> We should probably clarify "Geo-based" as there are different approaches; BGP AS route based, IP-Geo map tables, etc.
16:18:18 <mugsie> johnsom: i think that should be an excersise for the DNS provider (designate)
16:18:39 <Kiall> Okay - Everyone done reading?
16:18:45 <mugsie> as they may provide layered EDNS / BGP etc
16:18:50 <sballe> yep
16:19:31 <Kiall> Cool, so.. Are are key use cases missing?
16:20:08 <blogan> does the GSLB need to be HA?
16:20:19 <mugsie> blogan: well, it really should be
16:20:34 <blogan> i agree but does that need to be documented
16:20:38 <mugsie> but that will be down the the architechtre we use for it / deployer choice
16:20:43 <KunalGandhi> @blogan ..Yes..there should at least be in pair
16:21:08 <mugsie> it should be in a simalar style to other OpenStack services
16:21:26 <blogan> so will there be an open source driver for this?
16:21:32 <mugsie> (horizontaly scalable active - active componants)
16:21:36 <Kiall> Yea, we should add to the doc that we expect the failure of a region to be acceptable - it should continue working etc
16:21:44 <dougwig> blogan: there has to be, from what i understand.
16:21:54 <mugsie> I would expect this to be fully open source
16:22:07 <blogan> mugsie: is there an open source GSLB appliance right now?
16:22:26 <mugsie> no, but we are looking at using designate as the dns provider to do the load balencing
16:22:29 <blogan> dougwig: i do belive there has to be but i dont know of an open source version right now
16:22:48 <mugsie> which is part of openstakc, and fully open source
16:22:55 <dougwig> mugsie: speaking as a vendor, i'd like to see a driver mechanism in place for some parts of this.
16:22:58 <blogan> mugsie: what about monitoring?
16:23:12 <mugsie> dougwig: definitly
16:23:17 <Kiall> Okay, So.. What's the next steps here? If the use cases are not missing any key things (bar a mention of HA), dougwig suggested talking API, but I wonder if we need to figure out where this lives before that? Is it in Designate, in Neuton, a new service? etc
16:23:24 <KunalGandhi> @mugsie .. we should still need a driver that would configure the GSLB for monitoring and other settings right ?
16:23:27 <blogan> mugsie: and i assume designate has the ability or the plans to have the ability to do geo-based (sorry for my ignorance)
16:23:29 <Santosh_> plugin --> vendor specific driver(NetScaler GSLB)
16:23:39 <dougwig> blogan: i'm not aware of an open-source gslb monitoring appliance. i think we'll be writing parts of the gslb stuff.
16:23:41 <Kiall> blogan: it's planned for Designate, but isn't there yet
16:23:42 <mugsie> blogan: we have in the plans
16:24:02 <blogan> okay that works for me, same teams involved to drive both
16:24:25 <mugsie> I think we should have a driver interface, but allow people to use designate and neutron lbaas v2 to do this without a vendor
16:24:39 <dougwig> Kiall: i could see it as a neutron extension that interfaces with designate, or... what would it look like plugged into designate directly?
16:24:55 <dougwig> mugsie: agree.
16:26:06 <mugsie> i dont think it should be in designate
16:26:11 <mugsie> or in neutron
16:26:17 <blogan> is it common for a GSLB appliance to set up the load balancers as well?
16:26:18 <mugsie> neutron is a regional service
16:26:20 <rrickard> i agree.
16:26:31 <KunalGandhi> @mugsie .. i agree
16:26:35 <Kiall> blogan: GSLB appliances typically have a DNS server, and Load Balancer "in the box"
16:26:39 <rrickard> with mugsie. :)
16:26:40 <dougwig> blogan: no.
16:27:12 <KunalGandhi> @blogan ... GSLB appliances typically act as an LB and a DNS server..
16:27:43 <mugsie> can we plan this out assuming designate / neutron with driver hook points then, as a separate service?
16:27:48 <dougwig> right now, neutron is a global service, not regional, and the extension mechanism would let it all land in a new stackforge repo and bypass the normal goo surrounding a new project (rest, auth, test infra, docs infra, ...). but i'd be fine either way.
16:27:57 <KunalGandhi> @blogan .. The LB part is for health monitoring and the DNS is for managing the global zone
16:27:59 <blogan> i know, im just wondering if this GSLB API will orchestrate setting them all up or do we just leave it o the user to create hte load balancers and point the GSLB API to those vips
16:28:13 <Kiall> dougwig: neutron is global?
16:28:20 <mugsie> dougwig: are you sure neutron is global? I have only ever seen it deployed as a regional one
16:28:27 <blogan> ah maybe im misunderstanding using the lbaas v2 api then sorry
16:29:18 <mugsie> blogan: I think for v1 / v.05 they would be pre set up
16:29:24 <mugsie> v0.5*
16:29:33 <dougwig> Kiall, mugsie: ok, that's fair.  i'm thinking in terms of cells, not regions.
16:29:39 <Kiall> dougwig: ah :)
16:29:50 <mugsie> dougwig: ah, yes, fogot about cells
16:30:08 <blogan> mugsie: ah okay makes sense
16:30:34 <rrickard> so, separate service?
16:30:36 <KunalGandhi> @blogan .. i would presume that the VIP's on the regional LB's are pre-configured.
16:30:38 <mugsie> OK, I can take this feedback and try and draft a rough API for next week, if people like?  - Or is there more discussion?
16:30:40 <blogan> so separate API entirely from any other service right?
16:30:50 <mugsie> blogan: I would say yes
16:31:27 <blogan> mugsie: will the API including monitoring?
16:31:34 <dougwig> sounds like we should draft it that way, and assume that's the plan of record, unless something else shakes out while we figure out the API.
16:31:36 <KunalGandhi> @blogan .. +1.. since GLB is more at the global level rather than regional..
16:31:38 <Kiall> I would agree, I don't think it quite belongs in Designate or Neutron .. It's a mashup of Designate, Neutron, Monasca, etc
16:31:43 <dougwig> KunalGandhi: sounds good, and i'd like to help with that part.
16:32:02 <rrickard> we should add that to the use cases - monitoring.
16:32:04 <KunalGandhi> @dougwig .. cool.. thanks
16:32:39 <dougwig> rrickard: can you edit the doc with what you're thinking?
16:33:34 <Kiall> So - Is anyone feeling strongly this belongs in Neutron or Designate?
16:33:36 <blogan> i gotta go guys, but thanks for answering my questions :) i'd like to stay involved in this project as well, at least a high level
16:33:41 <dougwig> #action KunalGandhi dougwig draft initial API by next meeting
16:33:45 <KunalGandhi> @rrickard .. are you talking about monitoring the GSLB's themselves or monitoring the VIP's on the regional LB ?
16:33:54 <barclaac> How about option #3 - it's own thing?
16:34:09 <blogan> KunalGandhi: i'm talking monitoring the vips to pull them out of rotation
16:34:17 <dougwig> barclaac: that's the current decision. i think Kiall is trying to suss out whether we have any strong feelings in the other direction.
16:34:45 <Kiall> dougwig: bang on ;) trying to see if anyone disagrees's before we say "yep, own service+API"
16:34:53 <barclaac> blogan: do you see glsb managing one vip per data center or balance the individual machines?
16:35:03 <KunalGandhi> @blogan ... ok.. i can clarify that further.. i briefly mentioned it in point #3
16:35:16 <barclaac> e.g. glsb -> servers or gslb -> data center lb (ahem: octavia :-) -> machines?
16:35:17 <blogan> i can see people outside of this group disagreeing with another service simply because there are many many different endpoints in openstack right now
16:35:39 <mugsie> blogan: with big tent it is not as big a deal anymore
16:35:48 <Kiall> blogan: yea, agreed.. But there's also pain involved in putting something that doesn't belong into a project
16:36:02 <barclaac> But API bloat has been a problem with openstack
16:36:09 <blogan> speaking to the choir, but just throwing it out there
16:36:15 <mugsie> blogan: :)
16:36:16 <barclaac> let's have a cohesive service defn.
16:36:34 <KunalGandhi> @blogan ... GSLB API's will mainly run as a global service in most of the deployment..
16:36:39 <barclaac> although we could always add glsb to the neutron api server ;-)
16:36:45 <blogan> barclaac: hmmm i would think multiple vips in one dc but haven't thought about it much
16:36:49 <dougwig> we're now arguing about what people *might* argue about. i think i need more caffeine.
16:36:52 <KunalGandhi> @blogan .. and services like neutron typically run at the region level..
16:37:03 <sballe> dougwig: +1
16:37:08 <blogan> lol
16:37:16 <Kiall> Okay - So, rrickard, as far as what an API might look like since you got #action'd on that.. Are you familar with for e.g. he Netscaler APIs look like?
16:37:17 <mugsie> dougwig: :D
16:37:19 <blogan> dougwig: its openstack what do you expect
16:37:29 <rrickard> let's move forward with GSLB as it's own service.
16:37:35 <blogan> +1
16:37:41 <sballe> +1
16:37:44 <johnsom> +1
16:37:46 <KunalGandhi> +!
16:37:46 <barclaac> rrickard +1
16:37:52 <KunalGandhi> +1
16:37:53 <mugsie> +1
16:37:55 <Kiall> +1
16:38:12 <rrickard> kiall: i am not.
16:38:14 <blogan> or we just do it all in heat
16:38:16 <Kiall> actually.. It was KunalGandhi / dougwig who go #action'd.. sorry! same question to them
16:38:18 <barclaac> I'd go with gslb -> data center -> server model. It makes the individual data center LB responsible for pool management
16:38:18 <blogan> kidding
16:38:27 <sballe> @blogan -1
16:38:28 <dougwig> violent agreement, it seems.
16:38:31 <barclaac> glsb managing the pools would be potentially slower
16:38:36 <mugsie> KunalGandhi: dougwig I would like to give a hand on that spec as well, if possible
16:38:52 <dougwig> mugsie: great
16:38:53 <Santosh_> Can we put point wrt  expectations from  vendor specific drivers ?
16:39:12 <rrickard> KunalGandhi: obviously i am available too if you need help with Designate questions.
16:39:34 <KunalGandhi> @rrickard .. thanks :)
16:39:45 <mugsie> Santosh_: yup, that should be added to the doc
16:39:49 <dougwig> Santosh_: just a guess, but i think we need to sort out an api before we can know what the driver interface will look like.
16:40:08 <Kiall> Santosh_: Q - With NetScaler, I'm guessing you would expect this to be a shim API towards the NetScaler, no involvment from Designate/Neutron LBaaS - Right?
16:40:41 <KunalGandhi> @dougwig +!
16:40:42 <rrickard> regardless of API, we should be able to say this will be designed in a modular/driver fashion.
16:40:45 <KunalGandhi> @dougwig +1
16:40:49 <barclaac> +1
16:40:57 <Santosh_> For monitor related configuration it is managed by vendor GSLB
16:41:16 <Santosh_> Yes
16:41:27 <KunalGandhi> @rrickard .. it will be designed in a driver fashion.. similar to what LBaaS is
16:41:34 <dougwig> Kiall: well, there's two halves at play.  the dns side and the monitor side.  and the glsb appliances can play on both sides.  do they do dns directly, or as a provider/driver/plugin to designate directly?  or does designate still do dns, but delegate for vips?  many questions.
16:41:57 <dougwig> i'm not suggesting we try to answer them this morning.
16:42:11 <dougwig> just that it's not necessarily an "either or" thing.
16:42:29 <Kiall> dougwig: yea, exactly.. I kinda see the likes of NetScaler as providing all the pieces already, if you own one. The exception being OpenStack "style " API/Auth/Multi-Tenancy etc
16:42:30 <KunalGandhi> @dougwig ... i think whether the dns part is done by the GSLB appliance or not competely depends on the vendor's impl right ?
16:42:56 <Santosh_> Kiall yes
16:43:08 <dougwig> KunalGandhi: assuming our driver interface is flexible enough, yes.
16:43:22 <KunalGandhi> @dougwig ..ok..
16:43:50 <Kiall> Santosh_: cool, thanks.. I think that makes the most sense, letting NS/F5 etc do their thing, while allowing Designate/Neutron LB/Monasca to be combined into an a driver
16:44:09 <KunalGandhi> so the next step is @dougwig and I work on an intial draft of the API right ?
16:44:14 <mugsie> yup
16:44:18 <Kiall> 15 min warning.
16:44:21 <dougwig> and mugsie
16:44:35 <dougwig> anything else to discuss this morning?
16:44:40 <dougwig> #topic Open discussion
16:44:46 <dougwig> not that we haven't been in open discussion the entire time anyway.
16:45:04 <Kiall> dougwig: lol, yea.. Let's get an agenda page up on the wiki for next time.. :)
16:45:14 <dougwig> Kiall: agreed.  :)
16:46:27 <dougwig> ok, unless there's more, let's get out of here.
16:46:44 <Kiall> Sounds good :) Till next week...
16:47:00 <dougwig> thank you, and bye folks
16:47:27 <dougwig> #endmeeting