17:00:24 <vinod> #startmeeting Designate
17:00:25 <openstack> Meeting started Wed Apr  9 17:00:24 2014 UTC and is due to finish in 60 minutes.  The chair is vinod. Information about MeetBot at http://wiki.debian.org/MeetBot.
17:00:26 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
17:00:28 <openstack> The meeting name has been set to 'designate'
17:00:30 <vinod> who's here?
17:00:57 <kiall> Heya
17:01:03 <mugsie> o/
17:01:15 <eankutse> her
17:01:17 <eankutse> here
17:01:18 <tsimmons> o/
17:01:25 <vinod> #topic Review action items from last week
17:01:40 <richm> here
17:01:45 <vinod> Both the action items were to add agenda action items.  They were done
17:01:53 <kiall> 2x actions for me - Both to put stuff on agenda for today. Done
17:02:11 <vinod> #topic Workshop Meetup - 17:00 UTC via Hangout
17:02:22 <kiall> BTW - Myself and mugsie will have to leave this meeting a little early
17:02:30 <vinod> #link https://etherpad.openstack.org/p/DesignateAtalantaWorkshop
17:02:48 <vinod> Mugsie what day would the hangout be?
17:03:15 <mugsie> on monday
17:03:18 <mugsie> next week
17:03:23 <mugsie> I just added it there ;)
17:03:26 <kiall> 14th?
17:03:30 <mugsie> yup
17:03:46 <mugsie> was a brain fart on my side
17:03:58 <mugsie> rjrjr_: do you want to stay on after that and talk about our talk?
17:04:05 <rjrjr_> yes.
17:04:11 <rjrjr_> what time monday?
17:04:27 <mugsie> 17:00 UTC -> 18:00 UTC
17:04:36 <mugsie> then 18:00 on wards for us
17:04:43 <vinod> so about an hour earlier than now
17:04:53 <mugsie> no, this time actually
17:05:03 <kiall> really? It's 17:00 UTC right now?
17:05:05 <mugsie> we are UTC +1 at the moment
17:05:18 <ekarlso> yo
17:05:25 <eankutse> that works for me
17:05:56 <rjrjr_> where do i find the information about the hangout meetup?
17:06:08 <mugsie> i will send it on after this meeting
17:06:10 <kiall> Cool :) Graham has everyones's google acct details.. So we'll let him organize the hangout.
17:06:25 <kiall> #action mugsie to Send out invite etc for Hangout on Mon 14th @ 17:00 UTC
17:07:02 <kiall> rjrjr_: no details other than "Workshop planning" and https://etherpad.openstack.org/p/DesignateAtalantaWorkshop
17:07:14 <rjrjr_> okay
17:07:17 <vinod> anything more on the workshop before we move to the next item?
17:07:35 <vinod> #topic RRSets APIs - Decision time
17:07:37 <kiall> Not from me..
17:07:40 <kiall> #link https://wiki.openstack.org/wiki/Designate/Blueprints/RecordSets
17:07:56 <kiall> Okay - So, I added a Proposal #4 (and re-titled the existing proposals)
17:08:12 <kiall> Can everyone take 5 mins or so to re-read them?
17:08:23 <vinod> doing now
17:10:42 <vinod> so proposal 4 is essentially the same as what we had before as the design - correct?
17:10:44 <eankutse> Kiall: how different is this from the one proposed last week?
17:11:19 <kiall> vinod / eankutse Proposal 3 and 4 are quite similar, but each proposes a different resource is kept
17:11:44 <kiall> Proposal 4 looks very similar to the original V2 spec (i.e. not what got implemented in the end..)
17:12:17 <rjrjr_> were there problems in implementation?
17:12:47 <vinod> with proposal 4 - can we also have a PUT which would be completely replace the existing with the new
17:12:58 <kiall> eankutse: So, there was 3 proposals last week, the first 3 on that page are the same as last week, just with a new heading for easier referencing :) Proposal 4 is new since last week, but it what I suggested last week
17:13:13 <vinod> the reasoning being that if we have more changes than the modify could be pretty ugly
17:13:20 <eankutse> k
17:14:01 <mugsie> vinod: the PATCH would replace the entire resource
17:14:04 <kiall> all updates in P4 replace the set, with JSONPatch offering support to mutate the set in place where needed
17:14:25 <mugsie> and the to add, you would use JSON+Patch
17:14:35 <mugsie> ah, kiall just said it
17:14:38 <kiall> rjrjr_: yes, there was implementation difficulties - But, we're in a better spot to address those now than we were
17:15:41 <kiall> Now that backend operations are performed within a TX, we can add a new "replace_records" or similar method that replaces the set as a whole in 1 go, in 1 TX
17:16:09 <vinod> from an implementation perspective, kiall were you thinking about having a table for recordsets and another for records similar to now
17:16:11 <kiall> Anyone still reading BTW?
17:16:22 <rjrjr_> still here.
17:16:23 <richm> yes
17:16:41 <richm> What data is associated with a recordset, other than ttl?
17:16:58 <kiall> richm: name, type, TTL
17:17:12 <kiall> potentially more if/when we add more advanced features
17:17:13 <richm> of those, what is allowed to be changed?
17:17:29 <kiall> for example - GeoIP - RRSet #1 for EU queries, RRSet #2 US
17:17:46 <richm> ok
17:17:55 <kiall> richm: ttl, and we could allow name to change.. we just don't currently
17:18:13 <kiall> vinod: re the tables - I think this BP happens regardless https://wiki.openstack.org/wiki/Designate/Blueprints/Records_Table_Redesign
17:18:29 <kiall> i.e. no matter what is chosen here, records gets split
17:18:39 <rjrjr_> so, some of the "difficulties" in the code is around creating recordset then record, etc.?  (i also see a bug was found where recordsets are not deleted with records.)  will this help with that?  can some of the central code be simplified?
17:19:25 <kiall> rjrjr_: yes, all the central code for records goes away - RecordSets would be the only thing it knows about with P4
17:20:01 <kiall> So, the DB layer would, inside a TX, create the RRSet entry, then the Nx RR entries .. Should one fail, it aborts the TX and keeps things clean
17:20:49 <kiall> Anyone still reading BTW?
17:21:08 <vinod> i assume you mean reading the proposals - no i am done
17:21:12 <rjrjr_> okay, my objects last week are being retracted. 8^)  this looks better.
17:21:24 <rjrjr_> objects = objections
17:21:26 <kiall> vinod: Yea, I mean reading the proposals :)
17:21:46 <vinod> decision time or any more questions still lingering in people's minds?
17:22:05 <kiall> So .. Say everyone is done reading.. Let's go thought them one by one?
17:22:14 <richm> ok
17:22:20 <kiall> ==== Proposal 1
17:22:40 <kiall> Anyone have any pros/cons for P1?
17:23:16 <kiall> Personally, I dislike the "?modify-rrset" query string, and that without that, a update TTL on a 1 vs 2+ record RRSet behaves differently.
17:23:53 <richm> For those folks who actually have to administer DNS - is the concept of managing recordsets separately from records a natual one?  So would it be natural to want to modify the ttl (or other attributes) of a recordset separately from records?
17:24:04 <richm> natural
17:24:34 <rjrjr_> in BIND, they just manage records.  recordsets are "background".
17:24:36 <richm> I also dislike the ?modify-rrset
17:25:21 <vinod> Pros - Would be that the users deal with records and not recordsets
17:25:32 <kiall> rjrjr_: yea, in BIND (and many DNS servers) RRSets are hidden away - But, if your managing a DNS server and don't understand them - chances are your zonefiles are invalid, and BIND is silently serving something different than what you told it to
17:25:43 <richm> rjrjr_: in BIND, how do you change the ttl in a recordset?
17:25:44 <vinod> Cons - Modifying the recordset is clumsy
17:26:09 <kiall> vinod: Yep - Agreed on both your Pros/Cons
17:26:10 <rjrjr_> you change the TTL for all the records.  lowest TTL wins!
17:26:17 <richm> egads
17:26:28 <rjrjr_> you asked. 8^)
17:26:32 <richm> that seems . . . sub-optimal
17:26:42 <kiall> rjrjr_: So, to me, that's not right. Since when i fetch a record via the API, and see ttl=300
17:26:49 <kiall> then do a DNS query and see ttl=60
17:26:55 <kiall> something is wrong ;)
17:27:52 <kiall> Any other thoughts on P1? Anyone disagree with anything said ^?
17:28:01 <vinod> No
17:28:25 <kiall> Okay .. Moving on ;)
17:28:27 <kiall> ==== Proposal 2
17:29:07 <vinod> This essentially seeks to mimic BIND's behavior
17:29:19 <kiall> My last comment from above is really related to this one, as P1 enforces the TTLs are the same, while P2 proposes to use lowest TTL wins behaviour similar to BIND
17:30:03 <kiall> Anyone have pro/con's for P2?
17:30:28 <rjrjr_> pro: it's what most administrators of BIND expect.
17:31:05 <vinod> cons: dns behavior might not be consistent with what api shows
17:31:09 <kiall> rjrjr_: Can't argue with that :) But, for me, the average Designate end-user isn't a DNS admin
17:32:21 <kiall> Designate should be taking half the DNS admin's job (updating zonefiles), and delegating that to the user who would have been submitting a ticket for that change ..
17:32:21 <richm> fits with the way IPA works too - if you change the ttl of a record, it actually changes the ttl of the recordset
17:33:06 <kiall> so - IPA doesn't expose RRSets in it's APIs, but internally enforces consistency?
17:33:06 <mugsie> I would say keeping the API data cnsistant with the end result is requirement
17:33:15 <richm> kiall: right
17:34:19 <kiall> richm: so, how would we enforce lowest TTL wins with IPA?
17:34:28 <kiall> It sounds like with IPA, latest TTL wins?
17:34:32 <richm> right
17:34:51 <richm> enforcing lowest ttl wins would be more difficult
17:35:16 <richm> will have to see if ipa can enforce that on the server side
17:35:17 <vinod> so essentially modifying one record's ttl could modify some other records ttls too
17:35:25 <richm> right
17:35:30 <kiall> New con: We can't easily implement this is a way that is consistent cross different DNS servers
17:35:35 <rjrjr_> Proposal 5 - Handle TTLs Implicitly - latest TTL wins. 8^)
17:35:43 <kiall> rjrjr_: lol
17:36:27 <kiall> Okay .. So, moving on?
17:36:43 <kiall> Or anything else before we do?
17:36:59 <richm> no
17:37:25 <vinod> ==== Proposal 3
17:37:30 <kiall> Okay
17:38:19 <vinod> this is mostly similar to proposal 4 except for the terminology and modify
17:38:43 <kiall> So .. I can't come up with much in the way of cons for this one to be honest. Essentially, it's RecordSets being called Records, and update being a little different
17:39:10 <vinod> Cons: We talk about recordsets without calling them recordsets - could be more confusing
17:39:19 <mugsie> +1
17:39:27 <rjrjr_> i like proposal 4 API better ("record" instead of "data", etc.)
17:39:29 <richm> how does this correspond with how other DNS servers (other than BIND) are managed?
17:39:43 <mugsie> also, not sure i like the PUT vs PATCH works either
17:40:10 <kiall> richm: RecordSets can be mapped onto any DNS (they have to be!). But, with some DNS servers, we'll have to "explode" the RRSet in a list of Records
17:40:30 <kiall> But - Zonetransfers with mDNS should make that just work
17:41:13 <kiall> rjrjr_: I think the "records" vs "data" etc is not really important, it's the concept we're aiming to agree on :)
17:41:24 <kiall> (not important *right now* ;))
17:41:33 <richm> I mean - it sounds like this proposal may be difficult for BIND admins to grok - but what about pdns, nsd, etc.?
17:41:57 <rjrjr_> i don't think it is difficult, just different.
17:42:22 <richm> It seems more natural to me, and aligns better with the DNS specs
17:42:37 <kiall> P3 and P4 are both likely to cause a double take for DNS admins.. But, DNS Admins are likely not our primary audience
17:44:26 <kiall> Any other pros/cons on this one?
17:44:30 <richm> about PATCH - is it supported everywhere?
17:44:50 <kiall> Yea, it certainly should be
17:45:09 <kiall> The bad old days of GET/POST being the only things that worked are gone thanks to APIs :)
17:45:28 <kiall> (We also use PATCH elsewhere in the v2 API, as do several other OS APIs)
17:45:33 <richm> ok
17:46:00 <richm> Then it looks like the usage of PUT vs. PATCH is as intended by the HTTP docs
17:46:04 <kiall> So - No other comments/pros/cons on P3?
17:46:41 <rjrjr_> vote?
17:46:46 <kiall> richm: Kinda, PUT is applying PUT's semantics onto a single element within the payload.. But, it's closer than most APIs get to doing it right ;)
17:47:02 <kiall> ==== Proposal 4
17:47:03 <richm> well, let's just say it makes sense in this context
17:47:33 <kiall> Okay - Cons.. We use the word "RecordSets" - this can be scary
17:47:51 <kiall> Who has pros/cons on this one?
17:48:31 <kiall> Pros: Maps to the DNS specs - So will fit on any DNS server while keeping data in the API, and in DNS consistent
17:48:38 <mugsie> I prefer the idea of JSON+PATCH - it shows a good flow of what the modifications are
17:48:56 <vinod> Cons: New concept recordsets.  If we want to add just one record (how many % of the users?) we need to think in terms of recordsets
17:49:27 <vinod> Cons: The zone file does not have recordsets - just records.  But the api has recordsets and not records
17:49:28 <eankutse> Con: doing away with the concept of Record
17:49:31 <mugsie> true, but for most of the users who will have issues, they will be using a CLI / horizon panel
17:49:35 <kiall> vinod: if your just adding 1 record, then it's a s/record/recordset/ and it should be pretty similar
17:49:52 <eankutse> now Record is RecordSet with one member - a little heavy-duty
17:49:54 <mugsie> eankutse: the concept of record is there, but as a paylod in a recordset
17:50:36 <kiall> vinod: BIND zone files do have RRSets, implicitly.
17:50:56 <mugsie> yeah, it is the same info that we would be providing if it was called a record.. and it does align with the RFCs.
17:51:22 <kiall> Pro AND Con: This is the same data model as AWS's Route53. As i said.. Pro AND Con ;)
17:51:47 <vinod> kiall/mugsie: how are you on time?  do you want to start a vote?
17:51:59 <kiall> eankutse: also, most users will be using JClouds, Python bindings, Web Console..
17:52:24 <kiall> vinod: Does everyone have a clear #1 in mind?
17:52:31 <richm> kiall: interesting - do you have a url for the route53 docs?
17:52:36 <kiall> We're fine on time
17:52:45 <kiall> (dont need to leave anymore)
17:52:58 <kiall> richm: http://awsdocs.s3.amazonaws.com/Route53/20130401/route53-api-20130401.pdf
17:53:19 <kiall> RRSet = Resource Record Set BTW, they call them that
17:54:16 <kiall> http://pastie.org/9057085 - example
17:54:47 <richm> ok - thanks
17:55:09 <kiall> Okay. 5 mins left.. Is anyone ready to vote? Say Yes or No please :)
17:55:15 <richm> Yes
17:55:16 <rjrjr_> yes
17:55:17 <mugsie> yes
17:55:18 <kiall> Yes
17:55:32 <vinod> yes
17:55:42 <eankutse> yes
17:55:54 <kiall> Ok...
17:56:00 <kiall> #startvote Which RecordSet proposal? P1, P2, P3, P4
17:56:00 <openstack> Only the meeting chair may start a vote.
17:56:07 <kiall> grr.. vinod :)
17:56:13 <vinod> irc://morgan.freenode.net:6667/#startvote Which RecordSet proposal? P1, P2, P3, P4
17:56:27 <rjrjr_> P4
17:56:33 <kiall> lol .. that prefix isn't right ;) Try again?
17:56:35 <eankutse> P4 with slight reservation
17:56:35 <vinod> #startvote Which RecordSet proposal? P1, P2, P3, P4
17:56:35 <openstack> Begin voting on: Which RecordSet proposal? Valid vote options are P1, P2, P3, P4.
17:56:36 <openstack> Vote using '#vote OPTION'. Only your last vote counts.
17:56:44 <kiall> Okay
17:56:44 <mugsie> #vote P4
17:56:47 <kiall> #vote P4
17:56:51 <vinod> #vote P4
17:56:53 <rjrjr_> #vote P4
17:57:02 <eankutse> #vote P4 with slight reservation
17:57:03 <openstack> eankutse: P4 with slight reservation is not a valid option. Valid options are P1, P2, P3, P4.
17:57:12 <rjrjr_> lol
17:57:15 <mugsie> :D
17:57:29 <kiall> eankutse: the bot told you odd ;)
17:57:38 <kiall> #showvote
17:57:39 <openstack> P4 (4): mugsie, rjrjr_, kiall, vinod
17:58:04 <eankutse> #vote P4
17:58:07 <kiall> So .. eankutse / richm let?
17:58:09 <kiall> left*
17:58:17 <richm> #vote P4
17:58:29 <rjrjr_> that's everyone.
17:58:30 <vinod> kiall is there an endvote?
17:58:36 <kiall> Yep #endvote
17:58:44 <vinod> #endvote
17:58:45 <openstack> Voted on "Which RecordSet proposal?" Results are
17:58:46 <openstack> P4 (6): eankutse, vinod, rjrjr_, mugsie, kiall, richm
17:59:02 <kiall> That's not what I expected :) I was thinking people were leaning towards P3!
17:59:18 <vinod> you were convincing kiall :-)
17:59:24 <kiall> #action kiall to put Mini-DNS: Can we rename it to something less provoking, like ZoneTransfer Module? on agenda for next week, again
17:59:35 <kiall> That's time :)
17:59:43 <vinod> #endmeeting