17:00:26 #startmeeting designate 17:00:27 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 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 17:00:31 The meeting name has been set to 'designate' 17:00:43 and - I just broke my chair. heh. 2 sec 17:00:59 :O 17:00:59 :-) 17:01:14 Okay :) 17:01:17 mugsie get's 2 broken chairs on his first dat 17:01:26 Heyas! Who's about for the Designate/DNSaaS meeting? 17:01:36 o/ 17:01:45 vinod here 17:01:45 me 17:01:45 o/ 17:01:45 eankutse 17:01:55 Me :D 17:02:18 Agenda is short - Another round of APIv2.. Unless anyone has an item? 17:02:24 #topic APIv2 17:02:30 APv2 is good 17:02:59 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 #link http://lists.openstack.org/pipermail/openstack-dev/2013-August/013493.html 17:03:08 First email in the thread ^ 17:03:14 I'll summarize though.. 17:03:22 * CaptTofu is here 17:03:34 So - page/per_page is being removed from the Keystone V3 API, in favor of marker/limit 17:04:12 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 so Designate will confirm - right? 17:04:33 *conform* 17:04:45 I've no real preference for anything other than conforming to the standards that the other projects set.. 17:05:00 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 same 17:05:17 Does anyone have a good reason why we shouldn't conform? 17:05:42 Semantically both are the same 17:05:44 I don't think any of us are UI guys 17:05:45 yes? 17:05:55 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 so conforming to the parameter name is fine with me 17:06:03 mugsie does lots of UI work :) 17:06:10 for the next week ;) 17:06:17 eankutse: well, it's much more than the param name 17:06:30 so page=1&per_page=10 17:06:31 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 vs marker=&limit=10 17:07:03 I would lean more towards making the UI easier rather than conforming for no reason 17:07:03 and to go backwards, marker=&limit=10&sort_dir=DESC 17:07:33 Would the marker in designate be a UUID that is randomly generated or that keeps increasing as time progresses? 17:07:44 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 ello folks 17:08:04 vinodmr: it would be the ID of the last domain/record/etc on the page your looking at 17:08:27 corporate* 17:08:41 UIs can store the previous markers, as pointed out in the thread 17:08:55 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 tsimmons: yea.. I know the feeling :) 17:09:45 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 ttsimmons: true 17:10:32 So - Does anyone think we should stick with page/per_page (or page/limit) ? 17:10:34 Has Horizon already done pagination with nova/glance/keystone etc? 17:10:42 conforming would also bode well for things like incubation 17:10:44 vinodmr: ehh - I don't think so to be honest 17:10:57 CaptTofu: yea.. good point. 17:11:11 I've never noticed pagination in horizon anyway... 17:11:32 So .. 17:11:36 Are all OpenStack projects going to change? 17:11:42 Does Keystone set the standard? 17:12:11 bluzader: I believe glance and nova already do it this way 17:12:26 Ah. Then it makes sense that we change 17:12:34 #startvote Should we conform to the limit/marker pagination pattern in the V2 API? yes, no, maybe 17:12:35 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 Vote using '#vote OPTION'. Only your last vote counts. 17:12:38 #vote yes 17:12:48 so - lets get a show of hands! 17:12:52 #vote yes 17:12:57 #vote yes 17:12:58 #vote yes 17:13:03 #vote yes 17:13:06 #vote yes 17:13:08 #vote yes 17:13:21 Any stragglers? simonmcc / CaptTofu ? 17:13:44 #vote yes 17:13:46 #vote yes 17:13:56 5 ... 4 ... 3... 17:13:58 #endvote 17:13:59 Voted on "Should we conform to the limit/marker pagination pattern in the V2 API?" Results are 17:14:00 yes (9): eankutse, simonmcc, bluzader, CaptTofu, tsimmons, vinodmr, mugsie, msisk_, kiall 17:14:12 So .. that's a yes. I'll update the spec. 17:14:40 I've got a quick question on v2API 17:14:58 Do the RecordSets replace Records, or are there Records and RecordSets 17:15:39 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 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 Make sense? 17:17:08 I'm not sure. It makes a big change from the way we're currently doing our DNS 17:17:36 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 I, obviously, need to read the spec more 17:17:59 eankutse: I agree 17:18:08 That part doesn't make sense to me at all 17:18:17 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 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 and if they don't.. 17:19:01 they the load balancing you are expecting will fail. 17:19:13 after 300 seconds, resolvers will discard the 300 one, and keep the 3600 one.. 17:19:31 for the next 3300 seconds, it's as if you only have 1 A record for "www.example.org." 17:19:59 hmm 17:20:20 As I said, I, obviously, need to spend more time in the spec to fully understand the pros and cons 17:20:33 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 Ah. I didn't realize that 17:21:16 Now RecordSets are making more sense to me 17:21:33 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 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 #link http://www.ietf.org/rfc/rfc2181.txt 17:22:32 vinodmr: that's right 17:22:40 vinodmr: correct, you would get back {"ttl": 300, "records": [, ], ...} 17:23:03 vinodmr: the only thing that varies in a recordset are the IP addresses 17:23:13 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 well - the rdata differs. SO for a A, that's just the IP address 17:23:43 for SRV, it's priority, port, weight, target 17:23:45 etc 17:24:07 kiall: right. I was thinking of only A records 17:24:15 and for MX priority+exchange differ :) 17:24:16 It's only the "data" that varies 17:24:56 Also - as another datapoint .. Amazon's Route53 went the RecordSet route from memory 17:25:08 (That's wasn't a deciding factor in any way!P 17:25:11 ..)* 17:25:41 kiall: Thx for explanation. It's making more sense to me now 17:25:57 So - Any lingering concerns over the use of RecordSet's? 17:26:15 kiall: Not from me at this point. 17:26:23 Is there any way to know the acutal TTL values that are configured using the API? 17:27:05 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 http://pastie.org/private/dke2mocexwilfwpqcmvivg <-- Route53's XML representation of a RecordSet 17:28:19 Conceptually, that's very similar to what we propose for the V2 API 17:28:49 Okay .. Next up :) 17:29:05 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 Then, over the next week or two finalize any core changes needed to make the conventions work. 17:30:40 #action Kiall to update spec for limit/marker/sort_dir/sort_key 17:30:42 (Forgot to add ^ earlier) 17:31:34 Anybody have any more comments/suggestions/issues with the conventions used in the APIv2 spec? :) 17:31:49 I have no issues at this stage 17:32:08 none 17:32:30 Okay .. I'll take that as a no from everyone! :) 17:32:31 #topic Any other business? Ask away. 17:32:41 I'll read up on the updates of the doc again 17:32:57 So - Anything else from anyone at all? Doesn't have to be APIv2 related :) 17:32:59 How's progress on State Machine 17:33:30 State Machine? 17:33:59 simonmcc: the domain/record "status" field.. e.g PENDING, ACTIVE etc 17:34:01 eankutse: I've not began writing any code - Before that gets added, backends need to become async capable. 17:34:05 yes. Kiall was coming up with one for zones the other day 17:34:22 Otherwise, the status are always just "ACTIVE" and there are no transitions really :) 17:34:43 k 17:35:24 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 k 17:35:51 if complete = True, we'll do what we do today, and return a synchronous status code with status=ACTIVE 17:36:02 kiall: that sounds cool. Have you written a blueprint for it? 17:36:25 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 bluzader: semi :) https://blueprints.launchpad.net/designate/+spec/domain-status 17:36:51 it's expanded from there though 17:37:05 eankutse: do you have the link to the state machine graphic I sent you? 17:38:14 I can find it 17:39:16 #link https://dl.dropboxusercontent.com/u/1400487/graphviz-fd80799c9423325e8616080d6ae7d1af8a96b5f6.png 17:39:32 #link https://dl.dropboxusercontent.com/u/1400487/graphviz-9c55129fd4d85273bcd3c6dc6fdae2471124e420.png 17:39:37 one for domains, one for recordsets 17:39:47 Thx 17:39:53 No problem :) 17:40:23 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 yes 17:41:04 Okay - Any more questions/comments before we call it a day? 17:41:19 not me 17:41:34 none from me either 17:41:43 nope 17:41:47 any progress on a designate face to face before HK? 17:41:53 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 simonmcc: I think there was budget issues on the HP side .. 17:42:32 :-) 17:42:48 HK has pushed the travel budget pretty far this year :( 17:43:21 @simonmcc I need to re-ask 17:43:21 all the more reason we should all go to HK ;) 17:43:41 I don't think RAX are planning on going to HK? 17:43:45 Okay - Thanks everyone :) Speak in #openstack-dns later! 17:43:48 @simonmcc I think management was thinking of possibly some place a bit inbetween Ireland and TX 17:43:49 #endmeeting