17:04:30 <vinod1> #startmeeting Designate
17:04:31 <openstack> 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 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
17:04:34 <openstack> The meeting name has been set to 'designate'
17:04:56 <vinod1> who's around?
17:05:08 <eankutse> here
17:05:16 <tsimmons> Here-ish
17:05:29 <betsy> here
17:05:34 <vinod1> #topic Review action items from last week
17:05:44 <vinod1> mugsie to refresh Pools BP's before Monday
17:05:53 <vinod1> I guess mugsie is not around
17:06:01 <vinod1> kiall to refresh MiniDNS BP's/Specs before Monday
17:06:10 <vinod1> I see kiall updated the minidns specs
17:06:14 <eankutse> yep
17:06:34 <vinod1> questions/comments on those specs?
17:06:53 <eankutse> made first pass. no comemnts. Good docs
17:07:23 <vinod1> we actually have a separate agenda item for them
17:07:35 <vinod1> add agenda item for Pool/MDNS BP/spec discussions
17:07:36 <Kiall> Hiya
17:07:38 <vinod1> That is done
17:07:45 <Kiall> Sorry - was late in a meeting
17:07:51 <eankutse> :-)
17:07:53 <vinod1> kiall lead away
17:08:05 <Kiall> vinod1: too late, only you can now :)
17:08:11 <Kiall> Bot won't listen to me
17:08:20 <Kiall> Go ahead :)
17:08:20 <vinod1> we finished looking at the action items from last week
17:08:34 <vinod1> #topic MiniDNS Blueprints and Work Items
17:08:48 <vinod1> #link https://blueprints.launchpad.net/designate/+spec/mdns-master
17:09:03 <vinod1> #link https://wiki.openstack.org/wiki/Designate/Blueprints/MiniDNS
17:09:38 <Kiall> 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 <Kiall> Anyone had a chance to look at the steps I had laid out?
17:10:08 <vinod1> yes i did look at it
17:10:10 <eankutse> yes
17:10:15 <betsy> me too
17:10:19 <eankutse> looks good!
17:10:26 <Kiall> Okay - Anything obvious wrong/missing/too big a BP etc>
17:10:27 <vinod1> thanks for splitting it - makes it easier to understand
17:10:41 <Kiall> Oh - Also worth mentioning, both the DIY and DNSPython route have BPs in there
17:10:48 <Kiall> one set of those will be deleted when a decision is made
17:10:53 <eankutse> kiall; maybe on second pass. I'll catch something or have questions
17:11:01 <vinod1> one thing i wanted a bit clarification on was the mdns-storage-objects blueprint
17:11:28 <vinod1> so what is the reasoning behind having storage returning objects?
17:11:45 <Kiall> 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 <vinod1> does minidns need rdata?
17:12:24 <Kiall> The main reason, is to keep consistency when we turn the RData is structured data where the acceptable types are pluggable
17:12:46 <Kiall> It also gives a move for the encode/decode from DNSPython's equivalent objects
17:12:47 <richm> hello
17:13:09 <Kiall> 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 <vinod1> makes sense
17:13:53 <betsy> makes sense to me, too. I like the idea
17:14:00 <Kiall> 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 <vinod1> Another question that I had was about - mdns-designate-mdns-functional blueprint
17:14:31 <vinod1> you mention "This will be limited to standard, non AXFR/TSIG, queries for now."
17:14:40 <vinod1> what queries would these be?
17:14:54 <Kiall> Thats somewhat badly named ;)
17:15:06 <vinod1> #link https://blueprints.launchpad.net/designate/+spec/mdns-designate-mdns-functional
17:15:09 <Kiall> But it's where several other pieces would get tied together into something that actually responds to DNS queries
17:15:35 <Kiall> vinod1: DNS queries - Simple SOA lookups to start I would imagine
17:16:18 <vinod1> so would these be the building blocks for an AXFR response?
17:16:21 <Kiall> 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 <Kiall> Yea - Once this is there, AXFR comes after
17:16:52 <Kiall> (for AXFR to work, the server needs to be able to answer a SOA query)
17:17:20 <Kiall> 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 <vinod1> any more questions on this topic?
17:17:54 <eankutse> one
17:17:57 <eankutse> Kiall
17:18:06 <Kiall> 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 <Kiall> code*
17:18:42 <eankutse> 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 <vinod1> #link https://wiki.openstack.org/wiki/Designate/Blueprints/MiniDNS
17:19:14 <Kiall> I did - But, it seems I don't have the original markdown-ish version I wrote up
17:19:20 <eankutse> k
17:19:31 <Kiall> It was much easier to read than what the wiki did to it :(
17:19:53 <betsy> the wiki's not too bad
17:20:03 <betsy> I have a question, but I listed it as a separate agenda item
17:20:05 <Kiall> betsy: maybe it's just because I saw the original ;)
17:20:12 <betsy> :)
17:20:35 <betsy> I guess you could always send it out as an email
17:20:37 <rjrjr_> will the specs be made available to everyone?  launchpad tells me "Not allowed here"
17:20:52 <Kiall> rjrjr_: really? it should be totally public
17:21:06 <Kiall> what URL in partocular?
17:21:11 <rjrjr_> strange.  tells me it is private.
17:21:29 <betsy> hmm. I can see it and I'm not currently logged into the wiki
17:21:44 <rjrjr_> never mind. 8^)
17:21:49 <Kiall> lol
17:21:58 <rjrjr_> no specs to see.
17:21:59 <Kiall> Okay - I think that's all the Q's vinod1, if to want to move on to betsy's item :)
17:22:09 <betsy> Ok
17:22:12 <vinod1> #topic Records Table Redesign
17:22:23 <vinod1> #link https://blueprints.launchpad.net/designate/+spec/records-table-redesign
17:22:27 <betsy> So, if we're going to split up the Records table into multiple tables per record type...
17:22:39 <betsy> where does this fit into the priority?
17:22:49 <betsy> Seems like it would be easier to do this first
17:23:03 <betsy> Since we're changing the storage for minidns
17:23:25 <betsy> Thoughts on priority for this?
17:23:37 <Kiall> betsy: I personally think it can go before or after the mdns storage changes - just not at the same time :)
17:23:47 <betsy> true
17:23:58 <betsy> that's why I think we should decide on when
17:23:58 <vinod1> i would say before would be ideal
17:24:05 <rjrjr_> betsy, did you talk to a DBA about this?
17:24:10 <betsy> Yes.
17:24:23 <betsy> I wrote some of the justification he gave on the blueprint
17:24:48 <betsy> Basically, he said we could probably make one huge table work, but it would be better to have it divided
17:24:54 <Kiall> 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 <betsy> ikr?
17:25:19 <betsy> But we can't do it at the same time as the mini-dns changes
17:25:58 <Kiall> Well - It should avoid happening at the same time as mdns-storage-objects and mdns-structured-rdata
17:26:15 <Kiall> But, that's only because it will be 2 major changes to the same piece of code at the same time
17:26:23 <betsy> kiall: Right.
17:26:49 <betsy> So, is it easier to do it first or does it really matter and we can put it off until after?
17:27:38 <Kiall> 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 <vinod1> how about migration considerations at that time?
17:28:29 <Kiall> 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 <Kiall> After those 2 blueprints, that convert is unnecessary
17:29:00 <betsy> kiall; hmm. Hadn't thought of that
17:29:39 <betsy> Okay. So, are we all agreed that we're going to do that after mini-dns and possibly pools?
17:29:41 <Kiall> vinod1: not sure what you mean?
17:30:10 <Kiall> 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 <vinod1> would it be harder to get the migration done at that time than now?
17:30:52 <vinod1> but i think your point about conversion implies that it is definitely easier to do after
17:31:04 <Kiall> vinod1: Oh, not that I can think of, other than HP's growing dataset that needs conversion ;)
17:31:21 <betsy> 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 <Kiall> That was all i meant by the would like it sooner comment earlier ;)
17:32:17 <vinod1> so adding this blueprint to the mdns dependency tree would be helpful - even though it is not related to mdns
17:32:35 <betsy> Then I'll add a dependency to the blueprint I did
17:32:50 <Kiall> 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 <vinod1> #action betsy to add dependency to records-table-redesign blueprint
17:33:21 <betsy> vinod1: Or at least at the dependency to the blueprint on splitting up the Records table
17:33:52 <vinod1> ok
17:33:53 <rjrjr_> so, Kiall is advocating waiting for the record table work?
17:34:19 <betsy> rjrjr_: Yes. Until after the mdns-structured-rdata BP
17:34:30 <betsy> It will eliminate some re-work
17:35:18 <vinod1> Moving on
17:35:35 <vinod1> #topic RecordSets revisited
17:35:56 <betsy> I wanted kiall's input on this one
17:36:55 <Kiall> back
17:37:12 <betsy> As our QA team is testing creating Records and RecordSets, they are finding the url quite long and cumbsersome
17:37:15 <vinod1> the concern here seems to be the advantages of having the recordsets outweigh having the long URLS for accessing a record
17:37:19 <Kiall> rjrjr_: yes, I think it makes sense - and ties in with some of the min-dns needs
17:38:21 <Kiall> 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 <rjrjr_> not particularly familiar with the API, but shouldn't recordsets be obfuscated from API users?
17:38:41 <rjrjr_> this part of the API.
17:39:15 <betsy> rjrjr_: That's my question to Kiall.
17:39:17 <Kiall> rjrjr_: No, the URL ends up /v2/zones/<ZONEID>/recordsets/<RRSETID>/records/<RECORDID>
17:39:19 <Kiall> so - Long
17:39:32 <betsy> Yes. Very long with 3 recordids
17:39:39 <vinod1> so what is the intention of having recordsets?
17:39:58 <vinod1> is it to enforce the same ttl for records?
17:40:27 <betsy> ^ or 3 different IDs rather
17:40:39 <Kiall> 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 <Kiall> Yes, Mainly focuses on the TTL
17:41:24 <betsy> Is there a way we can do this without exposing the RRS resource to the end user?
17:41:39 <Kiall> 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 <Kiall> among*
17:42:09 <rjrjr_> do all records use recordsets?
17:42:29 <Kiall> 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 <Kiall> When someone queries for IN A example.com against, say, google DNS
17:42:59 <Kiall> google DNS will cache the first record for 100 seconds, the second for 200 seconds.
17:43:14 <Kiall> For the first 100 seconds, people will get back 2 records - 1.1.1.1, and 2.2.2.2
17:43:23 <Kiall> for seconds 101 through 200, they will only get 2.2.2.2 back
17:43:31 <Kiall> Which is totally unexpected
17:43:40 <vinod1> wouldn't this be pilot error?
17:43:52 <Kiall> rjrjr_: yes, all records belong to recordsets
17:44:04 <rjrjr_> if that is the case, can't we hide this from the user?
17:44:07 <Kiall> vinod1: absolutely, but it's also a violation of the DNS specs
17:44:20 <vinod1> at create/update time, can we check that the other ttl is different and fail the create/update
17:44:36 <Kiall> 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 <Kiall> "Automatic" update behind the scenes is unexpected, they didn't ask for the second record to be changed
17:45:24 <rjrjr_> we can't just change the first record's TTL?
17:45:31 <vinod1> how about the ability to update multiple records belonging to a single zone in the same request
17:45:43 <Kiall> Anyway - Here's my question, what percentage of API calls do we expect a human to be making by hand?
17:46:19 <Kiall> I expect the vast majority will be using Horizon (other consoles) and client libraries/language bindings
17:46:42 <rjrjr_> i think this is unknown.  if you expose it, people will use it has been my experience.
17:47:01 <Kiall> 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 <richm> what about the designate command line tool?
17:47:37 <tsimmons> That's my stance on that, no one is going to be adding data to the API manually.
17:47:38 <Kiall> 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 <betsy> Still seems like a lot of overhead just to enforce the TTL's
17:48:22 <vinod1> in any case - users now have to understand the recordset concept
17:48:24 <Kiall> 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 <Kiall> keystoneclient model*
17:48:35 <rjrjr_> 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 <Kiall> rjrjr_: well, if RRSets are hidden in the API, then they can't update it on the RRSet?
17:49:48 <rjrjr_> so TTL is part of a recordset and a record?  why not just make it part of the record?
17:50:09 <rjrjr_> is the only reason we are exposing the recordset because of the TTL?
17:50:22 <richm> 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 <rjrjr_> hence the recordset being exposed.
17:50:52 <Kiall> rjrjr_: it's "exposed in order to facilitate adherence to the DNS RFCs" would be my carefully worded answer :)
17:51:11 <Kiall> richm: that violates the spec :)
17:51:23 <richm> Kiall: you mean rfc 1034?
17:51:48 <Kiall> http://tools.ietf.org/html/rfc2181 Section 5
17:53:12 <Kiall> 6 mins left
17:53:30 <richm> ok, I see
17:53:41 <vinod1> i would still like to enforce the spec without introducing a recordset concept
17:53:55 <vinod1> the zone file too has just records and not recordsets
17:54:07 <Kiall> vinod1: I'm not sure any alternatives exist that don't add other complications
17:54:08 <rjrjr_> why not give the user the option to work with recordsets or not?  /zones/<id>/records/<id> or /zones/<id>/recordsets/<id>/records/<id>
17:54:40 <rjrjr_> if they choose not to work with them directly, the code handles them for the user on the backend.
17:54:52 <Kiall> rjrjr_: that adds the complication of surprise TTL changes to records your not intending to edit
17:55:14 <rjrjr_> how?
17:55:24 <vinod1> how about an action item for me to come up with some alternatives and we discuss this again next week?
17:55:30 <richm> 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 <Kiall> Also relevant, here's a snippet from AWS Route53 API: http://paste.openstack.org/show/73840/
17:55:45 <betsy> vinod1: Good idea as we're running short on time
17:55:52 <tsimmons> 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 <Kiall> #link http://paste.openstack.org/show/73840/
17:56:16 <vinod1> #link http://tools.ietf.org/html/rfc2181
17:56:22 <Kiall> tsimmons: mugsie literally just ran out to another meeting, I haven't had a chance to discuss it with him today
17:56:27 <rjrjr_> i have a question, but i can move it to #openstack-dns.
17:56:28 <Kiall> s/today/this week/
17:56:52 <vinod1> #action vinod to come up with alternatives to recordsets
17:56:55 <tsimmons> 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 <Kiall> #action Everyone to think about RRSets, reread the logs from the conversation, and come with alternatives and pro's con's
17:57:10 <Kiall> vinod1: snap ;)
17:57:14 <vinod1> 4 more mins and 2 more items on the agents
17:57:31 <vinod1> we can move the 2 remaining items to next week
17:57:34 <vinod1> any other questions
17:57:36 <Kiall> Lets move real real quick onto .. TenantId in URL.. I think I can kill it it a few seconds ;)
17:57:49 <vinod1> #topic TenantId in URL
17:57:57 <vinod1> 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 <vinod1> #link http://api.openstack.org/api-ref-blockstorage.html
17:58:21 <vinod1> #link http://api.openstack.org/api-ref-compute.htmlml
17:58:27 <Kiall> 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 <eankutse> do they come in headers then?
17:58:55 <Kiall> There have been lots of conversations over the last year or so about there merits, I'll try dig them up
17:58:57 <vinod1> hmm - so what were the issues they had
17:59:07 <Kiall> #action kiall to dig up ML archive entries around tenant id's in URLs
17:59:19 <vinod1> ok
17:59:23 <rjrjr_> long URLs?  LOL
17:59:24 <vinod1> time to wrap up
17:59:25 <Kiall> vinod1: two of the main ones are..
17:59:37 <Kiall> 1) viewing all tenants stuff ends up funky
17:59:50 <Kiall> 2) Placing a versionless URL into the catalog becomes impossible
18:00:09 <vinod1> #endmeeting