16:00:51 <mugsie> #startmeeting GSLB
16:00:52 <openstack> Meeting started Tue Jul 14 16:00:51 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:53 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
16:00:55 <openstack> The meeting name has been set to 'gslb'
16:01:03 <mugsie> so - who is here?
16:01:27 <santosh> Hi
16:01:32 <mugsie> o/
16:01:56 <KunalGandhi> o/
16:02:39 <mugsie> I think we might need to wait a few more minutes for people to join
16:05:24 <mugsie> ok, I think we are good to go - if people join later we can loop back
16:05:53 <mugsie> #topic review API strawman doc
16:05:56 <mugsie> #link https://docs.google.com/document/d/1nw5jVn0hjmhlhkZJAohx-gqRkkbVhMMJ79Pogd0ysEk/edit?usp=sharing
16:06:14 <mugsie> I saw there was a few comments over the last few days
16:06:39 <mugsie> I suppose to start out - is there any objections to the whole doc?
16:06:54 <KunalGandhi> @mugsie .. yes.. i added a few more API drafts around monitors and regional LB's
16:07:15 <mugsie> (did I miss some fundimental requirement that makes this API inconpatable)
16:07:48 <mugsie> KunalGandhi: I saw -  thanks for taking the time :)
16:07:55 <mugsie> I had 2 questions ..
16:08:05 <mugsie> for the regional LBs - is that required for the MVP?
16:08:28 <mugsie> and health monitors - how would they differ to healthchecks?
16:09:17 <KunalGandhi> @mugsie ... the way some GSLB's are used is the local VIP's are actually added to the regional LB
16:10:08 <mugsie> yeah - but for the MVP, is that needed
16:10:23 <mugsie> (aka version 0.1)
16:10:27 <KunalGandhi> @mugsie .. it might not be..
16:10:36 <mugsie> I think we definitly need to do it
16:10:42 <mugsie> but I am not sure of when
16:10:48 <KunalGandhi> @mugsie .. ok agree..
16:11:36 <mugsie> I think we will probably end up finding issues as we implement this API anyway, and I dont think we should make any guarenteee about how stable it is until we are certain anyway :)
16:11:43 <KunalGandhi> to answer your second question, health checks seems to be the status of the pool member itsef (at least from the doc)
16:12:11 <KunalGandhi> health monitors are very similar to what we have with LbaaS.
16:12:23 <mugsie> /lbs/<uuid>/pool_members/<uuid>/status was what I saw as the status
16:12:42 <mugsie> and healthchecks are actions that populate /status
16:12:48 <dougwig> sorry i'm late!
16:12:50 <KunalGandhi> @mugsie .. that looks like the status of the pool_member..
16:13:27 <mugsie> dougwig: np :)
16:13:29 <KunalGandhi> health monitors are monitors that will be required to monitor the health of the local VIP's (pool members) themselves.
16:14:01 <mugsie> ok, I think we can re name healthchecks -> healthmonitors, and have it do the same thing
16:14:32 <mugsie> that is what I had aimed heathchecks to do, I just didnt explain it well
16:14:54 <KunalGandhi> @mugsie .. if we go with the convention we followed with LBaaS.. we will need API's manage healthmonitors and API to associate/dissociate from pool member
16:15:03 <KunalGandhi> @mugsie .. ok cool..
16:15:07 <mugsie> dougwig: did you get a chance to read the doc?
16:15:19 <mugsie> KunalGandhi: ah - ok, thats the disconnect I am having
16:15:41 <mugsie> so healthmonitors are separate objects that are attached to multiple pool memebers?
16:15:50 <KunalGandhi> @mugsie .. yes.
16:15:54 <dougwig> no, but i just skimmed. i think we need a pool object on top of members, both so we can hang health monitors off of it, and so we can do /pool/uuid/member/uuid nested?
16:16:21 <KunalGandhi> @dougwig .. i agree
16:16:39 <mugsie> dougwig: do we need multiple pools per gslb?
16:17:07 <dougwig> i think we can start with one.  if the foreign key is in the pool, we can always make a 1:N later, too.
16:17:19 <dougwig> unless we want different monitors in different regions, e.g.?
16:17:33 <KunalGandhi> we could have something like pools --> members.. were pools are group of members that need to Globally load balanced.. and each member is a local VIP
16:18:08 <mugsie> so, re name the lb to pool?
16:18:20 <mugsie> or another nest?
16:18:28 <KunalGandhi> @dougwig ... we will multiple pools per GSLB.
16:18:32 <dougwig> KunalGandhi: i'm not sure it has to be a VIP.  you can use gslb without local LB.  an IP should be sufficient, no?
16:18:45 <mugsie> it should be IMHO
16:18:55 <dougwig> i'd prefer to keep pool/lb separate.  the dns half and the ip/monitor half, so to speak.
16:19:05 <mugsie> I gave an example of a regional LB, an IP, and a neutron port
16:19:23 <dougwig> mugsie: i saw that, and agreed.
16:19:29 <KunalGandhi> @dougwig .. yes.. when i said VIP.. i actually meant just the IP address.. GSLB just needs to IP.. no other data
16:20:51 <KunalGandhi> so just to recap, for MVP, we need the following : 1) Pool API 2) Member API 3) Monitors 4) Association and Dissociation of monitors ?
16:21:02 <mugsie> so, we have load balencers, pools, health monitors as first level API objects
16:21:18 <mugsie> and then APIs to associate them to each other?
16:21:26 <mugsie> and disassociate
16:22:07 <dougwig> i'd be fine with that, though i'd also be fine with just passing a linking uuid for anything that we don't ever think will be many-to-many.
16:22:11 <mugsie> KunalGandhi: member API? that would be the current pool_member API moved to the Pools API right?
16:22:13 <dougwig> and then also members as children of pools?
16:22:26 <mugsie> dougwig: ++
16:22:30 <dougwig> (as an aside, i can also solicit feedback from the lbaas folks at tomorrow's midcycle.)
16:22:48 <mugsie> dougwig: ah, your in seattle?
16:22:50 <KunalGandhi> @mugsie .. yes..
16:22:56 <mugsie> cool.
16:23:11 <dougwig> mugsie: yes.  will you be there?
16:23:18 <mugsie> unfortunatly not
16:23:32 <dougwig> ok, then we can volunteer you for everything.
16:23:44 <mugsie> :)
16:24:05 <mugsie> so, then next steps:
16:24:07 <mugsie> Update the doc
16:24:15 <mugsie> get lbaas feedback
16:24:27 <mugsie> anything else?
16:25:03 <dougwig> no, i think that'll be good until next week.
16:25:10 <mugsie> cool.
16:25:14 <mugsie> #topic AOB
16:25:24 <dougwig> aob?
16:25:40 <mugsie> I was thinking of subbmitting a talk to Tokyo on this - would anyone be interested in co-presenting?>
16:25:47 <mugsie> dougwig: any other buisiness
16:25:54 <dougwig> aha.
16:25:57 <mugsie> i think it might be a european thing
16:26:20 <dougwig> i'd be willing, though i hate presenting, so i'd be just as happy to let someone else.  :)
16:26:26 <mugsie> I think a talk would be a good way to get knowledge out and get wider community feedback
16:26:53 <KunalGandhi> @mugsie .. agree..
16:26:54 <dougwig> agree
16:27:04 <dougwig> we better submit today or tomorrow.
16:27:07 <mugsie> yup
16:27:20 <mugsie> #link https://etherpad.openstack.org/p/gslb-tokyo-talks
16:27:21 <dougwig> you want to take point on that? you can always juggle the speaker list later as needed.
16:27:33 <mugsie> sounds good
16:27:46 <KunalGandhi> @mugsie .. i can provide some help on this front..
16:28:00 <mugsie> if anyone want anything to be added to the abstract dump it in that etherpad :)
16:28:07 <mugsie> KunalGandhi: great
16:28:07 <KunalGandhi> i had done a GSLB talk in the last summit.
16:28:16 <mugsie> even better :)
16:28:48 <dougwig> do folks want to start the infra/tc process to get a repo created? there's usually a few week lead time on that. i can get the ball rolling.
16:29:20 <mugsie> yeah - do we want to go stackforge first?
16:29:25 <KunalGandhi> ok. that sounds good..
16:29:46 <dougwig> mugsie: since stackforge is about to disappear, i was thinking we could try to go straight to openstack.
16:30:01 <mugsie> dougwig: oh I forgot about that
16:30:40 <mugsie> ok, I think we are done for today then :)
16:30:51 <mugsie> anyone have anything else?
16:30:58 <dougwig> cool. thanks for taking point on the API doc.
16:31:29 <mugsie> no problem - am on of those REST nerd
16:31:33 <mugsie> nerds*
16:31:41 <mugsie> #endmeeting