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