17:00:57 <kiall> #startmeeting designate
17:00:58 <openstack> 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 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
17:01:02 <openstack> The meeting name has been set to 'designate'
17:01:44 <kiall> Nobody? ;)
17:01:50 <betsy> I'm here
17:01:53 <vinodmr> I am here for the DNS meet
17:01:58 <tsimmons> As am I
17:02:04 <simonmcc> b
17:02:04 <kiall> Cool :) Wanted to make sure you guys were around :)
17:02:22 <vinodmr> Is there a # tag for recording attendees
17:02:35 <kiall> Nope .. Just say something and it's logged :)
17:02:38 <gcheng> here
17:02:45 <kiall> #link https://wiki.openstack.org/wiki/Meetings/DNSaaS
17:02:47 <jmcbride> Howdy from Austin
17:02:49 <msisk> Here. ;)
17:02:49 <kiall> Ageana ^
17:02:54 <kiall> Agenda*
17:03:06 <CaptTofu> I'm here
17:03:15 <kiall> Okay .. Let's get started :)
17:03:19 <kiall> #topic Intro of some of the RackSpace folks getting involved
17:03:35 <kiall> jmcbride suggested this topic :) So I'll let you guys take over!
17:03:44 <zane> Hi Zane here QE on Dnsaas
17:03:44 <jmcbride> cool
17:03:52 <eankutse> Emmanuel (eankutse)
17:04:16 <jmcbride> 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 <CaptTofu> glad to have Rackspace onboard!
17:04:50 <jmcbride> In that meeting, we briefly introduced part of our team.  Since then, you have probably seen a few other handles.
17:05:28 <kiall> Yup - We've noticed a few RS folks hanging around :)
17:05:38 <jmcbride> so, without further ado...
17:06:24 <jmcbride> eankutse, tsimmons, betsy, vinodmr are developers
17:06:37 <jmcbride> msisk is dev ops
17:06:50 <jmcbride> zane is test automation
17:07:04 <jmcbride> I am Dev manager
17:07:45 <jmcbride> And Nicole (who is on vacation at the moment in rainy arizona) is Product Manager.
17:08:28 <jmcbride> We are all ramping up at the moment, while also juggling managing our current Rackspace DNS solution.
17:09:09 <kiall> 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 <kiall> jdbarry (he's AFK at the moment) is Josh Barry, our product manager
17:09:27 <jmcbride> So although we are bringing a lot of team members to the party, not everyone is 100% involved.
17:10:11 <kiall> Yea - That's totally understandable.. the existing service doesn't run itself!
17:10:11 <jmcbride> Awesome.  So that covers Rackspace and HP.  Are there any other frequent operators/developers we should mention?
17:11:03 <CaptTofu> future feather.
17:11:11 <CaptTofu> feature :)
17:11:13 <kiall> Not really, we've got the likes of Ryan_Lane in wikimedia who's always bugging us about incubation etc.. :)
17:11:27 <kiall> Okay! Any more intros before I move on?
17:11:58 <kiall> I guess not :)
17:12:04 <kiall> #topic API v2.0 Discussion/Feedback
17:12:06 <kiall> #link  https://wiki.openstack.org/wiki/Designate/APIv2
17:12:56 <kiall> 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 <kiall> I believe it was betsy who gave me some initial feedback
17:13:36 <jmcbride> kiall: can you send the link to the draft for reference?
17:13:53 <kiall> jmcbride: Yup - It's about 5 lines up :)
17:13:56 <kiall> https://wiki.openstack.org/wiki/Designate/APIv2
17:14:18 <eankutse> eankutse(Emmanuel) gave some feedback in irc as well
17:14:28 <vinodmr> 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 <kiall> 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 <kiall> All "create" calls should be returning a Location header.
17:16:06 <kiall> I'll make sure that get's cleaned up tonight/tomorrow
17:16:33 <kiall> #action kiall Ensure draft API spec is consistent in it's use of Headers and status codes
17:16:50 <kiall> One of the other pieces of feedback I got from you guys was around batch operations
17:16:58 <zane> Kiall if you remember we had talked about the get recordset call
17:17:33 <kiall> I've been struggling to understand what these batch calls should look like, anything I've mocked up "felt awful"
17:17:40 <zane> Sorry List record set
17:17:47 <kiall> Do you guys have any opinions on what these should look like?
17:18:13 <kiall> zane: Yes - that's another one to remove from the List RecordSet's response
17:18:35 <kiall> #action kiall to remove "records" array from List RecordSets API response
17:18:55 <zane> just list the ids of recordsets and then we can call indvidual records set
17:19:13 <mugsie> just ID's?
17:19:32 <mugsie> it might be usefull to have partial metadata
17:19:55 <mugsie> like name, and type
17:20:03 <kiall> 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 <jmcbride> is there a performance concern of providing more metadata?
17:20:16 <kiall> (This is related to this API call BTW https://wiki.openstack.org/wiki/Designate/APIv2#List_RecordSets )
17:21:28 <eankutse> name/type/id sounds good
17:21:37 <kiall> 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 <zane> agreed
17:22:11 <kiall> the records get pulled from another table (potentially table(s)), so getting all that data together would be quite expensive
17:22:14 <zane> and we do have gett records call in v1
17:22:15 <jmcbride> #agreed on name/type/id and performance
17:22:21 <betsy> #agreed
17:22:23 <vinodmr> 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 <kiall> vinodmr: is this to do with pagination etc?
17:22:50 <CaptTofu> #agreed
17:22:59 <vinodmr> Yes - pagination etc
17:23:40 <betsy> I like the pagination on List Zones
17:23:57 <kiall> 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 <vinodmr> Since list zones accepts filtering, it would be good if list records also accepts filtering
17:25:00 <kiall> Yea - I actually think List RRsets requires it even more than List Zones does!
17:25:14 <kiall> Previously, I was thinking that using the RFC defined "Link" headers, rather than adding the links into the JSON response
17:25:45 <kiall> 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 <kiall> #link https://github.com/openstack/identity-api/blob/master/openstack-identity-api/v3/src/markdown/identity-api-v3.md
17:26:12 <kiall> That's the Keystone V3 API spec ^
17:26:31 <kiall> You should see lots of similarities between Designate V2, and Keystone V3
17:26:46 <kiall> https://github.com/openstack/identity-api/blob/master/openstack-identity-api/v3/src/markdown/identity-api-v3.md#list-entities
17:27:04 <kiall> That section shows where they place "links" which includes pagination
17:27:34 <mugsie> i like the idea of a "links" section
17:27:50 <mugsie> the "self" attrib can be very usefull
17:27:52 <kiall> 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 <kiall> Thoughts?
17:28:35 <CaptTofu> keystone is a good reference
17:28:55 <simonmcc> I agree - following the Keystone & Glance links for pagination model works for me
17:29:04 <vinodmr> Is the keystone API final or are there changes still being proposed/discussed?
17:29:59 <kiall> vinodmr: it's final, and a released part of Grizzly as far as I remember!
17:30:17 <kiall> #link https://github.com/openstack/image-api/blob/master/openstack-image-service-api/src/markdown/image-api-v2.0.md
17:30:20 <kiall> Glance V2 API ^
17:31:15 <kiall> 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 <kiall> s/out/our/
17:32:28 <jmcbride> #agreed on pagination links in json response
17:32:29 <eankutse> links in response is what I am used to seeing
17:32:33 <tsimmons> 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 <betsy> #agreed we should stay consistent with Keystone
17:33:11 <kiall> 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 <kiall> After that, port it from the wiki to the format that keystone/glance etc use
17:33:41 <eankutse> I am
17:34:00 <jmcbride> kiall: we actually have some questions/concerns about handling async actions.
17:34:30 <kiall> jmcbride: sure - what are you thinking?
17:35:13 <CaptTofu> #agreed on modeling/inspiration from keystone API
17:36:02 <kiall> #link http://docs.rackspace.com/cdns/api/v1.0/cdns-devguide/content/overview.html
17:36:08 <kiall> RackSpace DNS API ^
17:36:53 <jmcbride> As I understand it, a user gets a 202 when performing a Create/Update/Delete action, right?
17:37:28 <tsimmons> ^in V2
17:37:37 <kiall> mugsie pointed out some inconsistencies in the return codes for create/update/delete API calls yesterday
17:38:29 <kiall> 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 <kiall> Where, 202 Accepted would be unused until we introduce a "status" field on records and domains
17:39:31 <kiall> 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 <kiall> 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 <vinodmr> If you return a 201 created would that call be sync or async?
17:40:24 <simonmcc> and you query status just using the regular record-get?
17:40:35 <betsy> or provide a callback?
17:40:37 <kiall> 201 Created would be sync, and would indicate the new record should be visible on the DNS server immediately
17:40:41 <eankutse> So how does the user find the status of a long running 202 job?
17:41:19 <kiall> eankutse, by querying the URL and inspecting the status field.
17:41:39 <kiall> That would follow the pattern set by Nova etc for async actions, like booting a VM
17:41:55 <kiall> A new VM starts in the "BUILDING" state, and progresses over time to the "ACTIVE" state
17:43:00 <jmcbride> kiall: So I assume we provide a unique endpoint for the user to query for status?
17:43:40 <kiall> 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 <kiall> 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 <kiall> As an example, if if POST /v2/records
17:45:05 <kiall> 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 <kiall> (with a 202 Accepted status)
17:45:43 <kiall> From there, you can query /v2/records/{record-uuid} and check if status has changed to ACTIVE
17:46:08 <CaptTofu> that sounds logical
17:46:14 <vinodmr> #agreed on returning status similar to Nova
17:46:22 <kiall> 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 <CaptTofu> #agreed on returning status similar to Nova
17:46:43 <CaptTofu> leaves room ...
17:47:12 <jmcbride> Agreed, seems like extra overhead to have an additional asyc call.  Can we support providing a unique ID on each request?
17:47:14 <kiall> 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 <kiall> 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 <kiall> The record has a unique ID, and a "status" field
17:49:01 <kiall> once all pending changes are live, status will change to "ACTIVE"
17:50:12 <kiall> 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 <kiall> But - that's intended for debugging rather than end users
17:50:33 <jmcbride> 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 <jmcbride> time check - we have 10 more minutes
17:51:35 <kiall> 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 <CaptTofu> when should be discuss openstack in Hong Kong?
17:51:44 <jmcbride> #agreed
17:51:48 <kiall> Okay! So ..
17:52:15 <jmcbride> CaptTofu - I would like to discuss that next as well (skip the documentation topic)
17:52:20 <kiall> #action kiall and eankutse to discuss API over the next few days
17:52:37 <kiall> #topic Identify opportunities to maximize collaboration
17:52:40 <kiall> Moving on quickly :)
17:52:56 <eankutse> kiall: ok
17:53:32 <jmcbride> so, in proposing this item, I feel our project interim goals are a little different from other official and incubated projects.
17:53:32 <kiall> jmcbride: so, are you guys going to make it to Hong Kong?
17:53:56 <CaptTofu> I have yet to submit a talk but was going to base it off our last talk
17:54:02 <CaptTofu> though you guys are now involved so...
17:54:21 <jmcbride> it seems like designate would benefit more from an interim designate "summit".
17:54:36 <kiall> jmcbride: that sounds like it could be fun :) What did you have in mind?
17:54:42 <CaptTofu> Prague?
17:54:49 <eankutse> :-)
17:54:49 <jmcbride> I propose we come together before that
17:55:23 <jmcbride> for targetted and focused sessions to advance designate towards official Openstack project status.
17:55:33 <simonmcc> i like the sound of that
17:55:51 <CaptTofu> #agreed on focus on official Openstack project status
17:56:01 <kiall> Yea, I think that's a great idea. (Travel budgets this year are going to be tight ;))
17:56:15 <jmcbride> 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 <jmcbride> Hong Kong = $$$$$$$
17:57:05 <simonmcc> jmcbride did you have a location & month in mind?
17:57:08 <kiall> Yea, I would assuming EU <-> US is about the same though :)
17:57:09 <kiall> jmcbride: did you have a time/place in mind?
17:57:18 <kiall> simonmcc: beat me to it!
17:57:20 <jmcbride> Austin Tx (or something closer) = pennies :)
17:57:37 <jmcbride> although I would LOVE to see Ireland!
17:57:42 <CaptTofu> heheh
17:57:43 <simonmcc> mid-point for "us" would be new york, but if you can host in Austin, that might work too
17:57:44 <CaptTofu> well,
17:57:58 <CaptTofu> we are thinking internally as a team to go to Ireland mid Sept. possiby
17:58:05 <CaptTofu> possibly, even
17:58:05 <jmcbride> You can stay at my house, its right near the river (do you like canoing?)
17:58:20 <CaptTofu> Austin has a good Whole Foods
17:58:26 <tsimmons> #agree on Party at Joe's house
17:58:50 <jmcbride> OK, why don't we have an action for CaptTofu and I to chat details for a slumber party
17:59:01 <kiall> 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 <CaptTofu> #action figure out this meeting thing
17:59:16 <kiall> #action jmcbride and CaptTofu to sync up on party
17:59:27 <jmcbride> nice.
17:59:42 <kiall> #topic How do we identify more small tasks that developers and testers can work on
17:59:45 <CaptTofu> and how to involve other organizations
17:59:46 <jmcbride> I think that topic can be closed for now.
17:59:47 <kiall> 1 min to go ;)
17:59:58 <jmcbride> CaptTofu, good point!
18:00:06 <kiall> So .. We've been a bit overloaded on our side over the last week or so
18:00:19 <CaptTofu> kiall: what we have been doing - I think is a good start
18:00:26 <kiall> And, filing small bugs that we didn't need fixed yesterday has been hard :)
18:00:33 <CaptTofu> find a bug, find someone with the most expertise in that area
18:01:14 <jmcbride> 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 <kiall> 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 <jmcbride> Hey guys, I think we need to head to another commitment, shall we call it a day?
18:02:06 <kiall> Yea :)
18:02:07 <kiall> Lets
18:02:14 <simonmcc> thanks everybody
18:02:17 <kiall> Thanks all - and we'll sync up again tomorrow/the day after
18:02:20 <kiall> #endmeeting