17:00:57 #startmeeting designate 17:00:58 Meeting started Wed Jul 24 17:00:57 2013 UTC. The chair is kiall. Information about MeetBot at http://wiki.debian.org/MeetBot. 17:00:59 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 17:01:02 The meeting name has been set to 'designate' 17:01:44 Nobody? ;) 17:01:50 I'm here 17:01:53 I am here for the DNS meet 17:01:58 As am I 17:02:04 b 17:02:04 Cool :) Wanted to make sure you guys were around :) 17:02:22 Is there a # tag for recording attendees 17:02:35 Nope .. Just say something and it's logged :) 17:02:38 here 17:02:45 #link https://wiki.openstack.org/wiki/Meetings/DNSaaS 17:02:47 Howdy from Austin 17:02:49 Here. ;) 17:02:49 Ageana ^ 17:02:54 Agenda* 17:03:06 I'm here 17:03:15 Okay .. Let's get started :) 17:03:19 #topic Intro of some of the RackSpace folks getting involved 17:03:35 jmcbride suggested this topic :) So I'll let you guys take over! 17:03:44 Hi Zane here QE on Dnsaas 17:03:44 cool 17:03:52 Emmanuel (eankutse) 17:04:16 so, as you know, some of our team had a chance for a phone meeting with the HP'ers about 2 weeks ago. 17:04:23 glad to have Rackspace onboard! 17:04:50 In that meeting, we briefly introduced part of our team. Since then, you have probably seen a few other handles. 17:05:28 Yup - We've noticed a few RS folks hanging around :) 17:05:38 so, without further ado... 17:06:24 eankutse, tsimmons, betsy, vinodmr are developers 17:06:37 msisk is dev ops 17:06:50 zane is test automation 17:07:04 I am Dev manager 17:07:45 And Nicole (who is on vacation at the moment in rainy arizona) is Product Manager. 17:08:28 We are all ramping up at the moment, while also juggling managing our current Rackspace DNS solution. 17:09:09 Excellent :) May as well re-introduce our team while we're at at.. CaptTofu (Patrick Galbraith) is Team Lead, simonmcc (Simon McCartney) is a developer, I'm a developer, and mugsie is joining our team next month as a developer 17:09:26 jdbarry (he's AFK at the moment) is Josh Barry, our product manager 17:09:27 So although we are bringing a lot of team members to the party, not everyone is 100% involved. 17:10:11 Yea - That's totally understandable.. the existing service doesn't run itself! 17:10:11 Awesome. So that covers Rackspace and HP. Are there any other frequent operators/developers we should mention? 17:11:03 future feather. 17:11:11 feature :) 17:11:13 Not really, we've got the likes of Ryan_Lane in wikimedia who's always bugging us about incubation etc.. :) 17:11:27 Okay! Any more intros before I move on? 17:11:58 I guess not :) 17:12:04 #topic API v2.0 Discussion/Feedback 17:12:06 #link https://wiki.openstack.org/wiki/Designate/APIv2 17:12:56 So, we've been drafting a version two API spec, and before we call anything final - I wanted to get your opinions on the current draft 17:13:22 I believe it was betsy who gave me some initial feedback 17:13:36 kiall: can you send the link to the draft for reference? 17:13:53 jmcbride: Yup - It's about 5 lines up :) 17:13:56 https://wiki.openstack.org/wiki/Designate/APIv2 17:14:18 eankutse(Emmanuel) gave some feedback in irc as well 17:14:28 Some of the create requests - for .e.g Create RecordSet returns a Location in the response but not all of them do. Would it be good for all the create/update requests to return a location in the response 17:15:20 vinodmr: absolutly.. The are some inconsistencies in the draft, and in general it needs more TLC before we expand it to cover other resources 17:15:38 All "create" calls should be returning a Location header. 17:16:06 I'll make sure that get's cleaned up tonight/tomorrow 17:16:33 #action kiall Ensure draft API spec is consistent in it's use of Headers and status codes 17:16:50 One of the other pieces of feedback I got from you guys was around batch operations 17:16:58 Kiall if you remember we had talked about the get recordset call 17:17:33 I've been struggling to understand what these batch calls should look like, anything I've mocked up "felt awful" 17:17:40 Sorry List record set 17:17:47 Do you guys have any opinions on what these should look like? 17:18:13 zane: Yes - that's another one to remove from the List RecordSet's response 17:18:35 #action kiall to remove "records" array from List RecordSets API response 17:18:55 just list the ids of recordsets and then we can call indvidual records set 17:19:13 just ID's? 17:19:32 it might be usefull to have partial metadata 17:19:55 like name, and type 17:20:03 We were thinking of removing just the "records" array from the List RecordSet response, leaving all the other fields like name/type/etc 17:20:12 is there a performance concern of providing more metadata? 17:20:16 (This is related to this API call BTW https://wiki.openstack.org/wiki/Designate/APIv2#List_RecordSets ) 17:21:28 name/type/id sounds good 17:21:37 I can see the "records" array as being a large enough performance hit to be worth removing it from that call, but I can't see any of the other fields providing a hit 17:22:01 agreed 17:22:11 the records get pulled from another table (potentially table(s)), so getting all that data together would be quite expensive 17:22:14 and we do have gett records call in v1 17:22:15 #agreed on name/type/id and performance 17:22:21 #agreed 17:22:23 It would be good to have consistency between List Zones (https://wiki.openstack.org/wiki/Designate/APIv2#List_Zones) and Records although the zones returned could vary a lot from the number of records returned 17:22:49 vinodmr: is this to do with pagination etc? 17:22:50 #agreed 17:22:59 Yes - pagination etc 17:23:40 I like the pagination on List Zones 17:23:57 Yea, pagination and filtering would exist on all "list" API calls, So far it's only be "mocked" on 1 API call to decide if that pattern is suitable 17:24:26 Since list zones accepts filtering, it would be good if list records also accepts filtering 17:25:00 Yea - I actually think List RRsets requires it even more than List Zones does! 17:25:14 Previously, I was thinking that using the RFC defined "Link" headers, rather than adding the links into the JSON response 17:25:45 But - I'm now thinking that, "Average End User" will never see or notice them, and not understand why they are not getting all data 17:26:06 #link https://github.com/openstack/identity-api/blob/master/openstack-identity-api/v3/src/markdown/identity-api-v3.md 17:26:12 That's the Keystone V3 API spec ^ 17:26:31 You should see lots of similarities between Designate V2, and Keystone V3 17:26:46 https://github.com/openstack/identity-api/blob/master/openstack-identity-api/v3/src/markdown/identity-api-v3.md#list-entities 17:27:04 That section shows where they place "links" which includes pagination 17:27:34 i like the idea of a "links" section 17:27:50 the "self" attrib can be very usefull 17:27:52 Personally, I'm thinking we "just go with that" and stay as consistent as possible to Keystone V3/Glance V2 (the newest openstack APIs) 17:28:03 Thoughts? 17:28:35 keystone is a good reference 17:28:55 I agree - following the Keystone & Glance links for pagination model works for me 17:29:04 Is the keystone API final or are there changes still being proposed/discussed? 17:29:59 vinodmr: it's final, and a released part of Grizzly as far as I remember! 17:30:17 #link https://github.com/openstack/image-api/blob/master/openstack-image-service-api/src/markdown/image-api-v2.0.md 17:30:20 Glance V2 API ^ 17:31:15 Glance V2 and Keystone V3 have lots of little inconsistencies with each other, I think out draft take the best parts of each, while staying closer to Keystone V3 17:31:21 s/out/our/ 17:32:28 #agreed on pagination links in json response 17:32:29 links in response is what I am used to seeing 17:32:33 Having that in a header would be confusing for folks. Having a simple links section in the JSON seems better. Might as well stay consistent with Keystone. 17:32:55 #agreed we should stay consistent with Keystone 17:33:11 Anyway - I had planned to do updates to the API spec earlier this week, but other priorities bumped it. I'd like to get the draft in better shape this week, is there anyone on the RS team who is particularly interested in the API? I'd love to try and get things worked, then decide if the spec is final or not next week. 17:33:26 After that, port it from the wiki to the format that keystone/glance etc use 17:33:41 I am 17:34:00 kiall: we actually have some questions/concerns about handling async actions. 17:34:30 jmcbride: sure - what are you thinking? 17:35:13 #agreed on modeling/inspiration from keystone API 17:36:02 #link http://docs.rackspace.com/cdns/api/v1.0/cdns-devguide/content/overview.html 17:36:08 RackSpace DNS API ^ 17:36:53 As I understand it, a user gets a 202 when performing a Create/Update/Delete action, right? 17:37:28 ^in V2 17:37:37 mugsie pointed out some inconsistencies in the return codes for create/update/delete API calls yesterday 17:38:29 Based on that conversation, I've been eyeing up allowing the API to return either 201 Created or 202 Accepted (for create calls) 17:39:03 Where, 202 Accepted would be unused until we introduce a "status" field on records and domains 17:39:31 a new record would start with status=PENDING, and change to status=ACTIVE once it's been published to the DNS servers 17:40:04 The backend in use (powerdns driver, akamai driver etc etc) would be responsible for making the PENDING->ACTIVE change on the records 17:40:04 If you return a 201 created would that call be sync or async? 17:40:24 and you query status just using the regular record-get? 17:40:35 or provide a callback? 17:40:37 201 Created would be sync, and would indicate the new record should be visible on the DNS server immediately 17:40:41 So how does the user find the status of a long running 202 job? 17:41:19 eankutse, by querying the URL and inspecting the status field. 17:41:39 That would follow the pattern set by Nova etc for async actions, like booting a VM 17:41:55 A new VM starts in the "BUILDING" state, and progresses over time to the "ACTIVE" state 17:43:00 kiall: So I assume we provide a unique endpoint for the user to query for status? 17:43:40 Well, even with the async call, we already know the new resources ID, so I don't think a dedicated async-status endpoint is necessary 17:44:14 And, a dedicated async-status endpoint would be counter to what we see other OpenStack projects doing - Nova is the prime example for async calls 17:44:24 As an example, if if POST /v2/records 17:45:05 You will get a Location: /v2/records/{record-uuid} header, and a body that looks something like {"id": "..", "status": "PENDING"} in response 17:45:15 (with a 202 Accepted status) 17:45:43 From there, you can query /v2/records/{record-uuid} and check if status has changed to ACTIVE 17:46:08 that sounds logical 17:46:14 #agreed on returning status similar to Nova 17:46:22 On the other hand, some backends might not be aync. In which case, a 201 Created would be returned along with {"id": "..", "status": "ACTIVE"} 17:46:24 #agreed on returning status similar to Nova 17:46:43 leaves room ... 17:47:12 Agreed, seems like extra overhead to have an additional asyc call. Can we support providing a unique ID on each request? 17:47:14 The async parts are going to require some changes in how out backends are implemented, but I wan't to make sure the spec covers what we need 17:48:27 jmcbride: I'm not sure I follow? Let's say a record is updated twice in a row, one of those updates has to "win" (or the changes need to be "merged" e.g. ttl and rdata change can be merged) 17:48:40 The record has a unique ID, and a "status" field 17:49:01 once all pending changes are live, status will change to "ACTIVE" 17:50:12 Also, we do have a unique request ID already, which gets dropped into error response bodies, and the X-Dns-Request-Id response header 17:50:27 But - that's intended for debugging rather than end users 17:50:33 kiall: I think we are coming around. Basically, RAX DNS' current async approach works around some internal challenges… but the approach you specify probably better handles it. 17:51:22 time check - we have 10 more minutes 17:51:35 jmcbride: yea, Maybe eankutse and myself can go through some of the challenges you guys have over the next few days, that will help ensure we get something that works for everyone 17:51:42 when should be discuss openstack in Hong Kong? 17:51:44 #agreed 17:51:48 Okay! So .. 17:52:15 CaptTofu - I would like to discuss that next as well (skip the documentation topic) 17:52:20 #action kiall and eankutse to discuss API over the next few days 17:52:37 #topic Identify opportunities to maximize collaboration 17:52:40 Moving on quickly :) 17:52:56 kiall: ok 17:53:32 so, in proposing this item, I feel our project interim goals are a little different from other official and incubated projects. 17:53:32 jmcbride: so, are you guys going to make it to Hong Kong? 17:53:56 I have yet to submit a talk but was going to base it off our last talk 17:54:02 though you guys are now involved so... 17:54:21 it seems like designate would benefit more from an interim designate "summit". 17:54:36 jmcbride: that sounds like it could be fun :) What did you have in mind? 17:54:42 Prague? 17:54:49 :-) 17:54:49 I propose we come together before that 17:55:23 for targetted and focused sessions to advance designate towards official Openstack project status. 17:55:33 i like the sound of that 17:55:51 #agreed on focus on official Openstack project status 17:56:01 Yea, I think that's a great idea. (Travel budgets this year are going to be tight ;)) 17:56:15 Basically, we are still unsure about whether we should attend Hong Kong — because we thing a better return for our investment would be something before that with targets. 17:56:32 Hong Kong = $$$$$$$ 17:57:05 jmcbride did you have a location & month in mind? 17:57:08 Yea, I would assuming EU <-> US is about the same though :) 17:57:09 jmcbride: did you have a time/place in mind? 17:57:18 simonmcc: beat me to it! 17:57:20 Austin Tx (or something closer) = pennies :) 17:57:37 although I would LOVE to see Ireland! 17:57:42 heheh 17:57:43 mid-point for "us" would be new york, but if you can host in Austin, that might work too 17:57:44 well, 17:57:58 we are thinking internally as a team to go to Ireland mid Sept. possiby 17:58:05 possibly, even 17:58:05 You can stay at my house, its right near the river (do you like canoing?) 17:58:20 Austin has a good Whole Foods 17:58:26 #agree on Party at Joe's house 17:58:50 OK, why don't we have an action for CaptTofu and I to chat details for a slumber party 17:59:01 Hah - So, jmcbride let's sync up over the next few days before we agree anything ;) Would need to find out what we can do on our side etc 17:59:14 #action figure out this meeting thing 17:59:16 #action jmcbride and CaptTofu to sync up on party 17:59:27 nice. 17:59:42 #topic How do we identify more small tasks that developers and testers can work on 17:59:45 and how to involve other organizations 17:59:46 I think that topic can be closed for now. 17:59:47 1 min to go ;) 17:59:58 CaptTofu, good point! 18:00:06 So .. We've been a bit overloaded on our side over the last week or so 18:00:19 kiall: what we have been doing - I think is a good start 18:00:26 And, filing small bugs that we didn't need fixed yesterday has been hard :) 18:00:33 find a bug, find someone with the most expertise in that area 18:01:14 kiall: regarding small bugs, we are finding that we simple need to get it deployed and start using it before we can provide real feedback on defects. 18:01:34 We'll continue trying to get bugs filed rather than simply fixing non-critical things :) But I'm hoping you guys will get things up and running, then start noticing things we don't¬ 18:01:57 Hey guys, I think we need to head to another commitment, shall we call it a day? 18:02:06 Yea :) 18:02:07 Lets 18:02:14 thanks everybody 18:02:17 Thanks all - and we'll sync up again tomorrow/the day after 18:02:20 #endmeeting