16:59:34 <kiall> #startmeeting Designate
16:59:35 <openstack> Meeting started Wed Mar  5 16:59:34 2014 UTC and is due to finish in 60 minutes.  The chair is kiall. Information about MeetBot at http://wiki.debian.org/MeetBot.
16:59:37 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
16:59:40 <openstack> The meeting name has been set to 'designate'
16:59:44 <kiall> Hey all - Who's about?
16:59:48 <msisk> Here.
17:00:09 <mugsie> here
17:00:19 <kiall> mugsie / eankutse / betsy etc? about
17:00:28 <vinod> ?/yes/yes
17:00:31 <betsy> here
17:00:33 <kiall> Cool :)
17:00:34 <rjrjr__> here
17:00:38 <kiall> Okay .. Lets go..
17:00:40 <kiall> #topic Review action items from last week
17:00:51 <kiall> So first up.. Apologies for the double booking last week
17:01:03 <richm> here
17:01:06 <eankutse> here
17:01:10 <kiall> neither myself or mugsie could attend.. I see eankutse kept it going though :)
17:01:22 <eankutse> sort of :-)
17:01:25 <kiall> So - There was no actions last week, lots from the week before
17:01:30 <betsy> several of us from Rackspace couldn't attend either
17:01:55 <kiall> I can say the actions for me are not done :( We've been manic over the last 2 weeks with some HP internal stuff
17:02:14 <mugsie> i am ghe same as kiall unfortunatly
17:02:19 <mugsie> the*
17:02:34 <kiall> So, I'd like to push them off again until next week, with the exception of the V2 gaps
17:02:38 <kiall> https://etherpad.openstack.org/p/designate-v2-gaps
17:03:31 <kiall> There are 2 public facing gaps still listed, both of which I think we're going to have to drop from icehousr unless we can find someone with the bandwidth to do them :(
17:03:46 <kiall> Both would be API additions, so wouldn't cause a break in the v2 API
17:04:01 <kiall> (Filtering, and Structured data format)
17:04:03 <kiall> Thoughts?
17:04:10 <betsy> At this late date, I recommend we drop them from icehouse
17:04:14 <mugsie> +1
17:04:27 <eankutse> makes sense
17:04:36 <rjrjr__> i'm okay with that.
17:04:50 <kiall> betsy: agreed, we can add them right after icehouse final when people get the time!
17:05:28 <kiall> Any opposing opinions?
17:05:57 <kiall> Okay - I'm taking silence as a no then :)
17:06:37 <kiall> Okay ..
17:06:39 <kiall> #topic Icehouse 3 Release
17:06:55 <kiall> i3 is due for the core projects tomorrow
17:07:15 <kiall> I suggest we go ahead and cut an i3 over the weekend, or Monday
17:07:30 <kiall> From that point - It's bugs bugs bugs, thoughts?
17:07:38 <betsy> kiall: sounds good
17:07:39 <rjrjr__> +1
17:07:43 <eankutse> +1
17:07:48 <mugsie> I would say Monday morning
17:07:49 <vinod> So for i3 is v2 being enabled or disabled by default?
17:07:59 <mugsie> enabled I would say
17:08:06 <kiall> vinod: we discussed enabling by default for i3
17:08:25 <vinod> ok
17:08:29 <betsy> +1
17:08:31 <kiall> I think we should make that call right before we cut the release, depending on if anything is found
17:08:39 <kiall> But - I'd like to assume we're turning it on
17:08:46 <betsy> kiall:okay
17:09:03 <kiall> And only if there's a showstopper, would we decide otherwise
17:09:48 <kiall> (Also - I should point out, myself / ekarlso / mugsie are currently doing double duty on meetings. apologies for being a bit slow to type today!)
17:10:34 <richm> understood
17:10:48 <kiall> So - If anyone has knows of any bugs that either aren't targetted to i3, or aren't filed. Can we spend some time doing that today?
17:11:03 <kiall> Even if it's just a 1 line description, it will help :)
17:11:17 <mugsie> +1
17:11:20 <eankutse> Yep.
17:11:42 <kiall> #action all to file any remaining known bugs and target anything important to i3
17:11:43 <betsy> ok
17:11:53 <kiall> #topic mini-dns, what next?
17:12:24 <eankutse> I have looked at the dnspython library
17:12:35 <eankutse> I think it has great capablity
17:12:39 <eankutse> we can leverage
17:12:43 <eankutse> for miniDNS POC
17:12:43 <kiall> So - This item's been leftover from last week, and really needs some attention from myself to coordinate with eankutse. Apolgies - Up to 90 is an understatement!
17:13:03 <kiall> eankutse: cool, any info for us on what's good/bad re it?
17:13:15 <eankutse> I have not done any coding yet
17:13:19 <eankutse> that would be next step
17:13:29 <eankutse> but I think it is really capable library
17:13:36 <eankutse> for server-side AXFR
17:13:52 <eankutse> no documentation but looked at the code
17:14:03 <eankutse> and I think we can use it for POC
17:14:10 <kiall> eankutse: Cool, let's organize a 1:1 call next week sometime to see if I can unblock you at all?
17:14:30 <eankutse> k. I am not that blocked by you at this point
17:14:44 <eankutse> but let's still do 1:1
17:14:53 <kiall> Oh - cool, I thought you were waiting on the storage stuff I had talked about before starting to code :)
17:15:07 <eankutse> not yet
17:15:09 <eankutse> :-)
17:15:10 <kiall> We'll sync up after this to find a time :)
17:15:20 <eankutse> k
17:15:30 <kiall> #topic What should we call "miniDNS" - The BikeShed
17:15:39 <ekarlso> oh, there's a meeting also
17:15:47 <kiall> Lots of options in the agenda if people have looked!
17:15:48 <betsy> :D
17:15:51 <kiall> #link https://wiki.openstack.org/wiki/Meetings/Designate
17:16:47 <rjrjr__> i like betsy's names, but am wondering if sync / sink will be confusing.
17:16:52 <kiall> Any strong opinions yet? :)
17:17:08 <rjrjr__> i like how short and simple they are.
17:17:13 <betsy> rjrjr: I know. I thought about calling it the kitchensync
17:17:16 <vinod> Demon - Designate Master Name Server
17:17:20 <rjrjr__> LOL
17:17:24 <kiall> vinod: nice :)
17:17:39 <kiall> "madness" is one I'd argue against ;) (sorry rich)
17:18:06 <mugsie> I like designate-mns
17:18:34 <vinod> I like it too - except it is a mouthful
17:18:43 <eankutse> Kiall "mdns" is not that different from "madness" tho :-)
17:18:43 <betsy> and hyphenated
17:18:55 <ekarlso> designate-mdns ?
17:18:58 <ekarlso> : p
17:19:00 <betsy> maybe we should just call it mdns
17:19:10 <eankutse> which is like "madness"
17:19:13 <eankutse> :-)
17:19:14 <rjrjr__> and pronounce it madness.
17:19:38 <kiall> mdns + madness -> madness m(a)dn(e)s(s)  ;)
17:19:48 <eankutse> :-)
17:19:49 <jesusaurus> +1
17:19:52 <kiall> lol
17:19:56 <betsy> +1
17:19:57 <eankutse> BackendSync?
17:20:08 <rjrjr__> +1 on designate-mdns
17:20:27 <richm> I meant no disrespect with madness, just wanted to get a discussion going, which it seems to have . . .
17:20:29 <kiall> eankutse: the "sync" part is probably going to lead to some confusion
17:20:42 <kiall> richm: lol .. I like it, just not the image to project ;)
17:20:43 <eankutse> ok
17:21:28 <eankutse> ;-0
17:21:40 <kiall> So - Any arguments for the "*sync" names etc? I personally think the confusion with sink will cause issues
17:22:00 <richm> yeah, would rather find something else
17:22:05 <eankutse> Kiall: I see what you mean
17:22:07 <betsy> kiall: agreed
17:22:46 <kiall> Okay .. So we're left with "transfer-agent" (designate-agent will die, so confusion is not an issue)
17:23:07 <richm> xfer-agent?
17:23:13 <kiall> master, mdns, mns and demon :)
17:23:44 <eankutse> would that work for the future functionality of the component as well?
17:23:52 <kiall> Anyone have any reasons to rule any of the above out?
17:24:08 <betsy> demon might be confused with daemon
17:24:09 <richm> it probably won't be just a transfer agent
17:24:14 <kiall> eankutse: agent? I think it kinda replaces the current agent in terms of functionality
17:24:16 <rjrjr__> if mini-dns does more than xfers in the future ...
17:24:32 <eankutse> kiall: no; "transfer"
17:24:39 <kiall> ah
17:24:56 <rjrjr__> so, toss xfer-agent and transfer-agent.
17:25:22 <mugsie> yup
17:25:33 <kiall> true. Also, "agent" works for the initial functionality but not eventual/future functionality
17:25:50 <mugsie> I would say designate-mdns - it shows its the dns section, and isthe 'master'
17:25:56 <kiall> So do we think we have a winner in the remaining choices?
17:26:07 <kiall> humm
17:26:10 <rjrjr__> +1 on mdns
17:26:17 <richm> #agreed
17:26:17 <kiall> mdns - short for either master or mini
17:26:22 <betsy> mugsie: agreed, but do we need the full name? Is mans ok?
17:26:31 <kiall> master is again initial and not eventual stuff
17:26:33 <betsy> mdns
17:26:38 <betsy> I mean
17:26:43 <mugsie> i would say keep the prefix - everything else we have is prefixed
17:26:50 <rjrjr__> aren't the other processes called designate-<something>
17:26:57 <mugsie> (designate-central, desingate-api etc)
17:26:59 <betsy> mugsie: ah
17:26:59 <kiall> betsy: well, all the services are designate-*
17:27:01 <kiall> and code is designate/*
17:27:26 <betsy> Then I'm fine with designate-mdns
17:27:35 <mugsie> any objections?
17:27:37 <rjrjr__> if we use mdns, i'll be pronouncing it "madness" at work. :)
17:27:44 <betsy> :)
17:27:45 <kiall> rjrjr__: as will I :)
17:27:52 <vinod> +1 on designate-mdns
17:27:59 <kiall> Okay - any -'s on it?
17:28:07 <eankutse> +1
17:28:23 <mugsie> +1
17:28:41 <kiall> Okay - Settled then if there are no opposing opinions
17:28:55 <kiall> That was the easiest bikeshed ever ;)
17:28:58 <kiall> #topic Records table -- having a table for each type vs. one record table
17:29:07 <kiall> betsy: you added this one?
17:29:19 <betsy> So, right now in our production dns, we have separate tables for each record type
17:29:29 <betsy> I was looking in to how many rows each contains
17:29:43 <betsy> The 'a' record table has almost 4 million rows
17:29:52 <betsy> Same for came and mx and some others
17:30:19 <betsy> That would leave us with a single table of almost 15 million rows and growing
17:30:27 <kiall> Okay, so your angle is around DB scalability?
17:30:35 <betsy> Yep
17:30:38 <kiall> I see a few other good reasons for a split
17:30:43 <betsy> I'm not a dab, but i'm worried about adding a row, etc.
17:30:54 <betsy> Lots of traffic on them, too
17:31:07 <kiall> e.g. allowing DB constraints and schema to be tightended for the specific record types
17:31:07 <betsy> dba
17:31:15 <betsy> yes
17:31:27 <betsy> scalability is just one issue
17:31:41 <kiall> and giving us a way to store the structured representation of the RData without converting back and forth from string format
17:31:50 <betsy> Yes
17:32:04 <kiall> So - I personally think it's the right way to go ..
17:32:16 <mugsie> i think it is a good idea. We just need to figure how it would work with plugable record types
17:32:32 <betsy> mugsie: in what way?
17:32:37 <mugsie> (aka creating new tables on the fly)
17:32:44 <betsy> oh, right
17:32:46 <kiall> mugsie: plugins can have there own migrations
17:32:59 <kiall> we actually do that already for our Akamai plugin
17:33:04 <betsy> Or there could even be one table for generic types
17:33:31 <kiall> betsy: right, so most rtpes can be reduced to a few common bases ..
17:33:45 <kiall> TXT / SPF == Text, A / AAAA = IP Address
17:33:52 <kiall> etc
17:34:19 <kiall> Maybe we should see if we can get generic tables rather than 1 per record type?
17:34:36 <kiall> also NS / CNAME / PTR / DNAME / etc are all identical again
17:34:40 <betsy> kiall: You still might run into super large tables
17:34:41 <mugsie> I think that 1 per type is ok
17:34:54 <kiall> betsy: true
17:35:04 <kiall> So - What's the harm in 1 per type?
17:35:15 <mugsie> none, that I can see
17:35:18 <betsy> Yeah. I like one per type
17:35:26 <mugsie> but, I am not a (good) dba
17:35:36 <kiall> I'm no DBA, so how does MySQL/Postgres/etc handle 1 large table vs N small (but still large) tables
17:35:36 <mugsie> so I am open to correction
17:35:51 <rjrjr__> joins can slow down queries...
17:35:55 <kiall> Lol - It's like "I'm no lawyer .. But.."
17:36:16 <mugsie> rjrjr__: we shouldn't be joining (afik)
17:36:26 <mugsie> actually
17:36:28 <mugsie> we would
17:36:31 <kiall> rjrjr__: so, AXFR's would end up doing JOINs cross the tables
17:36:34 <kiall> I think
17:36:38 <betsy> Seems like separate tables would make it easier for recordsets
17:36:38 <mugsie> even api requests
17:36:48 <mugsie> (get all records in zone x)
17:37:11 <mugsie> humm.
17:37:32 <rjrjr__> we'd have to understand the performance implications of separating things out.
17:37:37 <kiall> Okay - So, I think we should write up a blueprint for this - with some of the use cases were we'll need cross-type data returned
17:37:38 <mugsie> That would be slower... but I think DB views *might* help?
17:37:54 <kiall> Then - Point a DBA at that to give us their opinion?
17:37:59 <mugsie> yup
17:38:03 <betsy> we've got some dba's in-house I think
17:38:11 <betsy> I can ask them what they think
17:38:17 <kiall> mugsie: DB views aren't standard - So.. can't really do that
17:38:59 <betsy> Would you like me to write up a BP on it and then we can discuss more?
17:39:04 <kiall> Okay - betsy, are you OK to write out a small BP on this?
17:39:07 <kiall> snap :)
17:39:10 <mugsie> +1
17:39:13 <betsy> lol
17:39:33 <betsy> add that as an action item
17:40:12 <kiall> #action betsy to write up BP for table per record-type change
17:40:45 <kiall> Okay - Shall we move on and come back to ^ in a week or two when the BP is up?
17:41:07 <betsy> sounds good
17:41:47 <kiall> #topic Review fixed IP PTR records BP
17:41:52 <kiall> Okay - Moving on :)
17:42:00 <kiall> rjrjr__: this was added by you, want to intro it?
17:42:32 <rjrjr__> sure, in a nutshell, this BP is to finish the API started for floating IPs but for fixed IPs.
17:43:06 <rjrjr__> fixed IPs have the same issue, tenant owns reverse domain, but networks can be shared by tenants.
17:43:49 <rjrjr__> kiall mentioned extending the floating IP API for fixed IPs.
17:44:06 <kiall> rjrjr__: so I like the idea, but have a few notes on the BP
17:44:13 <rjrjr__> sure.
17:44:21 <kiall> Currently, your using just the IP in the URL
17:44:47 <kiall> for cases where overlapping networks are disabled, but tenants are still picking and choosing there own networks.. We should to and ensure we support that
17:44:47 <rjrjr__> i'm using the IP as the resource ID, correct.
17:45:20 <kiall> Also, with Designate being "global" and Neutron being per-region, we may need to include the region in the URL, similar to the /reverse/floatingip APUI
17:45:21 <kiall> API*
17:45:33 <rjrjr__> so, you mean if two tenants have the same network.
17:45:52 <rjrjr__> like say, 10.0.0.0/24?
17:46:04 <kiall> No, where tenant A has 10.0.0.0/24 and tenant B has 10.1.0.0/24
17:46:21 <kiall> if we do a GET /reverse/fixed/10.0.0.1 - we have to "figure out" what network it belongs to
17:46:28 <kiall> potentially with 1000's of networks
17:46:51 <kiall> I think the network_id (or subnet_id?) along with region need to be included somehow
17:47:04 <kiall> Yea - subnet_id rather than network_id
17:47:15 <kiall> networks can have N subnets with different CIDRs
17:47:43 <betsy> kiall: don't floating IPs have this same issue?
17:48:09 <kiall> FloatingIPs are, AFAIK, always unique within a region
17:48:12 <rjrjr__> i looked at the floating IP code and it looked like we assumed everything is a /24 or class C.
17:48:26 <kiall> so we use /reverse/floating/<region name>:<floating ip id>
17:48:34 <betsy> Ah
17:48:44 <kiall> rjrjr__: we auto generate /24 in-addr.arpa. zones
17:48:56 <kiall> (which is the smallest we can)
17:49:20 <kiall> Sadly PTR records are stuck in the pre-classless era
17:49:35 <kiall> so they inherently assume /8 /16 or /24
17:49:50 <kiall> 10 mins left BTW
17:50:00 <rjrjr__> so, the resource ID in the API should be qualified with the subnet_Id?  so subnet_id:ip address?
17:50:27 <kiall> rjrjr__: maybe, we use this for floating IPS:
17:50:30 <kiall> /reverse/floating/<region name>:<floating ip id>
17:50:41 <kiall> but.. the equilivant for fixed would be even more ugly
17:50:51 <kiall> /reverse/fixed/<region name>:<subnet_id>:<floating ip id>
17:50:53 <kiall> ehh
17:51:07 <kiall> /reverse/fixed/<region name>:<subnet_id>:<fixed ip (or FixedIP ID)>
17:51:40 <rjrjr__> i have notes in the BP. i was thinking about determining the correct domain using the Designate domains table.
17:51:51 <mugsie> so, kiall's pc just turned itself off :/
17:52:05 <mugsie> he should be bakc in a sec
17:52:08 <rjrjr__> putting all this in the API makes the API very hard to use.
17:52:08 <mugsie> back*
17:52:42 <betsy> rjrjr_:agreed
17:52:48 <betsy> Can some of that go in the body>
17:52:51 <betsy> ?*
17:53:01 <mugsie> I would say that it couldn't
17:53:13 <mugsie> (it should represent a single resorouce)
17:53:36 <mugsie> so, the url could represnt multiple items, if we put some of that in the body
17:53:43 <rjrjr__> i still don't understand why we need it all.  i have an IP address.  should be able to figure out the domain for it without the user prompting me in the API.
17:53:49 <kiall> Okay - Back.
17:54:01 <kiall> rjrjr__: re making the API hard, agreed
17:54:11 <kiall> We need to figure out what the best approach is
17:54:14 <rjrjr__> wether that is looking things up in Nova/Neutron or Designate.
17:54:23 <kiall> betsy: the body can't be used for GET queries
17:54:25 <rjrjr__> whether.
17:55:18 <kiall> rjrjr__: anyway, we have like 5 mins left.. SO! Other than needing to figure that out, which is a more general problem for us, I'd love to see that implemented :)
17:55:27 <rjrjr__> i'd argue an IP address should have been sufficient for floating IPs too.
17:55:27 <kiall> Can't speak for anyone else though!
17:56:01 <kiall> rjrjr__: yea, we may be able to reconsider that (while continuing to support the region hint if necessary)
17:56:08 <rjrjr__> i have the next 2 weeks scheduled (via a Sprint) to work on the implementation.
17:56:16 <kiall> rjrjr__: cool :)
17:56:53 <kiall> rjrjr__: why don't we try come up with the API that works and go from there?
17:57:02 <rjrjr__> i want to eventually align my companies needs with the communities needs (i.e. Icehouse 3 release) but right now, i just need to get designate ready for us to use it.
17:57:15 <rjrjr__> kiall.  sure.  when can we discuss this more?
17:57:18 <kiall> rjrjr__: We all know that feeling :)
17:57:36 <kiall> rjrjr__: friday is probably the next time I'll not be either asleep or on a call!
17:57:55 <kiall> But - others might have an option - bring it up in #openstack-dns :)
17:58:30 <rjrjr__> okay.  i'm going to start implementation on this.  maybe things will become clearer as i start working on it.  i'll be agile for what the community (we) decide as a correct API.
17:58:47 <kiall> Cool :)
17:58:57 <kiall> #topic Open Discussion
17:59:11 <kiall> And - Last but not least - Anyone else have anything else? :)
17:59:16 <richm> nada
17:59:20 <mugsie> nope
17:59:24 <eankutse> none
17:59:37 <betsy> none from me
17:59:41 <kiall> Okay .. with about 30 seconds to spare...
17:59:44 <rjrjr__> what time friday works for you kiall?
17:59:44 <kiall> #endmeeting