17:04:30 #startmeeting Designate 17:04:31 Meeting started Wed Mar 19 17:04:30 2014 UTC and is due to finish in 60 minutes. The chair is vinod1. Information about MeetBot at http://wiki.debian.org/MeetBot. 17:04:32 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 17:04:34 The meeting name has been set to 'designate' 17:04:56 who's around? 17:05:08 here 17:05:16 Here-ish 17:05:29 here 17:05:34 #topic Review action items from last week 17:05:44 mugsie to refresh Pools BP's before Monday 17:05:53 I guess mugsie is not around 17:06:01 kiall to refresh MiniDNS BP's/Specs before Monday 17:06:10 I see kiall updated the minidns specs 17:06:14 yep 17:06:34 questions/comments on those specs? 17:06:53 made first pass. no comemnts. Good docs 17:07:23 we actually have a separate agenda item for them 17:07:35 add agenda item for Pool/MDNS BP/spec discussions 17:07:36 Hiya 17:07:38 That is done 17:07:45 Sorry - was late in a meeting 17:07:51 :-) 17:07:53 kiall lead away 17:08:05 vinod1: too late, only you can now :) 17:08:11 Bot won't listen to me 17:08:20 Go ahead :) 17:08:20 we finished looking at the action items from last week 17:08:34 #topic MiniDNS Blueprints and Work Items 17:08:48 #link https://blueprints.launchpad.net/designate/+spec/mdns-master 17:09:03 #link https://wiki.openstack.org/wiki/Designate/Blueprints/MiniDNS 17:09:38 Okay - So, I split the MiniDNS blueprint into a series of smaller items that should be implementable on their own, without breaking master, and without too much code churn 17:09:58 Anyone had a chance to look at the steps I had laid out? 17:10:08 yes i did look at it 17:10:10 yes 17:10:15 me too 17:10:19 looks good! 17:10:26 Okay - Anything obvious wrong/missing/too big a BP etc> 17:10:27 thanks for splitting it - makes it easier to understand 17:10:41 Oh - Also worth mentioning, both the DIY and DNSPython route have BPs in there 17:10:48 one set of those will be deleted when a decision is made 17:10:53 kiall; maybe on second pass. I'll catch something or have questions 17:11:01 one thing i wanted a bit clarification on was the mdns-storage-objects blueprint 17:11:28 so what is the reasoning behind having storage returning objects? 17:11:45 vinod1: sure, so.. That actually it's technically mini-dns perse, but it's something that will make the remainder of MiniDNS easier. 17:12:15 does minidns need rdata? 17:12:24 The main reason, is to keep consistency when we turn the RData is structured data where the acceptable types are pluggable 17:12:46 It also gives a move for the encode/decode from DNSPython's equivalent objects 17:12:47 hello 17:13:09 And, gives a place for splitting validations out of the API and Central into a shared place that can be used by both 17:13:36 makes sense 17:13:53 makes sense to me, too. I like the idea 17:14:00 So - As I said, it's not 100% minidns related, but it's most likely the right think to do, and if we do it, we don't want to have to go back and update all the minidns code again 17:14:16 Another question that I had was about - mdns-designate-mdns-functional blueprint 17:14:31 you mention "This will be limited to standard, non AXFR/TSIG, queries for now." 17:14:40 what queries would these be? 17:14:54 Thats somewhat badly named ;) 17:15:06 #link https://blueprints.launchpad.net/designate/+spec/mdns-designate-mdns-functional 17:15:09 But it's where several other pieces would get tied together into something that actually responds to DNS queries 17:15:35 vinod1: DNS queries - Simple SOA lookups to start I would imagine 17:16:18 so would these be the building blocks for an AXFR response? 17:16:21 Once that BP is implemented - We should have a service is designate that's actually capable of receiving queries from `dig`, and responding.. Hence it "functional mdns" title :) 17:16:37 Yea - Once this is there, AXFR comes after 17:16:52 (for AXFR to work, the server needs to be able to answer a SOA query) 17:17:20 So - Getting the SOA (and probably other, since once you have one the rest are easy) working first, then building the AXFR pieces next makes sense to me 17:17:39 any more questions on this topic? 17:17:54 one 17:17:57 Kiall 17:18:06 The dependency graph at the bottom shows the progression from coed that does nothing functional, through to something functional, through to actually doing the core things we want. 17:18:12 code* 17:18:42 did you mean to provide a link to "Pre-Wiki translation of "Implementation Steps" that's much easier to read" on wiki here https://wiki.openstack.org/wiki/Designate/Blueprints/MiniDNS? 17:19:11 #link https://wiki.openstack.org/wiki/Designate/Blueprints/MiniDNS 17:19:14 I did - But, it seems I don't have the original markdown-ish version I wrote up 17:19:20 k 17:19:31 It was much easier to read than what the wiki did to it :( 17:19:53 the wiki's not too bad 17:20:03 I have a question, but I listed it as a separate agenda item 17:20:05 betsy: maybe it's just because I saw the original ;) 17:20:12 :) 17:20:35 I guess you could always send it out as an email 17:20:37 will the specs be made available to everyone? launchpad tells me "Not allowed here" 17:20:52 rjrjr_: really? it should be totally public 17:21:06 what URL in partocular? 17:21:11 strange. tells me it is private. 17:21:29 hmm. I can see it and I'm not currently logged into the wiki 17:21:44 never mind. 8^) 17:21:49 lol 17:21:58 no specs to see. 17:21:59 Okay - I think that's all the Q's vinod1, if to want to move on to betsy's item :) 17:22:09 Ok 17:22:12 #topic Records Table Redesign 17:22:23 #link https://blueprints.launchpad.net/designate/+spec/records-table-redesign 17:22:27 So, if we're going to split up the Records table into multiple tables per record type... 17:22:39 where does this fit into the priority? 17:22:49 Seems like it would be easier to do this first 17:23:03 Since we're changing the storage for minidns 17:23:25 Thoughts on priority for this? 17:23:37 betsy: I personally think it can go before or after the mdns storage changes - just not at the same time :) 17:23:47 true 17:23:58 that's why I think we should decide on when 17:23:58 i would say before would be ideal 17:24:05 betsy, did you talk to a DBA about this? 17:24:10 Yes. 17:24:23 I wrote some of the justification he gave on the blueprint 17:24:48 Basically, he said we could probably make one huge table work, but it would be better to have it divided 17:24:54 In terms of priority, I think it can happen anytime really. It's not killing anyone today, but would be nice to do sooner so the migration is easier+quicker :) 17:25:06 ikr? 17:25:19 But we can't do it at the same time as the mini-dns changes 17:25:58 Well - It should avoid happening at the same time as mdns-storage-objects and mdns-structured-rdata 17:26:15 But, that's only because it will be 2 major changes to the same piece of code at the same time 17:26:23 kiall: Right. 17:26:49 So, is it easier to do it first or does it really matter and we can put it off until after? 17:27:38 I think it's probably slightly easier after, because we'll have the objects in place to hold all structured -> text conversion methods etc 17:28:12 how about migration considerations at that time? 17:28:29 If we do it first, and if the tables are catered to the specific rdata (e.g. SRV has priority, weight, port, and target columns) then something has to convert that back to the merged text format we use today 17:28:39 After those 2 blueprints, that convert is unnecessary 17:29:00 kiall; hmm. Hadn't thought of that 17:29:39 Okay. So, are we all agreed that we're going to do that after mini-dns and possibly pools? 17:29:41 vinod1: not sure what you mean? 17:30:10 betsy: well, I think it can easily happen right after the mdns-structured-rdata BP.. Which is well before mini-dns would be complete 17:30:12 would it be harder to get the migration done at that time than now? 17:30:52 but i think your point about conversion implies that it is definitely easier to do after 17:31:04 vinod1: Oh, not that I can think of, other than HP's growing dataset that needs conversion ;) 17:31:21 kiall: I had initially thought the table changes would be easier to do before that, but I see your point and agree with you 17:31:30 That was all i meant by the would like it sooner comment earlier ;) 17:32:17 so adding this blueprint to the mdns dependency tree would be helpful - even though it is not related to mdns 17:32:35 Then I'll add a dependency to the blueprint I did 17:32:50 Got to vacate this conference room, stayed here to save time after the last meet ran over.. Now someone else has it booked. Be back in 5 mins. 17:33:16 #action betsy to add dependency to records-table-redesign blueprint 17:33:21 vinod1: Or at least at the dependency to the blueprint on splitting up the Records table 17:33:52 ok 17:33:53 so, Kiall is advocating waiting for the record table work? 17:34:19 rjrjr_: Yes. Until after the mdns-structured-rdata BP 17:34:30 It will eliminate some re-work 17:35:18 Moving on 17:35:35 #topic RecordSets revisited 17:35:56 I wanted kiall's input on this one 17:36:55 back 17:37:12 As our QA team is testing creating Records and RecordSets, they are finding the url quite long and cumbsersome 17:37:15 the concern here seems to be the advantages of having the recordsets outweigh having the long URLS for accessing a record 17:37:19 rjrjr_: yes, I think it makes sense - and ties in with some of the min-dns needs 17:38:21 So - Yea, the URLs can get long all right. No doubt about that. I guess it boils down to, do we really expect people to be interacting with the APIs by hand? 17:38:21 not particularly familiar with the API, but shouldn't recordsets be obfuscated from API users? 17:38:41 this part of the API. 17:39:15 rjrjr_: That's my question to Kiall. 17:39:17 rjrjr_: No, the URL ends up /v2/zones//recordsets//records/ 17:39:19 so - Long 17:39:32 Yes. Very long with 3 recordids 17:39:39 so what is the intention of having recordsets? 17:39:58 is it to enforce the same ttl for records? 17:40:27 ^ or 3 different IDs rather 17:40:39 vinod1: it ensures we don't either A) allow people to create scenarios that do something surprising and unexpected OR B) magically change all records in an RRSet when a single record is updated 17:40:56 Yes, Mainly focuses on the TTL 17:41:24 Is there a way we can do this without exposing the RRS resource to the end user? 17:41:39 For example - a RRSet is defined as the set of records with the same name (example.com.), type (A) and class (IN). For each of these sets, there must not be differing TTLs amond the records. 17:41:52 among* 17:42:09 do all records use recordsets? 17:42:29 If you have 2 A records called example.com, the first being TTL=100 Address=1.1.1.1, the second being TTL=200 Address=2.2.2.2 17:42:48 When someone queries for IN A example.com against, say, google DNS 17:42:59 google DNS will cache the first record for 100 seconds, the second for 200 seconds. 17:43:14 For the first 100 seconds, people will get back 2 records - 1.1.1.1, and 2.2.2.2 17:43:23 for seconds 101 through 200, they will only get 2.2.2.2 back 17:43:31 Which is totally unexpected 17:43:40 wouldn't this be pilot error? 17:43:52 rjrjr_: yes, all records belong to recordsets 17:44:04 if that is the case, can't we hide this from the user? 17:44:07 vinod1: absolutely, but it's also a violation of the DNS specs 17:44:20 at create/update time, can we check that the other ttl is different and fail the create/update 17:44:36 rjrjr_: so - if we hide it from the user, and the update the first records TTL, what should happen to the second record? 17:44:54 "Automatic" update behind the scenes is unexpected, they didn't ask for the second record to be changed 17:45:24 we can't just change the first record's TTL? 17:45:31 how about the ability to update multiple records belonging to a single zone in the same request 17:45:43 Anyway - Here's my question, what percentage of API calls do we expect a human to be making by hand? 17:46:19 I expect the vast majority will be using Horizon (other consoles) and client libraries/language bindings 17:46:42 i think this is unknown. if you expose it, people will use it has been my experience. 17:47:01 While very few, outside of us dev's and the poor QA folks who look after us, will be hand crafting HTTP API calls... 17:47:29 what about the designate command line tool? 17:47:37 That's my stance on that, no one is going to be adding data to the API manually. 17:47:38 rjrjr_: people will use it no doubt, the question is will they be constructing the URLs by hand, or will 99% of API call URLs be generated by some form of tooling? 17:48:11 Still seems like a lot of overhead just to enforce the TTL's 17:48:22 in any case - users now have to understand the recordset concept 17:48:24 richm: the CLI has always been nasty with it's use of ID's everywhere, and I believe we should switch to the keystone model.. ask for the useful info (record name, type) and have the client handle figuring the rest out 17:48:35 keystoneclient model* 17:48:35 back to your question, if someone updates the TTL for a particular record in a record set, can't we just update the TTL for the record? 17:49:10 rjrjr_: well, if RRSets are hidden in the API, then they can't update it on the RRSet? 17:49:48 so TTL is part of a recordset and a record? why not just make it part of the record? 17:50:09 is the only reason we are exposing the recordset because of the TTL? 17:50:22 imho ttl should be part of a record _and_ a part of a recordset - if a record does not have a ttl it should use the one defined in the recordset 17:50:49 hence the recordset being exposed. 17:50:52 rjrjr_: it's "exposed in order to facilitate adherence to the DNS RFCs" would be my carefully worded answer :) 17:51:11 richm: that violates the spec :) 17:51:23 Kiall: you mean rfc 1034? 17:51:48 http://tools.ietf.org/html/rfc2181 Section 5 17:53:12 6 mins left 17:53:30 ok, I see 17:53:41 i would still like to enforce the spec without introducing a recordset concept 17:53:55 the zone file too has just records and not recordsets 17:54:07 vinod1: I'm not sure any alternatives exist that don't add other complications 17:54:08 why not give the user the option to work with recordsets or not? /zones//records/ or /zones//recordsets//records/ 17:54:40 if they choose not to work with them directly, the code handles them for the user on the backend. 17:54:52 rjrjr_: that adds the complication of surprise TTL changes to records your not intending to edit 17:55:14 how? 17:55:24 how about an action item for me to come up with some alternatives and we discuss this again next week? 17:55:30 How about if an attempt to set a TTL on a record returns an error, and some sort of redirect or pointer to the recordset endpoint? 17:55:43 Also relevant, here's a snippet from AWS Route53 API: http://paste.openstack.org/show/73840/ 17:55:45 vinod1: Good idea as we're running short on time 17:55:52 I have a quick question, I know we're on something else, but I have to head to class so whomever/whenever wants to answer that's cool. I wanted to ask Mugsie about the status of the server pools spec and the idea generally. I'd still like to help with that if it hasn't been consumed by mindns stuff. 17:55:52 #link http://paste.openstack.org/show/73840/ 17:56:16 #link http://tools.ietf.org/html/rfc2181 17:56:22 tsimmons: mugsie literally just ran out to another meeting, I haven't had a chance to discuss it with him today 17:56:27 i have a question, but i can move it to #openstack-dns. 17:56:28 s/today/this week/ 17:56:52 #action vinod to come up with alternatives to recordsets 17:56:55 Kiall: well, if that happens at any point, let me know in the regular room, even if i'm not there i'll see it :) no pressure. 17:57:03 #action Everyone to think about RRSets, reread the logs from the conversation, and come with alternatives and pro's con's 17:57:10 vinod1: snap ;) 17:57:14 4 more mins and 2 more items on the agents 17:57:31 we can move the 2 remaining items to next week 17:57:34 any other questions 17:57:36 Lets move real real quick onto .. TenantId in URL.. I think I can kill it it a few seconds ;) 17:57:49 #topic TenantId in URL 17:57:57 Some of the other openstack services have the TenantID in the URL. Should we too have it in the URL instead of in the context? 17:58:07 #link http://api.openstack.org/api-ref-blockstorage.html 17:58:21 #link http://api.openstack.org/api-ref-compute.htmlml 17:58:27 Okay - So, Yes - Lots of the other OpenStack services current APIs include the TenantID in the URL. These have been a source of many many frustrations for them, and most of the newer API versions are removing the TenantID 17:58:54 do they come in headers then? 17:58:55 There have been lots of conversations over the last year or so about there merits, I'll try dig them up 17:58:57 hmm - so what were the issues they had 17:59:07 #action kiall to dig up ML archive entries around tenant id's in URLs 17:59:19 ok 17:59:23 long URLs? LOL 17:59:24 time to wrap up 17:59:25 vinod1: two of the main ones are.. 17:59:37 1) viewing all tenants stuff ends up funky 17:59:50 2) Placing a versionless URL into the catalog becomes impossible 18:00:09 #endmeeting