17:00:26 <kiall> #startmeeting designate
17:00:27 <openstack> Meeting started Wed Aug 14 17:00:26 2013 UTC and is due to finish in 60 minutes.  The chair is kiall. Information about MeetBot at http://wiki.debian.org/MeetBot.
17:00:28 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
17:00:31 <openstack> The meeting name has been set to 'designate'
17:00:43 <kiall> and - I just broke my chair. heh. 2 sec
17:00:59 <bluzader> :O
17:00:59 <eankutse> :-)
17:01:14 <kiall> Okay :)
17:01:17 <simonmcc> mugsie get's 2 broken chairs on his first dat
17:01:26 <kiall> Heyas! Who's about for the Designate/DNSaaS meeting?
17:01:36 <simonmcc> o/
17:01:45 <vinodmr> vinod here
17:01:45 <bluzader> me
17:01:45 <mugsie> o/
17:01:45 <eankutse> eankutse
17:01:55 <tsimmons> Me :D
17:02:18 <kiall> Agenda is short - Another round of APIv2.. Unless anyone has an item?
17:02:24 <kiall> #topic APIv2
17:02:30 <eankutse> APv2 is good
17:02:59 <kiall> So - over the last few days, a discussion has started on the openstack-dev mailing list around pagination in the openstack APIs
17:03:04 <kiall> #link http://lists.openstack.org/pipermail/openstack-dev/2013-August/013493.html
17:03:08 <kiall> First email in the thread ^
17:03:14 <kiall> I'll summarize though..
17:03:22 * CaptTofu is here
17:03:34 <kiall> So - page/per_page is being removed from the Keystone V3 API, in favor of marker/limit
17:04:12 <kiall> The thread tends to go 1 of 2 ways.. either people say marker/limit is higher performance, or the Horizon guys say it's next to impossible to use in a UI
17:04:19 <eankutse> so Designate will confirm - right?
17:04:33 <eankutse> *conform*
17:04:45 <kiall> I've no real preference for anything other than conforming to the standards that the other projects set..
17:05:00 <vinodmr> One of the objections cited in favor of page/per_page was that any page can be accessed rather than moving in the forward direction and accessing just the previous page.
17:05:01 <mugsie> same
17:05:17 <kiall> Does anyone have a good reason why we shouldn't conform?
17:05:42 <eankutse> Semantically both are the same
17:05:44 <bluzader> I don't think any of us are UI guys
17:05:45 <eankutse> yes?
17:05:55 <kiall> I think UI's are painful with limit/marker.. And traditional pagination controls are out..  BUT Horizon etc will get the necessary parts to make it work
17:06:00 <eankutse> so conforming to the parameter name is fine with me
17:06:03 <kiall> mugsie does lots of UI work :)
17:06:10 <mugsie> for the next week ;)
17:06:17 <kiall> eankutse: well, it's much more than the param name
17:06:30 <kiall> so page=1&per_page=10
17:06:31 <simonmcc> I was going to say that UI is probably the most likely consumer of our customer facing DNS solutions - so should help direct a choice in favour of UI friendly pagination
17:06:44 <kiall> vs marker=<UUID of last item on previous page>&limit=10
17:07:03 <bluzader> I would lean more towards making the UI easier rather than conforming for no reason
17:07:03 <kiall> and to go backwards, marker=<UUID of last item on previous page>&limit=10&sort_dir=DESC
17:07:33 <vinodmr> Would the marker in designate be a UUID that is randomly generated or that keeps increasing as time progresses?
17:07:44 <kiall> bluzader: Yea - I tend to agree, but the "offical" UI, and any other copropate custom UIs are going to have to deal with limit/marker anyway
17:08:03 <ekarlso-> ello folks
17:08:04 <kiall> vinodmr: it would be the ID of the last domain/record/etc on the page your looking at
17:08:27 <kiall> corporate*
17:08:41 <mugsie> UIs can store the previous markers, as pointed out in the thread
17:08:55 <tsimmons> Just doesn't seem as clean to me, but conforming is probably the right thing to do especially if other people are going to have to figure out UI's before us.
17:09:17 <kiall> tsimmons: yea.. I know the feeling :)
17:09:45 <kiall> Anyway - I think the UIs that deal with nova/glance/keystone/designate will support this style of pagination.. So, I argue we conform
17:09:51 <bluzader> ttsimmons: true
17:10:32 <kiall> So - Does anyone think we should stick with page/per_page (or page/limit) ?
17:10:34 <vinodmr> Has Horizon already done pagination with nova/glance/keystone etc?
17:10:42 <CaptTofu> conforming would also bode well for things like incubation
17:10:44 <kiall> vinodmr: ehh - I don't think so to be honest
17:10:57 <kiall> CaptTofu: yea.. good point.
17:11:11 <kiall> I've never noticed pagination in horizon anyway...
17:11:32 <kiall> So ..
17:11:36 <bluzader> Are all OpenStack projects going to change?
17:11:42 <bluzader> Does Keystone set the standard?
17:12:11 <kiall> bluzader: I believe glance and nova already do it this way
17:12:26 <bluzader> Ah. Then it makes sense that we change
17:12:34 <kiall> #startvote Should we conform to the limit/marker pagination pattern in the V2 API? yes, no, maybe
17:12:35 <openstack> Begin voting on: Should we conform to the limit/marker pagination pattern in the V2 API? Valid vote options are yes, no, maybe.
17:12:36 <openstack> Vote using '#vote OPTION'. Only your last vote counts.
17:12:38 <kiall> #vote yes
17:12:48 <kiall> so - lets get a show of hands!
17:12:52 <vinodmr> #vote yes
17:12:57 <mugsie> #vote yes
17:12:58 <bluzader> #vote yes
17:13:03 <tsimmons> #vote yes
17:13:06 <eankutse> #vote yes
17:13:08 <msisk_> #vote yes
17:13:21 <kiall> Any stragglers? simonmcc / CaptTofu ?
17:13:44 <simonmcc> #vote yes
17:13:46 <CaptTofu> #vote yes
17:13:56 <kiall> 5 ... 4 ... 3...
17:13:58 <kiall> #endvote
17:13:59 <openstack> Voted on "Should we conform to the limit/marker pagination pattern in the V2 API?" Results are
17:14:00 <openstack> yes (9): eankutse, simonmcc, bluzader, CaptTofu, tsimmons, vinodmr, mugsie, msisk_, kiall
17:14:12 <kiall> So .. that's a yes. I'll update the spec.
17:14:40 <bluzader> I've got a quick question on v2API
17:14:58 <bluzader> Do the RecordSets replace Records, or are there Records and RecordSets
17:15:39 <kiall> bluzader: So, yes and no .. RecordSets brings our model closer to the various DNS specs, and makes it MUCH easier to prevent out-of-spec values.
17:16:07 <kiall> There won't be a separate /records API endpoint, but there is an array of records which belong to a RecordSet in the /recordsets/1234 response
17:16:39 <kiall> Make sense?
17:17:08 <bluzader> I'm not sure. It makes a big change from the way we're currently doing our DNS
17:17:36 <eankutse> But the spec also indicates that all records in a RecordSet should have the same TTL and that seems to be too much of a restriction
17:17:44 <bluzader> I, obviously, need to read the spec more
17:17:59 <bluzader> eankutse: I agree
17:18:08 <bluzader> That part doesn't make sense to me at all
17:18:17 <kiall> eankutse: all good DNS servers will pick the lowest TTL from all the records wit the same (rclass, rtype, rname) tuple and serve it
17:18:46 <kiall> So - If you have 2 A records at "www.example.org.", one with TTL 3600 and one with TTL 300, both will be served with 300
17:18:52 <kiall> and if they don't..
17:19:01 <kiall> they the load balancing you are expecting will fail.
17:19:13 <kiall> after 300 seconds, resolvers will discard the 300 one, and keep the 3600 one..
17:19:31 <kiall> for the next 3300 seconds, it's as if you only have 1 A record for "www.example.org."
17:19:59 <bluzader> hmm
17:20:20 <bluzader> As I said, I, obviously, need to spend more time in the spec to fully understand the pros and cons
17:20:33 <kiall> The original specs allowed for differing TTL for a given (rclass, rtype, rname). But it proved to be broken and was depreciated in rfc2181
17:20:48 <bluzader> Ah. I didn't realize that
17:21:16 <bluzader> Now RecordSets are making more sense to me
17:21:33 <kiall> Yea - I was surprised the first time I read that RFC too.. It gives a good explanation of the issues from memory.
17:21:52 <vinodmr> kiall: So in your eg. when you do a get recordset, you would get both the A records, but only 1 TTL value of 300.  Is that right?
17:22:03 <kiall> #link http://www.ietf.org/rfc/rfc2181.txt
17:22:32 <bluzader> vinodmr: that's right
17:22:40 <kiall> vinodmr: correct, you would get back {"ttl": 300, "records": [<record 1>, <record 2>], ...}
17:23:03 <bluzader> vinodmr: the only thing that varies in a recordset are the IP addresses
17:23:13 <kiall> and your DNS server will spit out both records, with the same TTL (which it should do anyway, even if you configure 2 different TTLs)
17:23:33 <kiall> well - the rdata differs. SO for a A, that's just the IP address
17:23:43 <kiall> for SRV, it's priority, port, weight, target
17:23:45 <kiall> etc
17:24:07 <bluzader> kiall: right. I was thinking of only A records
17:24:15 <kiall> and for MX priority+exchange differ :)
17:24:16 <bluzader> It's only the "data" that varies
17:24:56 <kiall> Also - as another datapoint .. Amazon's Route53 went the RecordSet route from memory
17:25:08 <kiall> (That's wasn't a deciding factor in any way!P
17:25:11 <kiall> ..)*
17:25:41 <bluzader> kiall: Thx for explanation. It's making more sense to me now
17:25:57 <kiall> So - Any lingering concerns over the use of RecordSet's?
17:26:15 <bluzader> kiall: Not from me at this point.
17:26:23 <vinodmr> Is there any way to know the acutal TTL values that are configured using the API?
17:27:05 <kiall> vinodmr: yea, the RecordSet will include the configured TTL for all records which are part of that RecordSet (or null, if the recordset inherits the default TTL from the parent domain)
17:27:55 <kiall> http://pastie.org/private/dke2mocexwilfwpqcmvivg <-- Route53's XML representation of a RecordSet
17:28:19 <kiall> Conceptually, that's very similar to what we propose for the V2 API
17:28:49 <kiall> Okay .. Next up :)
17:29:05 <kiall> we wanted to get any final feedback on the V2 API conventions, and if there is nothing else, we'll start merging framework code ASAP. I'll likely merge the base framework tomorrow. i.e. this one -> https://review.openstack.org/#/c/39077/
17:29:41 <kiall> Then, over the next week or two finalize any core changes needed to make the conventions work.
17:30:40 <kiall> #action Kiall to update spec for limit/marker/sort_dir/sort_key
17:30:42 <kiall> (Forgot to add ^ earlier)
17:31:34 <kiall> Anybody have any more comments/suggestions/issues with the conventions used in the APIv2 spec? :)
17:31:49 <simonmcc> I have no issues at this stage
17:32:08 <eankutse> none
17:32:30 <kiall> Okay .. I'll take that as a no from everyone! :)
17:32:31 <kiall> #topic Any other business? Ask away.
17:32:41 <eankutse> I'll read up on the updates of the doc again
17:32:57 <kiall> So - Anything else from anyone at all? Doesn't have to be APIv2 related :)
17:32:59 <eankutse> How's progress on State Machine
17:33:30 <simonmcc> State Machine?
17:33:59 <kiall> simonmcc: the domain/record "status" field.. e.g PENDING, ACTIVE etc
17:34:01 <kiall> eankutse: I've not began writing any code - Before that gets added, backends need to become async capable.
17:34:05 <eankutse> yes. Kiall was coming up with one for zones the other day
17:34:22 <kiall> Otherwise, the status are always just "ACTIVE" and there are no transitions really :)
17:34:43 <eankutse> k
17:35:24 <kiall> The current plan is - each of the backend methods will return a dict with a couple of keys in it, for status stuff, there will be "complete" = True/False key
17:35:50 <eankutse> k
17:35:51 <kiall> if complete = True, we'll do what we do today, and return a synchronous status code with status=ACTIVE
17:36:02 <bluzader> kiall: that sounds cool. Have you written a blueprint for it?
17:36:25 <kiall> and if complete = False, we'll return the async status code.. and expect the backend to update the record/domain status whenever it's completed it's change
17:36:46 <kiall> bluzader: semi :) https://blueprints.launchpad.net/designate/+spec/domain-status
17:36:51 <kiall> it's expanded from there though
17:37:05 <kiall> eankutse: do you have the link to the state machine graphic I sent you?
17:38:14 <eankutse> I can find it
17:39:16 <kiall> #link https://dl.dropboxusercontent.com/u/1400487/graphviz-fd80799c9423325e8616080d6ae7d1af8a96b5f6.png
17:39:32 <kiall> #link https://dl.dropboxusercontent.com/u/1400487/graphviz-9c55129fd4d85273bcd3c6dc6fdae2471124e420.png
17:39:37 <kiall> one for domains, one for recordsets
17:39:47 <eankutse> Thx
17:39:53 <kiall> No problem :)
17:40:23 <kiall> So, the domain status and async backend stuff really ties into each other.. and the async backend stuff needs to come first
17:40:43 <eankutse> yes
17:41:04 <kiall> Okay - Any more questions/comments before we call it a day?
17:41:19 <eankutse> not me
17:41:34 <vinodmr> none from me either
17:41:43 <mugsie> nope
17:41:47 <simonmcc> any progress on a designate face to face before HK?
17:41:53 <kiall> Okay - That's all :) Hopefully we'll have some of this V2 API stuff merged and ready to play with before next weeks meeting.
17:42:19 <kiall> simonmcc: I think there was budget issues on the HP side ..
17:42:32 <simonmcc> :-)
17:42:48 <kiall> HK has pushed the travel budget pretty far this year :(
17:43:21 <CaptTofu> @simonmcc I need to re-ask
17:43:21 <mugsie> all the more reason we should all go to HK ;)
17:43:41 <simonmcc> I don't think RAX are planning on going to HK?
17:43:45 <kiall> Okay - Thanks everyone :) Speak in #openstack-dns later!
17:43:48 <CaptTofu> @simonmcc I think management was thinking of possibly some place a bit inbetween Ireland and TX
17:43:49 <kiall> #endmeeting