| *** gokrokve has quit IRC | 00:05 | |
| *** sballe has quit IRC | 00:15 | |
| *** nkonoval_ has joined #openstack-meeting-alt | 00:35 | |
| *** nkonoval_ has quit IRC | 00:40 | |
| *** HenryG has joined #openstack-meeting-alt | 00:44 | |
| *** jcru has quit IRC | 01:16 | |
| *** markwash has joined #openstack-meeting-alt | 01:18 | |
| *** markwash has quit IRC | 01:33 | |
| *** nkonoval_ has joined #openstack-meeting-alt | 01:36 | |
| *** rnirmal has quit IRC | 01:38 | |
| *** nkonoval_ has quit IRC | 01:40 | |
| *** qwerty_nor has quit IRC | 01:42 | |
| *** tanisdl has quit IRC | 01:42 | |
| *** rnirmal has joined #openstack-meeting-alt | 01:45 | |
| *** demorris has joined #openstack-meeting-alt | 01:59 | |
| *** venkatesh has joined #openstack-meeting-alt | 02:09 | |
| *** venkatesh has quit IRC | 02:16 | |
| *** akuznetsov has joined #openstack-meeting-alt | 02:17 | |
| *** nkonoval_ has joined #openstack-meeting-alt | 02:37 | |
| *** vkmc has quit IRC | 02:40 | |
| *** nkonoval_ has quit IRC | 02:41 | |
| *** jcru has joined #openstack-meeting-alt | 03:09 | |
| *** jcru is now known as jcru|away | 03:09 | |
| *** jrodom has quit IRC | 03:22 | |
| *** nkonoval_ has joined #openstack-meeting-alt | 03:37 | |
| *** akuznetsov has quit IRC | 03:39 | |
| *** nkonoval_ has quit IRC | 03:42 | |
| *** jcru|away is now known as jcru | 03:43 | |
| *** demorris has quit IRC | 03:45 | |
| *** jrodom has joined #openstack-meeting-alt | 03:49 | |
| *** jrodom has quit IRC | 03:50 | |
| *** jrodom has joined #openstack-meeting-alt | 03:50 | |
| *** vipul is now known as vipul-away | 03:55 | |
| *** mestery has joined #openstack-meeting-alt | 04:00 | |
| *** SergeyLukjanov has joined #openstack-meeting-alt | 04:03 | |
| *** akuznetsov has joined #openstack-meeting-alt | 04:04 | |
| *** vipul-away is now known as vipul | 04:13 | |
| *** akuznetsov has quit IRC | 04:15 | |
| *** akuznetsov has joined #openstack-meeting-alt | 04:31 | |
| *** westmaas_ has joined #openstack-meeting-alt | 04:33 | |
| *** westmaas has quit IRC | 04:34 | |
| *** westmaas_ is now known as wesstmaas | 04:34 | |
| *** wesstmaas is now known as westmaas | 04:35 | |
| *** nkonoval_ has joined #openstack-meeting-alt | 04:38 | |
| *** nkonoval_ has quit IRC | 04:43 | |
| *** abaron_ has quit IRC | 04:52 | |
| *** vipul is now known as vipul-away | 05:04 | |
| *** nkonoval_ has joined #openstack-meeting-alt | 05:04 | |
| *** colinmcnamara has joined #openstack-meeting-alt | 05:05 | |
| *** colinmcnamara has quit IRC | 05:07 | |
| *** vipul-away is now known as vipul | 05:08 | |
| *** lastidiot has quit IRC | 05:09 | |
| *** nkonoval_ has quit IRC | 05:19 | |
| *** akuznetsov has quit IRC | 05:20 | |
| *** nkonoval_ has joined #openstack-meeting-alt | 05:26 | |
| *** SergeyLukjanov has quit IRC | 05:36 | |
| *** jcru has quit IRC | 05:39 | |
| *** bdpayne has quit IRC | 05:40 | |
| *** akuznetsov has joined #openstack-meeting-alt | 05:55 | |
| *** abaron_ has joined #openstack-meeting-alt | 05:59 | |
| *** jrodom has quit IRC | 06:04 | |
| *** akuznetsov has quit IRC | 06:04 | |
| *** esp has joined #openstack-meeting-alt | 06:07 | |
| *** abaron_ has quit IRC | 06:19 | |
| *** nkonoval_ has joined #openstack-meeting-alt | 06:20 | |
| *** abaron_ has joined #openstack-meeting-alt | 06:42 | |
| *** esp has left #openstack-meeting-alt | 06:42 | |
| *** plomakin has joined #openstack-meeting-alt | 07:04 | |
| *** SergeyLukjanov has joined #openstack-meeting-alt | 07:06 | |
| *** abaron_ has quit IRC | 07:08 | |
| *** jrodom has joined #openstack-meeting-alt | 07:30 | |
| *** nkonoval_ has quit IRC | 07:35 | |
| *** nkonoval_ has joined #openstack-meeting-alt | 07:35 | |
| *** jrodom has quit IRC | 07:43 | |
| *** jrodom has joined #openstack-meeting-alt | 07:44 | |
| *** abaron_ has joined #openstack-meeting-alt | 08:09 | |
| *** abaron_ has quit IRC | 08:19 | |
| *** nkonoval_ has quit IRC | 08:20 | |
| *** abaron_ has joined #openstack-meeting-alt | 08:21 | |
| *** nkonoval_ has joined #openstack-meeting-alt | 08:23 | |
| *** nkonoval_ has joined #openstack-meeting-alt | 08:24 | |
| *** dhellmann_ has joined #openstack-meeting-alt | 08:27 | |
| *** jeblair_ has joined #openstack-meeting-alt | 08:28 | |
| *** pleia2_ has joined #openstack-meeting-alt | 08:29 | |
| *** dhellmann has quit IRC | 08:29 | |
| *** pleia2 has quit IRC | 08:29 | |
| *** jeblair has quit IRC | 08:29 | |
| *** dhellmann_ is now known as dhellmann | 08:30 | |
| *** SergeyLukjanov has quit IRC | 08:49 | |
| *** SergeyLukjanov has joined #openstack-meeting-alt | 08:55 | |
| *** abaron_ has quit IRC | 09:06 | |
| *** nkonoval_ has quit IRC | 09:23 | |
| *** abaron has joined #openstack-meeting-alt | 09:26 | |
| *** abaron has quit IRC | 09:39 | |
| *** abaron has joined #openstack-meeting-alt | 09:52 | |
| *** jrodom has quit IRC | 10:05 | |
| *** pcm_ has joined #openstack-meeting-alt | 10:09 | |
| *** pcm_ has joined #openstack-meeting-alt | 10:09 | |
| *** nkonoval_ has joined #openstack-meeting-alt | 10:11 | |
| *** demorris has joined #openstack-meeting-alt | 10:13 | |
| *** nkonoval_ has quit IRC | 10:21 | |
| *** nkonoval_ has joined #openstack-meeting-alt | 10:22 | |
| *** demorris has quit IRC | 11:02 | |
| *** akuznetsov has joined #openstack-meeting-alt | 11:08 | |
| *** nkonova__ has joined #openstack-meeting-alt | 11:48 | |
| *** nkonoval_ has quit IRC | 11:48 | |
| *** nkonova__ has quit IRC | 12:14 | |
| *** vkmc has joined #openstack-meeting-alt | 12:19 | |
| *** vkmc has joined #openstack-meeting-alt | 12:19 | |
| *** pdmars has joined #openstack-meeting-alt | 12:39 | |
| *** nkonoval_ has joined #openstack-meeting-alt | 12:48 | |
| *** demorris has joined #openstack-meeting-alt | 13:06 | |
| *** pdmars has quit IRC | 13:17 | |
| *** pdmars has joined #openstack-meeting-alt | 13:23 | |
| *** nkonoval_ has quit IRC | 13:35 | |
| *** djohnstone has joined #openstack-meeting-alt | 13:54 | |
| *** jrodom has joined #openstack-meeting-alt | 13:55 | |
| *** jrodom has quit IRC | 13:55 | |
| *** jrodom has joined #openstack-meeting-alt | 13:56 | |
| *** cp16net is now known as cp16net|away | 13:56 | |
| *** cp16net|away is now known as cp16net | 13:56 | |
| *** lifeless has quit IRC | 13:57 | |
| *** nkonoval_ has joined #openstack-meeting-alt | 13:59 | |
| *** Riddhi has joined #openstack-meeting-alt | 14:04 | |
| *** lifeless has joined #openstack-meeting-alt | 14:04 | |
| *** kevinconway has quit IRC | 14:06 | |
| *** kevinconway has joined #openstack-meeting-alt | 14:07 | |
| *** kevinconway has left #openstack-meeting-alt | 14:08 | |
| *** kevinconway has joined #openstack-meeting-alt | 14:08 | |
| *** kevinconway has quit IRC | 14:08 | |
| *** megan_w has joined #openstack-meeting-alt | 14:08 | |
| *** kevinconway has joined #openstack-meeting-alt | 14:10 | |
| *** rnirmal has joined #openstack-meeting-alt | 14:11 | |
| *** lastidiot has joined #openstack-meeting-alt | 14:15 | |
| *** markmcclain has joined #openstack-meeting-alt | 14:15 | |
| *** lastidiot has quit IRC | 14:28 | |
| *** sballe has joined #openstack-meeting-alt | 14:39 | |
| *** ashestakov has joined #openstack-meeting-alt | 14:45 | |
| *** ashestakov has left #openstack-meeting-alt | 14:45 | |
| *** Serge has joined #openstack-meeting-alt | 14:46 | |
| *** ashestakov has joined #openstack-meeting-alt | 14:46 | |
| *** nkonoval_ has quit IRC | 14:53 | |
| *** tanisdl has joined #openstack-meeting-alt | 15:01 | |
| *** lastidiot has joined #openstack-meeting-alt | 15:03 | |
| *** jcru has joined #openstack-meeting-alt | 15:07 | |
| *** pleia2_ is now known as pleia2 | 15:09 | |
| *** tanisdl has quit IRC | 15:14 | |
| *** yidclare has joined #openstack-meeting-alt | 15:16 | |
| *** tanisdl has joined #openstack-meeting-alt | 15:17 | |
| *** nkonoval_ has joined #openstack-meeting-alt | 15:23 | |
| *** nkonoval_ has quit IRC | 15:31 | |
| *** colinmcnamara has joined #openstack-meeting-alt | 15:43 | |
| *** jergerber has joined #openstack-meeting-alt | 15:46 | |
| *** bdpayne has joined #openstack-meeting-alt | 15:48 | |
| *** nkonoval_ has joined #openstack-meeting-alt | 15:49 | |
| *** colinmcnamara has quit IRC | 15:57 | |
| *** colinmcnamara has joined #openstack-meeting-alt | 15:58 | |
| *** nkonova__ has joined #openstack-meeting-alt | 16:01 | |
| *** akuznetsov has quit IRC | 16:04 | |
| *** nkonoval_ has quit IRC | 16:05 | |
| *** vinodmr has joined #openstack-meeting-alt | 16:08 | |
| *** nkonova__ has quit IRC | 16:11 | |
| *** Riddhi_ has joined #openstack-meeting-alt | 16:11 | |
| *** Riddhi has quit IRC | 16:13 | |
| *** Riddhi_ is now known as Riddhi | 16:13 | |
| *** jcru is now known as jcru|away | 16:18 | |
| *** CaptTofu has joined #openstack-meeting-alt | 16:19 | |
| *** kiall has joined #openstack-meeting-alt | 16:20 | |
| *** jeblair_ is now known as jeblair | 16:22 | |
| *** tsimmons has joined #openstack-meeting-alt | 16:22 | |
| *** jcru|away is now known as jcru | 16:36 | |
| *** jergerber has quit IRC | 16:36 | |
| *** vinodmr has left #openstack-meeting-alt | 16:37 | |
| *** sarob has joined #openstack-meeting-alt | 16:38 | |
| *** gokrokve has joined #openstack-meeting-alt | 16:44 | |
| *** SergeyLukjanov has quit IRC | 16:45 | |
| *** esp has joined #openstack-meeting-alt | 16:46 | |
| *** akuznetsov has joined #openstack-meeting-alt | 16:47 | |
| *** sarob has quit IRC | 16:47 | |
| *** sarob has joined #openstack-meeting-alt | 16:47 | |
| *** kevinconway has quit IRC | 16:48 | |
| *** qwerty_nor has joined #openstack-meeting-alt | 16:49 | |
| *** kevinconway has joined #openstack-meeting-alt | 16:49 | |
| *** esp has quit IRC | 16:49 | |
| *** esp has joined #openstack-meeting-alt | 16:50 | |
| *** gokrokve has quit IRC | 16:50 | |
| *** esp has left #openstack-meeting-alt | 16:51 | |
| *** akuznetsov has quit IRC | 16:51 | |
| *** simonmcc has joined #openstack-meeting-alt | 16:53 | |
| *** gcheng has joined #openstack-meeting-alt | 16:53 | |
| *** tsimmons has quit IRC | 16:55 | |
| *** jmcbride has joined #openstack-meeting-alt | 16:58 | |
| *** tsimmons has joined #openstack-meeting-alt | 16:59 | |
| *** betsy has joined #openstack-meeting-alt | 17:00 | |
| *** vinodmr has joined #openstack-meeting-alt | 17:00 | |
| *** msisk has joined #openstack-meeting-alt | 17:00 | |
| kiall | Heya | 17:00 |
|---|---|---|
| kiall | Who's about for the DNS meet? | 17:00 |
| kiall | #startmeeting designate | 17:00 |
| 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 |
| openstack | Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. | 17:00 |
| *** openstack changes topic to " (Meeting topic: designate)" | 17:01 | |
| openstack | The meeting name has been set to 'designate' | 17:01 |
| *** eankutse has joined #openstack-meeting-alt | 17:01 | |
| kiall | Nobody? ;) | 17:01 |
| betsy | I'm here | 17:01 |
| vinodmr | I am here for the DNS meet | 17:01 |
| tsimmons | As am I | 17:01 |
| simonmcc | b | 17:02 |
| kiall | Cool :) Wanted to make sure you guys were around :) | 17:02 |
| *** zane has joined #openstack-meeting-alt | 17:02 | |
| vinodmr | Is there a # tag for recording attendees | 17:02 |
| kiall | Nope .. Just say something and it's logged :) | 17:02 |
| gcheng | here | 17:02 |
| kiall | #link https://wiki.openstack.org/wiki/Meetings/DNSaaS | 17:02 |
| jmcbride | Howdy from Austin | 17:02 |
| msisk | Here. ;) | 17:02 |
| kiall | Ageana ^ | 17:02 |
| kiall | Agenda* | 17:02 |
| CaptTofu | I'm here | 17:03 |
| kiall | Okay .. Let's get started :) | 17:03 |
| kiall | #topic Intro of some of the RackSpace folks getting involved | 17:03 |
| *** openstack changes topic to "Intro of some of the RackSpace folks getting involved (Meeting topic: designate)" | 17:03 | |
| kiall | jmcbride suggested this topic :) So I'll let you guys take over! | 17:03 |
| zane | Hi Zane here QE on Dnsaas | 17:03 |
| jmcbride | cool | 17:03 |
| eankutse | Emmanuel (eankutse) | 17:03 |
| 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 |
| CaptTofu | glad to have Rackspace onboard! | 17:04 |
| *** SergeyLukjanov has joined #openstack-meeting-alt | 17:04 | |
| *** mugsie has joined #openstack-meeting-alt | 17:04 | |
| jmcbride | In that meeting, we briefly introduced part of our team. Since then, you have probably seen a few other handles. | 17:04 |
| kiall | Yup - We've noticed a few RS folks hanging around :) | 17:05 |
| jmcbride | so, without further ado... | 17:05 |
| *** sarob has quit IRC | 17:06 | |
| jmcbride | eankutse, tsimmons, betsy, vinodmr are developers | 17:06 |
| *** sarob has joined #openstack-meeting-alt | 17:06 | |
| jmcbride | msisk is dev ops | 17:06 |
| *** eankutse has quit IRC | 17:06 | |
| jmcbride | zane is test automation | 17:06 |
| jmcbride | I am Dev manager | 17:07 |
| jmcbride | And Nicole (who is on vacation at the moment in rainy arizona) is Product Manager. | 17:07 |
| jmcbride | We are all ramping up at the moment, while also juggling managing our current Rackspace DNS solution. | 17:08 |
| 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 |
| kiall | jdbarry (he's AFK at the moment) is Josh Barry, our product manager | 17:09 |
| jmcbride | So although we are bringing a lot of team members to the party, not everyone is 100% involved. | 17:09 |
| kiall | Yea - That's totally understandable.. the existing service doesn't run itself! | 17:10 |
| jmcbride | Awesome. So that covers Rackspace and HP. Are there any other frequent operators/developers we should mention? | 17:10 |
| CaptTofu | future feather. | 17:11 |
| CaptTofu | feature :) | 17:11 |
| kiall | Not really, we've got the likes of Ryan_Lane in wikimedia who's always bugging us about incubation etc.. :) | 17:11 |
| kiall | Okay! Any more intros before I move on? | 17:11 |
| *** jcru is now known as jcru|away | 17:11 | |
| *** eankutse has joined #openstack-meeting-alt | 17:11 | |
| kiall | I guess not :) | 17:11 |
| kiall | #topic API v2.0 Discussion/Feedback | 17:12 |
| *** openstack changes topic to "API v2.0 Discussion/Feedback (Meeting topic: designate)" | 17:12 | |
| kiall | #link https://wiki.openstack.org/wiki/Designate/APIv2 | 17:12 |
| 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:12 |
| kiall | I believe it was betsy who gave me some initial feedback | 17:13 |
| jmcbride | kiall: can you send the link to the draft for reference? | 17:13 |
| kiall | jmcbride: Yup - It's about 5 lines up :) | 17:13 |
| kiall | https://wiki.openstack.org/wiki/Designate/APIv2 | 17:13 |
| eankutse | eankutse(Emmanuel) gave some feedback in irc as well | 17:14 |
| 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:14 |
| 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 |
| kiall | All "create" calls should be returning a Location header. | 17:15 |
| kiall | I'll make sure that get's cleaned up tonight/tomorrow | 17:16 |
| kiall | #action kiall Ensure draft API spec is consistent in it's use of Headers and status codes | 17:16 |
| kiall | One of the other pieces of feedback I got from you guys was around batch operations | 17:16 |
| zane | Kiall if you remember we had talked about the get recordset call | 17:16 |
| kiall | I've been struggling to understand what these batch calls should look like, anything I've mocked up "felt awful" | 17:17 |
| zane | Sorry List record set | 17:17 |
| kiall | Do you guys have any opinions on what these should look like? | 17:17 |
| kiall | zane: Yes - that's another one to remove from the List RecordSet's response | 17:18 |
| kiall | #action kiall to remove "records" array from List RecordSets API response | 17:18 |
| zane | just list the ids of recordsets and then we can call indvidual records set | 17:18 |
| mugsie | just ID's? | 17:19 |
| *** nkonoval_ has joined #openstack-meeting-alt | 17:19 | |
| mugsie | it might be usefull to have partial metadata | 17:19 |
| mugsie | like name, and type | 17:19 |
| 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 |
| jmcbride | is there a performance concern of providing more metadata? | 17:20 |
| kiall | (This is related to this API call BTW https://wiki.openstack.org/wiki/Designate/APIv2#List_RecordSets ) | 17:20 |
| *** nkonoval_ has left #openstack-meeting-alt | 17:20 | |
| eankutse | name/type/id sounds good | 17:21 |
| 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:21 |
| *** sarob has quit IRC | 17:21 | |
| zane | agreed | 17:22 |
| kiall | the records get pulled from another table (potentially table(s)), so getting all that data together would be quite expensive | 17:22 |
| zane | and we do have gett records call in v1 | 17:22 |
| jmcbride | #agreed on name/type/id and performance | 17:22 |
| *** sarob has joined #openstack-meeting-alt | 17:22 | |
| betsy | #agreed | 17:22 |
| 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 |
| kiall | vinodmr: is this to do with pagination etc? | 17:22 |
| CaptTofu | #agreed | 17:22 |
| vinodmr | Yes - pagination etc | 17:22 |
| betsy | I like the pagination on List Zones | 17:23 |
| 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:23 |
| vinodmr | Since list zones accepts filtering, it would be good if list records also accepts filtering | 17:24 |
| kiall | Yea - I actually think List RRsets requires it even more than List Zones does! | 17:25 |
| kiall | Previously, I was thinking that using the RFC defined "Link" headers, rather than adding the links into the JSON response | 17:25 |
| 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:25 |
| kiall | #link https://github.com/openstack/identity-api/blob/master/openstack-identity-api/v3/src/markdown/identity-api-v3.md | 17:26 |
| kiall | That's the Keystone V3 API spec ^ | 17:26 |
| kiall | You should see lots of similarities between Designate V2, and Keystone V3 | 17:26 |
| kiall | https://github.com/openstack/identity-api/blob/master/openstack-identity-api/v3/src/markdown/identity-api-v3.md#list-entities | 17:26 |
| kiall | That section shows where they place "links" which includes pagination | 17:27 |
| mugsie | i like the idea of a "links" section | 17:27 |
| mugsie | the "self" attrib can be very usefull | 17:27 |
| 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:27 |
| kiall | Thoughts? | 17:28 |
| *** sarob has quit IRC | 17:28 | |
| CaptTofu | keystone is a good reference | 17:28 |
| *** pdmars has quit IRC | 17:28 | |
| simonmcc | I agree - following the Keystone & Glance links for pagination model works for me | 17:28 |
| vinodmr | Is the keystone API final or are there changes still being proposed/discussed? | 17:29 |
| kiall | vinodmr: it's final, and a released part of Grizzly as far as I remember! | 17:29 |
| kiall | #link https://github.com/openstack/image-api/blob/master/openstack-image-service-api/src/markdown/image-api-v2.0.md | 17:30 |
| kiall | Glance V2 API ^ | 17:30 |
| 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 |
| kiall | s/out/our/ | 17:31 |
| jmcbride | #agreed on pagination links in json response | 17:32 |
| eankutse | links in response is what I am used to seeing | 17:32 |
| 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 |
| betsy | #agreed we should stay consistent with Keystone | 17:32 |
| 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 |
| kiall | After that, port it from the wiki to the format that keystone/glance etc use | 17:33 |
| eankutse | I am | 17:33 |
| jmcbride | kiall: we actually have some questions/concerns about handling async actions. | 17:34 |
| kiall | jmcbride: sure - what are you thinking? | 17:34 |
| CaptTofu | #agreed on modeling/inspiration from keystone API | 17:35 |
| kiall | #link http://docs.rackspace.com/cdns/api/v1.0/cdns-devguide/content/overview.html | 17:36 |
| kiall | RackSpace DNS API ^ | 17:36 |
| jmcbride | As I understand it, a user gets a 202 when performing a Create/Update/Delete action, right? | 17:36 |
| tsimmons | ^in V2 | 17:37 |
| kiall | mugsie pointed out some inconsistencies in the return codes for create/update/delete API calls yesterday | 17:37 |
| 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:38 |
| kiall | Where, 202 Accepted would be unused until we introduce a "status" field on records and domains | 17:39 |
| kiall | a new record would start with status=PENDING, and change to status=ACTIVE once it's been published to the DNS servers | 17:39 |
| 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 |
| vinodmr | If you return a 201 created would that call be sync or async? | 17:40 |
| simonmcc | and you query status just using the regular record-get? | 17:40 |
| betsy | or provide a callback? | 17:40 |
| kiall | 201 Created would be sync, and would indicate the new record should be visible on the DNS server immediately | 17:40 |
| eankutse | So how does the user find the status of a long running 202 job? | 17:40 |
| kiall | eankutse, by querying the URL and inspecting the status field. | 17:41 |
| kiall | That would follow the pattern set by Nova etc for async actions, like booting a VM | 17:41 |
| kiall | A new VM starts in the "BUILDING" state, and progresses over time to the "ACTIVE" state | 17:41 |
| jmcbride | kiall: So I assume we provide a unique endpoint for the user to query for status? | 17:43 |
| 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:43 |
| 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 |
| kiall | As an example, if if POST /v2/records | 17:44 |
| 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 |
| kiall | (with a 202 Accepted status) | 17:45 |
| kiall | From there, you can query /v2/records/{record-uuid} and check if status has changed to ACTIVE | 17:45 |
| CaptTofu | that sounds logical | 17:46 |
| vinodmr | #agreed on returning status similar to Nova | 17:46 |
| 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 |
| CaptTofu | #agreed on returning status similar to Nova | 17:46 |
| CaptTofu | leaves room ... | 17:46 |
| jmcbride | Agreed, seems like extra overhead to have an additional asyc call. Can we support providing a unique ID on each request? | 17:47 |
| 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:47 |
| *** zane has quit IRC | 17:47 | |
| *** zane has joined #openstack-meeting-alt | 17:47 | |
| 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 |
| kiall | The record has a unique ID, and a "status" field | 17:48 |
| kiall | once all pending changes are live, status will change to "ACTIVE" | 17:49 |
| 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 |
| *** markwash has joined #openstack-meeting-alt | 17:50 | |
| kiall | But - that's intended for debugging rather than end users | 17:50 |
| 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:50 |
| jmcbride | time check - we have 10 more minutes | 17:51 |
| 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 |
| CaptTofu | when should be discuss openstack in Hong Kong? | 17:51 |
| jmcbride | #agreed | 17:51 |
| kiall | Okay! So .. | 17:51 |
| jmcbride | CaptTofu - I would like to discuss that next as well (skip the documentation topic) | 17:52 |
| kiall | #action kiall and eankutse to discuss API over the next few days | 17:52 |
| kiall | #topic Identify opportunities to maximize collaboration | 17:52 |
| *** openstack changes topic to "Identify opportunities to maximize collaboration (Meeting topic: designate)" | 17:52 | |
| kiall | Moving on quickly :) | 17:52 |
| eankutse | kiall: ok | 17:52 |
| jmcbride | so, in proposing this item, I feel our project interim goals are a little different from other official and incubated projects. | 17:53 |
| kiall | jmcbride: so, are you guys going to make it to Hong Kong? | 17:53 |
| CaptTofu | I have yet to submit a talk but was going to base it off our last talk | 17:53 |
| CaptTofu | though you guys are now involved so... | 17:54 |
| jmcbride | it seems like designate would benefit more from an interim designate "summit". | 17:54 |
| kiall | jmcbride: that sounds like it could be fun :) What did you have in mind? | 17:54 |
| CaptTofu | Prague? | 17:54 |
| eankutse | :-) | 17:54 |
| jmcbride | I propose we come together before that | 17:54 |
| jmcbride | for targetted and focused sessions to advance designate towards official Openstack project status. | 17:55 |
| simonmcc | i like the sound of that | 17:55 |
| CaptTofu | #agreed on focus on official Openstack project status | 17:55 |
| kiall | Yea, I think that's a great idea. (Travel budgets this year are going to be tight ;)) | 17:56 |
| 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 |
| jmcbride | Hong Kong = $$$$$$$ | 17:56 |
| simonmcc | jmcbride did you have a location & month in mind? | 17:57 |
| kiall | Yea, I would assuming EU <-> US is about the same though :) | 17:57 |
| kiall | jmcbride: did you have a time/place in mind? | 17:57 |
| kiall | simonmcc: beat me to it! | 17:57 |
| jmcbride | Austin Tx (or something closer) = pennies :) | 17:57 |
| jmcbride | although I would LOVE to see Ireland! | 17:57 |
| CaptTofu | heheh | 17:57 |
| simonmcc | mid-point for "us" would be new york, but if you can host in Austin, that might work too | 17:57 |
| CaptTofu | well, | 17:57 |
| CaptTofu | we are thinking internally as a team to go to Ireland mid Sept. possiby | 17:57 |
| CaptTofu | possibly, even | 17:58 |
| jmcbride | You can stay at my house, its right near the river (do you like canoing?) | 17:58 |
| CaptTofu | Austin has a good Whole Foods | 17:58 |
| tsimmons | #agree on Party at Joe's house | 17:58 |
| jmcbride | OK, why don't we have an action for CaptTofu and I to chat details for a slumber party | 17:58 |
| 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 |
| CaptTofu | #action figure out this meeting thing | 17:59 |
| kiall | #action jmcbride and CaptTofu to sync up on party | 17:59 |
| jmcbride | nice. | 17:59 |
| kiall | #topic How do we identify more small tasks that developers and testers can work on | 17:59 |
| *** openstack changes topic to "How do we identify more small tasks that developers and testers can work on (Meeting topic: designate)" | 17:59 | |
| CaptTofu | and how to involve other organizations | 17:59 |
| jmcbride | I think that topic can be closed for now. | 17:59 |
| kiall | 1 min to go ;) | 17:59 |
| jmcbride | CaptTofu, good point! | 17:59 |
| kiall | So .. We've been a bit overloaded on our side over the last week or so | 18:00 |
| CaptTofu | kiall: what we have been doing - I think is a good start | 18:00 |
| kiall | And, filing small bugs that we didn't need fixed yesterday has been hard :) | 18:00 |
| CaptTofu | find a bug, find someone with the most expertise in that area | 18:00 |
| *** colinmcnamara has quit IRC | 18:00 | |
| 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 |
| 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 |
| jmcbride | Hey guys, I think we need to head to another commitment, shall we call it a day? | 18:01 |
| kiall | Yea :) | 18:02 |
| kiall | Lets | 18:02 |
| simonmcc | thanks everybody | 18:02 |
| kiall | Thanks all - and we'll sync up again tomorrow/the day after | 18:02 |
| kiall | #endmeeting | 18:02 |
| eankutse | bye | 18:02 |
| *** openstack changes topic to "OpenStack meetings (alternate)" | 18:02 | |
| openstack | Meeting ended Wed Jul 24 18:02:20 2013 UTC. Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4) | 18:02 |
| openstack | Minutes: http://eavesdrop.openstack.org/meetings/designate/2013/designate.2013-07-24-17.00.html | 18:02 |
| openstack | Minutes (text): http://eavesdrop.openstack.org/meetings/designate/2013/designate.2013-07-24-17.00.txt | 18:02 |
| betsy | bye | 18:02 |
| openstack | Log: http://eavesdrop.openstack.org/meetings/designate/2013/designate.2013-07-24-17.00.log.html | 18:02 |
| kiall | Meeting logs ^ | 18:02 |
| jmcbride | cheers all! See ya later. | 18:02 |
| *** vinodmr has left #openstack-meeting-alt | 18:03 | |
| *** eankutse has left #openstack-meeting-alt | 18:03 | |
| *** tsimmons1 has joined #openstack-meeting-alt | 18:04 | |
| *** jergerber has joined #openstack-meeting-alt | 18:05 | |
| *** demorris has quit IRC | 18:06 | |
| *** jmcbride has quit IRC | 18:07 | |
| *** betsy has quit IRC | 18:07 | |
| *** betsy_ has joined #openstack-meeting-alt | 18:07 | |
| *** tsimmons1 has left #openstack-meeting-alt | 18:07 | |
| *** colinmcnamara has joined #openstack-meeting-alt | 18:07 | |
| *** tsimmons has quit IRC | 18:07 | |
| *** jmcbride has joined #openstack-meeting-alt | 18:09 | |
| *** zane has quit IRC | 18:10 | |
| *** zane has joined #openstack-meeting-alt | 18:12 | |
| gcheng | Hi all, | 18:12 |
| simonmcc | gcheng are you here for the DNS/Designate meeting? You just missed it, we finished already | 18:14 |
| gcheng | @simonmcc, I'm here all the time with two ears. :) | 18:15 |
| simonmcc | gcheng :-) | 18:15 |
| gcheng | so is nova-dns will be, or already abandoned by Designate/Moniker? | 18:16 |
| simonmcc | nova-dns is largely abandoned AFAIK | 18:17 |
| *** demorris has joined #openstack-meeting-alt | 18:17 | |
| gcheng | great. I see latest code update to nova-dns was one year ago, but still like to confirm from your Captains. | 18:18 |
| *** zane has quit IRC | 18:18 | |
| *** zane has joined #openstack-meeting-alt | 18:18 | |
| simonmcc | we should move this back to #openstack-dns :-) | 18:19 |
| simonmcc | it's not "ours" to abandon | 18:19 |
| *** jcru|away is now known as jcru | 18:19 | |
| gcheng | :) | 18:20 |
| *** pdmars has joined #openstack-meeting-alt | 18:20 | |
| *** msisk has left #openstack-meeting-alt | 18:26 | |
| *** sarob has joined #openstack-meeting-alt | 18:39 | |
| *** mugsie has left #openstack-meeting-alt | 18:39 | |
| *** sarob has quit IRC | 18:42 | |
| *** sarob has joined #openstack-meeting-alt | 18:42 | |
| *** jergerber has quit IRC | 18:53 | |
| *** sarob has quit IRC | 18:56 | |
| *** sarob has joined #openstack-meeting-alt | 18:57 | |
| *** jergerber has joined #openstack-meeting-alt | 18:57 | |
| *** ashestakov__ has joined #openstack-meeting-alt | 19:01 | |
| *** sarob has quit IRC | 19:02 | |
| *** zane has quit IRC | 19:05 | |
| *** zane has joined #openstack-meeting-alt | 19:12 | |
| *** zane has quit IRC | 19:13 | |
| *** zane has joined #openstack-meeting-alt | 19:13 | |
| *** jergerber has quit IRC | 19:13 | |
| *** tsg has joined #openstack-meeting-alt | 19:13 | |
| *** jmcbride1 has joined #openstack-meeting-alt | 19:16 | |
| *** jmcbride has quit IRC | 19:16 | |
| *** jergerber has joined #openstack-meeting-alt | 19:20 | |
| *** gcheng has quit IRC | 19:27 | |
| *** sarob has joined #openstack-meeting-alt | 19:29 | |
| *** colinmcnamara has quit IRC | 19:39 | |
| *** sarob_ has joined #openstack-meeting-alt | 19:42 | |
| *** sarob has quit IRC | 19:46 | |
| *** sarob_ has quit IRC | 19:47 | |
| *** colinmcnamara has joined #openstack-meeting-alt | 19:54 | |
| *** KennethWilke has joined #openstack-meeting-alt | 19:55 | |
| *** DandyPandy has joined #openstack-meeting-alt | 19:57 | |
| *** robertmyers has joined #openstack-meeting-alt | 19:57 | |
| *** hub_cap has joined #openstack-meeting-alt | 19:59 | |
| *** jmontemayor has joined #openstack-meeting-alt | 19:59 | |
| *** earthpiper has joined #openstack-meeting-alt | 19:59 | |
| hub_cap | #startmeeting trove | 20:00 |
| openstack | Meeting started Wed Jul 24 20:00:18 2013 UTC. The chair is hub_cap. Information about MeetBot at http://wiki.debian.org/MeetBot. | 20:00 |
| openstack | Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. | 20:00 |
| *** openstack changes topic to " (Meeting topic: trove)" | 20:00 | |
| openstack | The meeting name has been set to 'trove' | 20:00 |
| vipul | \o/ | 20:00 |
| robertmyers | o/ | 20:00 |
| pdmars | o/ | 20:00 |
| hub_cap | lets give a min | 20:00 |
| *** datsun180b has joined #openstack-meeting-alt | 20:00 | |
| *** esp has joined #openstack-meeting-alt | 20:00 | |
| KennethWilke | hi | 20:01 |
| earthpiper | ello | 20:01 |
| *** TheRealBill has joined #openstack-meeting-alt | 20:01 | |
| hub_cap | #link https://wiki.openstack.org/wiki/Meetings/TroveMeeting | 20:01 |
| datsun180b | hello | 20:01 |
| kevinconway | 7o | 20:01 |
| *** grapex has joined #openstack-meeting-alt | 20:01 | |
| hub_cap | #link http://eavesdrop.openstack.org/meetings/trove/2013/trove.2013-07-17-20.00.html | 20:01 |
| hub_cap | #topic action items | 20:01 |
| *** openstack changes topic to "action items (Meeting topic: trove)" | 20:01 | |
| *** imsplitbit has joined #openstack-meeting-alt | 20:01 | |
| hub_cap | heh so AI's will be quick | 20:01 |
| imsplitbit | o/ | 20:01 |
| hub_cap | vipul: any doc update on the wiki? | 20:01 |
| grapex | o/ | 20:02 |
| vipul | hub_cap: done! | 20:02 |
| hub_cap | ive moved every page ive looked at | 20:02 |
| imsplitbit | yay! | 20:02 |
| vipul | see https://wiki.openstack.org/wiki/Trove | 20:02 |
| hub_cap | done? | 20:02 |
| hub_cap | i moved two today | 20:02 |
| *** SlickNik has joined #openstack-meeting-alt | 20:02 | |
| hub_cap | oh done w/ that page | 20:02 |
| SlickNik | o/ | 20:02 |
| *** amytron has joined #openstack-meeting-alt | 20:02 | |
| hub_cap | cool | 20:02 |
| vipul | are there more pages that got lost? | 20:02 |
| hub_cap | oh ya vipul tons | 20:02 |
| vipul | moved a bunch of them as well | 20:02 |
| hub_cap | the next one i think we covered eh? | 20:02 |
| hub_cap | search reddwarf | 20:02 |
| hub_cap | or red dwarf | 20:02 |
| hub_cap | anyhoo we can just update as we see fit | 20:03 |
| hub_cap | its for older stuff anyway | 20:03 |
| hub_cap | like i did configuration editing today cuz a mirantis guy asked me about it | 20:03 |
| hub_cap | so i thikn the next AI is already taken care of eh? | 20:03 |
| hub_cap | Stop test and Unsuccessful Restart test thing | 20:03 |
| hub_cap | we decided to move it out of bb testsing | 20:03 |
| cp16net | \o | 20:03 |
| grapex | Yep | 20:04 |
| hub_cap | =o= four arm me | 20:04 |
| hub_cap | or my top gun pin | 20:04 |
| hub_cap | ok cool lets move on then | 20:04 |
| hub_cap | im going ot leave the api discussion to last | 20:04 |
| hub_cap | so ill skip to imsplitbits topic | 20:04 |
| cp16net | \^o | 20:04 |
| cp16net | my muscles | 20:04 |
| cp16net | lol | 20:05 |
| hub_cap | lol cp16net | 20:05 |
| hub_cap | #topic Replication API update | 20:05 |
| *** openstack changes topic to "Replication API update (Meeting topic: trove)" | 20:05 | |
| hub_cap | so imsplitbit tell us about replication api | 20:05 |
| imsplitbit | well we made the concensus | 20:05 |
| imsplitbit | that we were going to use /clusters as a helper for cluster ops | 20:06 |
| imsplitbit | instance ops stay in /instances | 20:06 |
| djohnstone | o/ | 20:06 |
| imsplitbit | I've begun work on the /clustertypes | 20:06 |
| imsplitbit | which is "flavors for clusters" | 20:06 |
| hub_cap | cool | 20:06 |
| imsplitbit | thats about all I have at this point | 20:06 |
| hub_cap | thats a good way to put it | 20:06 |
| hub_cap | ok great | 20:06 |
| hub_cap | now for the topic at hand | 20:06 |
| hub_cap | the hp guys dont know much about this yet so | 20:06 |
| imsplitbit | I HATE IT | 20:07 |
| * hub_cap makes vipul read the Windows ME user guide | 20:07 | |
| imsplitbit | lol | 20:07 |
| imsplitbit | wanted to start early :) | 20:07 |
| * hub_cap pokes SlickNik | 20:07 | |
| vipul | windows fun! | 20:07 |
| KennethWilke | 3.1 is better | 20:07 |
| imsplitbit | ouch | 20:07 |
| * SlickNik wakes up | 20:07 | |
| hub_cap | vipul: SlickNik take a minute to read | 20:07 |
| imsplitbit | ME... | 20:07 |
| hub_cap | #topic capabilities | 20:07 |
| *** openstack changes topic to "capabilities (Meeting topic: trove)" | 20:07 | |
| hub_cap | #link https://wiki.openstack.org/wiki/Trove/extensionsrefactor | 20:07 |
| hub_cap | i prefer to use the term capabilities to extension earthpiper | 20:07 |
| hub_cap | fwiw | 20:07 |
| earthpiper | sho nuff | 20:08 |
| hub_cap | lets give till 20:10 to finish reading it and talk about the pro/con | 20:08 |
| earthpiper | brb | 20:08 |
| earthpiper | then | 20:08 |
| kevinconway | hub_cap: 20:10 central standard time right? | 20:08 |
| hub_cap | heh yes kevinconway | 20:08 |
| hub_cap | not utc | 20:08 |
| KennethWilke | ... | 20:08 |
| KennethWilke | i only take epoch | 20:08 |
| *** KennethWilke has left #openstack-meeting-alt | 20:08 | |
| kevinconway | so for the next five hours? | 20:08 |
| hub_cap | Wed Jul 24 20:08:27 UTC 2013 | 20:09 |
| *** KennethWilke has joined #openstack-meeting-alt | 20:09 | |
| hub_cap | u have 1 1/2 minute to keep annoying me kevinconway | 20:09 |
| hub_cap | ;) | 20:09 |
| kevinconway | its 15:10 CST | 20:09 |
| kevinconway | why is time so confusing? | 20:09 |
| hub_cap | cuz in openstack u only speak in utc | 20:09 |
| grapex | hub_cap: Would it be bad form to add to that wiki article at this time? | 20:09 |
| hub_cap | grapex: ummm yes | 20:10 |
| hub_cap | well no | 20:10 |
| KennethWilke | i want integer epoch timestamps, or you do it right! | 20:10 |
| hub_cap | but no one would read it | 20:10 |
| KennethWilke | :) | 20:10 |
| hub_cap | but its ok grapex to do that because u wnt the information to persist | 20:10 |
| hub_cap | so go for it | 20:10 |
| hub_cap | u can always interject those points when relevant | 20:10 |
| KennethWilke | link us your diff! | 20:11 |
| hub_cap | LOL just click history | 20:11 |
| hub_cap | ok vipul SlickNik have a feel for whats going on? | 20:11 |
| hub_cap | earthpiper: back? | 20:11 |
| SlickNik | yeah | 20:11 |
| vipul | kinda | 20:11 |
| hub_cap | kevinconway: happy that we are in utc time? | 20:11 |
| KennethWilke | hub_cap: he is afk | 20:11 |
| hub_cap | k | 20:12 |
| vipul | so we want to dynamically load a service.py based on service_type? | 20:12 |
| hub_cap | so yes | 20:12 |
| cp16net | i'm never in utc time | 20:12 |
| hub_cap | but its more than that | 20:12 |
| hub_cap | its dynamically load the api based on service_type | 20:12 |
| KennethWilke | i think we want to consider the impact to the api over implementation at this moment | 20:12 |
| hub_cap | as in, /instances/id/users changes payload based on what type your instance is | 20:12 |
| KennethWilke | if i understand correctly | 20:12 |
| vipul | hmm | 20:12 |
| hub_cap | correct KennethWilke | 20:13 |
| SlickNik | so not just guestagent, but the trove-api as well. | 20:13 |
| hub_cap | lets hold off on opinions till earthpiper gets back | 20:13 |
| hub_cap | correct SlickNik | 20:13 |
| earthpiper | yeah | 20:13 |
| hub_cap | the arguments are 1) the user shuldnt care that he has a redis type, he should just pass info to /users (yes bad example) | 20:13 |
| vipul | So .. isn't it kinda odd that the body would change based on a type of database? | 20:13 |
| imsplitbit | you cannot have an opinion unless earthpiper is present??? | 20:13 |
| hub_cap | no imsplitbit u cannot | 20:14 |
| imsplitbit | lol | 20:14 |
| hub_cap | he is driving this | 20:14 |
| KennethWilke | vipul: i think so | 20:14 |
| hub_cap | go earthpiper (pips) | 20:14 |
| hub_cap | the input/output can differ based on the capability | 20:14 |
| SlickNik | btw, hello earthpiper! | 20:14 |
| earthpiper | Hi I am Conrad at Rackspace. | 20:14 |
| datsun180b | oh that makes sense now | 20:14 |
| vipul | howdy | 20:14 |
| earthpiper | If you don't know my net handle =) | 20:14 |
| *** zane has quit IRC | 20:15 | |
| KennethWilke | hello, i am kenneth at rackspace | 20:15 |
| KennethWilke | just... in case | 20:15 |
| imsplitbit | greetings | 20:15 |
| imsplitbit | ok go | 20:15 |
| hub_cap | he is the only Kenneth at rackspace | 20:15 |
| imsplitbit | lol | 20:15 |
| datsun180b | what's the frequency | 20:15 |
| kevinconway | Hello, I am Inigo Montoya… You killed my father. | 20:16 |
| hub_cap | LOL | 20:16 |
| imsplitbit | earthpiper: go | 20:16 |
| hub_cap | srsly GO | 20:16 |
| hub_cap | GO GO GO | 20:16 |
| hub_cap | weve burned 6 minutes on intros :) | 20:16 |
| imsplitbit | exactly | 20:16 |
| earthpiper | So what do you guys think? | 20:16 |
| hub_cap | no | 20:16 |
| imsplitbit | I think that sushi sounds great | 20:16 |
| SlickNik | hub_cap: trying to understand the motivation for this... | 20:16 |
| hub_cap | tell us what you think earthpiper | 20:16 |
| earthpiper | Oh cool. | 20:16 |
| earthpiper | Thanks | 20:16 |
| hub_cap | SlickNik: earthpiper will explain | 20:16 |
| hub_cap | what is the motivation earthpiper | 20:17 |
| earthpiper | So.. the problem with current extensions is they load everything in that directory. | 20:17 |
| earthpiper | We want Trove to support more Databases. | 20:17 |
| earthpiper | and right now the application is rather monolithic. | 20:17 |
| *** demorris has quit IRC | 20:17 | |
| *** zane has joined #openstack-meeting-alt | 20:17 | |
| hub_cap | lets stick to the api earthpiper | 20:17 |
| hub_cap | not the impl | 20:17 |
| hub_cap | the why so to speak | 20:17 |
| juice | i have a high level question | 20:18 |
| earthpiper | You get a routing conflict with current extensions if you have different requirements for instances functions. | 20:18 |
| hub_cap | correct | 20:18 |
| earthpiper | So like Users for postgres users for mysql etc. | 20:18 |
| hub_cap | so /users doesnt make sense if you host > 1 database type in the same installation | 20:18 |
| KennethWilke | or on my redis boxen | 20:19 |
| hub_cap | how do u differenciate between postgres' users and mysql users | 20:19 |
| hub_cap | the one u add users too KennethWilke ;) | 20:19 |
| vipul | are they really different types of users? they are 'database' users | 20:19 |
| hub_cap | juice: this is irc, ask away | 20:19 |
| imsplitbit | assuming we will allow a redis and mysql install on one instance yes? | 20:19 |
| juice | yeah I am formulating it :) | 20:19 |
| hub_cap | one installation imsplitbit | 20:19 |
| hub_cap | not one instnace | 20:19 |
| esp | regarding the bit about different POST body's in the API will the POST body's still follow the same structure even though they will be different? | 20:19 |
| KennethWilke | they may have different parameters based on database implementation | 20:19 |
| *** amytron has quit IRC | 20:19 | |
| KennethWilke | or requirements | 20:19 |
| imsplitbit | ok one aggregated infrastructure to manage all dbs | 20:20 |
| hub_cap | yes for instance postgres requires a default db, from what i think jeffe said | 20:20 |
| juice | what level of abstraction do we want for trove or what level of abstraction do we think is most suitable for trove | 20:20 |
| earthpiper | Well we should not make a person only host one type of db system per cluster. | 20:20 |
| hub_cap | and this is more than just /users its /anything | 20:20 |
| *** SergeyLukjanov has quit IRC | 20:20 | |
| KennethWilke | /db_specific_feature | 20:20 |
| hub_cap | correct | 20:20 |
| hub_cap | it could be /flushkeys for redis | 20:20 |
| juice | is that we plan on configuring trove at deploy time for a specifc implementation and have it build those instance types | 20:20 |
| hub_cap | ;) | 20:20 |
| hub_cap | juice: it shoudl be able to handle > 1 service_type | 20:20 |
| hub_cap | in the same api | 20:20 |
| juice | or is trove supposed to standup and handle any db implementation type | 20:20 |
| hub_cap | you configure it juice | 20:21 |
| vipul | so there are two types of things... | 20:21 |
| hub_cap | to handle what u want to support | 20:21 |
| hub_cap | avail_types=postgres, mysql, percona, redis | 20:21 |
| hub_cap | so to speak | 20:21 |
| vipul | additional operations on a db_type.. .which is differnt from the same operation, but different request for db_types | 20:21 |
| juice | and from the end user do they know which service type they are getting | 20:21 |
| hub_cap | yes so same uri, different body | 20:21 |
| vipul | I think we can support db_type specific actions | 20:21 |
| hub_cap | sound familar? | 20:21 |
| juice | we don't allow them currently to specify the service type on boot | 20:21 |
| hub_cap | /actions {} | 20:21 |
| jcooley | the thing is, if you are managing multiple databases with the same infrastructure, what are you gaining if each one has a completely different command-implementation? | 20:22 |
| grapex | vipul: I don't know- so far it seems like the users call has had to change a lot. We've added things to it and then found out it was ambigious because of how MySQL worked. Maybe I've mistinterpretted what you're saying, but I can't imagine users would "just work" for all db types. | 20:22 |
| SlickNik | juice: this proposal seeks to change that, I think. | 20:22 |
| hub_cap | technically juice we do | 20:22 |
| jcooley | i mean, why not just clone the 5 or 6 nodes | 20:22 |
| hub_cap | pass service_type in to the create, and watch it go | 20:22 |
| jcooley | right, | 20:22 |
| jcooley | if it doesn't work for a set of common types, why force a common infrastructure? | 20:22 |
| hub_cap | what benefit does having a bunch of duplicate api nodes w/ a single config diffence buy you jcooley? | 20:22 |
| hub_cap | its gonna be the same codebase | 20:23 |
| jcooley | i dunno, i have different api nodes for nova, swift, savanna, ... | 20:23 |
| hub_cap | so the difference between 6 nodes is gonna be service_type=blah | 20:23 |
| vipul | grapex: Right, so I agree there may be differences, and I think instead of a body that's compeletely different for different databases, we come up with either a genericized API that works across, or we make things optional | 20:23 |
| juice | ok so the user specified the service type and they are now wanting to interact with a redis or postgres instance | 20:23 |
| KennethWilke | jcooley: but you should be able to spin up ubuntu and centos or whatever on one nova deployment | 20:23 |
| earthpiper | This is just to make the deployment of new db types easier. | 20:23 |
| jcooley | right, with the same api | 20:23 |
| KennethWilke | on the same boxes if you would like | 20:24 |
| earthpiper | or not like | 20:24 |
| jcooley | well, that's where i'm getting lost | 20:24 |
| earthpiper | you can do what you want with it | 20:24 |
| grapex | vipul: I think having a generic user call won't be satisfying for power users, unless we offer it in addition to a type specific call | 20:24 |
| datsun180b | so even if not every db has a concept of users, ideally they'll all have a concept of connections. is that a common ground we can build off of? | 20:24 |
| hub_cap | not really | 20:24 |
| hub_cap | take redis | 20:24 |
| grapex | So there could be a user create call specific for MySQL, but then we could make a generic one for any DB. | 20:24 |
| hub_cap | no users at all | 20:24 |
| jcooley | sure, flexibility is nice but i'm not seeing the code sharing. | 20:24 |
| hub_cap | nil | 20:24 |
| jcooley | only infrastructure sharing. | 20:24 |
| KennethWilke | users? | 20:24 |
| earthpiper | It returns 404 | 20:24 |
| earthpiper | rather than a 200 | 20:24 |
| earthpiper | because that route is not defined for redis | 20:25 |
| hub_cap | so do we, since redis can support resizes, resets, all the things trove /instances support | 20:25 |
| hub_cap | do we have to stand up a diff service to host it? | 20:25 |
| hub_cap | and do we need a different docbook altogether? | 20:25 |
| hub_cap | just so we can have separate services? | 20:25 |
| vipul | hub_cap: No, i think it's fine to return not-implemented if things don't match | 20:25 |
| vipul | but that not impelemtned should come from the Guest Agent | 20:25 |
| hub_cap | i dont agree | 20:25 |
| vipul | which determines whether that operation can be done or not | 20:25 |
| hub_cap | id prefer to return "there is no route for this" | 20:25 |
| KennethWilke | i think not implemented should be returned by the api | 20:26 |
| datsun180b | more informative than a 404 | 20:26 |
| hub_cap | the same thing when you pass /instances/id/honeybooboo | 20:26 |
| vipul | exactly | 20:26 |
| grapex | Yeah, we don't want the guest agent to have to be that intelligent about what the API can do. | 20:26 |
| cp16net | yeah not implemented doesnt sound like something that should be returned | 20:26 |
| jcooley | i like vipul's idea of placing the differences in the guest agent... | 20:26 |
| vipul | why is it that they can invoke the same route at the same endpoint in oen case but not the other | 20:26 |
| juice | jumping to solutions here but what comes to mind is that each database would have it's own discrete api command structure and TROVE simply becomes a router to the different api implementations | 20:26 |
| hub_cap | juice: that is one of the approaches | 20:27 |
| SlickNik | grapex: but the guest agent needs to be intelligent about what the API can do since the guestagent will be the one doing it! | 20:27 |
| kevinconway | hub_cap: 501 Not Implemented | 20:27 |
| juice | you might even extend that and have different instances of task manager out there for the various implementations | 20:27 |
| grapex | juice: That's my favorite idea, with the addition that you'd have a generic instance resource that could do actions that were performable by any db type | 20:27 |
| hub_cap | naw taskmgr shoudl be generi | 20:27 |
| hub_cap | c | 20:27 |
| juice | this approach allows you to keep a generic front end yet have documentable and implementation specific apis | 20:27 |
| hub_cap | the big differences are the api+guest impl | 20:27 |
| grapex | SlickNik: Of course, but the guest agent shouldn't have to understand someone made a request for a Redis operation and the server is MySQL | 20:27 |
| vipul | juice: that means Trove has many APIs | 20:28 |
| hub_cap | stop typing | 20:28 |
| grapex | The API should know that and not even ask the guest agent | 20:28 |
| hub_cap | do we agree that trove can host > 1 capability | 20:28 |
| KennethWilke | yes | 20:28 |
| vipul | yes | 20:28 |
| earthpiper | yes | 20:28 |
| grapex | yes | 20:28 |
| kevinconway | #vote yes | 20:28 |
| hub_cap | good | 20:28 |
| robertmyers | yes | 20:28 |
| cp16net | yes | 20:28 |
| cp16net | #voted | 20:28 |
| hub_cap | i can start a vote kevinconway ;) | 20:28 |
| vipul | o/ | 20:28 |
| hub_cap | ok good | 20:28 |
| SlickNik | #agreed | 20:28 |
| hub_cap | lets move on | 20:28 |
| KennethWilke | #done | 20:28 |
| hub_cap | now its a matter of the proposal | 20:28 |
| hub_cap | do we 1) dynamically change the route | 20:28 |
| hub_cap | or 2) define namespaces for the routes | 20:29 |
| vipul | i see 3 things here... | 20:29 |
| KennethWilke | 2 | 20:29 |
| hub_cap | 1 is potentially more confusing for the user (imho) and 2 is potentially more annoying for the user (since there is 1 type) | 20:29 |
| jcooley | grapex: disagree. | 20:29 |
| hub_cap | whats 3? | 20:29 |
| vipul | 1. choosing which extensions should be loaded instead of all | 20:29 |
| vipul | 2. dynamic route / dynamic body | 20:29 |
| vipul | 3. fixed route w/namespaced route | 20:30 |
| jcooley | api should not have all the intelligence or we have to bake the polymorphism into it | 20:30 |
| hub_cap | hold up vipul | 20:30 |
| hub_cap | 1 is a installation procedure | 20:30 |
| hub_cap | and 2/3 are the api differnces | 20:30 |
| grapex | I think we agreed 1 wasn't an option if there's >1 capability | 20:30 |
| hub_cap | 1 will happen | 20:30 |
| earthpiper | Correct grapex | 20:30 |
| esp | hub_cap: is 2) above basically defining new routes for each db type? | 20:30 |
| vipul | ok.. makes sense | 20:30 |
| KennethWilke | esp: yes | 20:30 |
| hub_cap | u will choose the types you want to run based on your needs | 20:30 |
| hub_cap | avail_types=cassandra,oracle,couchdb | 20:31 |
| esp | KennethWilke: thx. yeah I like that better. | 20:31 |
| juice | we should revise that original vote to say "trove should dynamically support > 1 impl at runtime" | 20:31 |
| KennethWilke | esp: yw :) | 20:31 |
| grapex | juice: Good idea | 20:31 |
| hub_cap | huh!?!? | 20:31 |
| hub_cap | no | 20:31 |
| vipul | i'm ok with dyanmically loading a route in the backend, but i am not ok with those supporting differnt bodies | 20:31 |
| cp16net | 2: means to me that you dynamically look up the instance type and do the work | 20:31 |
| hub_cap | it was jcooley that brought up to not support > 1 | 20:31 |
| vipul | i can see that we may have different validation rules for a db_type | 20:31 |
| cp16net | 3 means that its defined in the uri | 20:31 |
| hub_cap | we are getting out of hand | 20:31 |
| vipul | but the request body shoudl be the same/similar | 20:31 |
| hub_cap | let me rephrase | 20:31 |
| KennethWilke | cp16net: in any other case do you not need to know the instance type if trove supports multiple dbs? | 20:31 |
| * hub_cap bangs the gavel | 20:32 | |
| jcooley | hub_cap: only meant that if they're really different and you can't share implementation, you're not gaining anything. | 20:32 |
| hub_cap | we will support > 1 impl in the same codebase/install/api server | 20:32 |
| hub_cap | period | 20:32 |
| hub_cap | if you want cassandra and redis, you can get them | 20:32 |
| hub_cap | thats not being argued | 20:32 |
| grapex | vipul: I decided I couldn't stand the totally dynamic, every type uses the same request path idea when I realized different db_types would eventually have different bodies for the same request paths. | 20:32 |
| hub_cap | if u have to restart the api server to install a new type, thats fine | 20:32 |
| * hub_cap bangs the gavel and points at grapex | 20:32 | |
| KennethWilke | grapex: i agree | 20:32 |
| *** KennethWilke has left #openstack-meeting-alt | 20:33 | |
| *** abaron has quit IRC | 20:33 | |
| *** KennethWilke has joined #openstack-meeting-alt | 20:33 | |
| hub_cap | lol netsplit | 20:33 |
| grapex | hub_cap: Am I in contempt? | 20:33 |
| hub_cap | yes | 20:33 |
| * KennethWilke shame | 20:33 | |
| hub_cap | :P | 20:33 |
| vipul | you have the floor hub_cap | 20:33 |
| hub_cap | so the question is this | 20:33 |
| imsplitbit | NO | 20:33 |
| hub_cap | do we have an api that supports dynamic bodies, because we cannot guarantee that every call to /users will be the same | 20:33 |
| imsplitbit | I just wanted to be in contempt too :) | 20:34 |
| hub_cap | or do we support namespaced urls, where the payload is the same | 20:34 |
| grapex | hub_cap: May I approach the bench? | 20:34 |
| hub_cap | but you have to type the type in | 20:34 |
| hub_cap | grapex: aye | 20:34 |
| earthpiper | I got dibs next. | 20:34 |
| hub_cap | yes you do earthpiper | 20:34 |
| imsplitbit | then me | 20:34 |
| KennethWilke | then i! | 20:34 |
| hub_cap | no imsplitbit | 20:34 |
| hub_cap | never | 20:34 |
| grapex | Another thing to consider is in addition to namespaced requests for specific types, we could also make requests to the existing instances path w/o the db_type to do things which *ANY* instance could do | 20:34 |
| imsplitbit | damnit | 20:34 |
| grapex | Think of it like calling a super class's interface | 20:35 |
| hub_cap | it will, resizes will still go thru /instance/id | 20:35 |
| hub_cap | /instance/id/resize | 20:35 |
| hub_cap | NO ACTIONS | 20:35 |
| imsplitbit | but we all *love* actions | 20:35 |
| grapex | Those are our favorite!! | 20:35 |
| juice | disagree | 20:35 |
| * juice notes sarcasm | 20:35 | |
| hub_cap | /instance/id/resize, /instances/id/user vs /instances/id/mysql/user, /instances/id/user vs /instances/id/redis/user | 20:35 |
| grapex | But they're so hard to use... :( | 20:35 |
| grapex | j/k | 20:36 |
| grapex | Put me back in contempt | 20:36 |
| earthpiper | So can I interject really quick. | 20:36 |
| * hub_cap urges grapex to use Windows Millennium Edition | 20:36 | |
| esp | I think it would be less redundancy (in your DTO or value objects) if request payloads and response payloads are the same across db_types. | 20:36 |
| hub_cap | earthpiper: plz do | 20:36 |
| earthpiper | Ok | 20:36 |
| earthpiper | take a gander at client flows | 20:36 |
| earthpiper | at the bottom of the propsal | 20:36 |
| earthpiper | https://wiki.openstack.org/wiki/Trove/extensionsrefactor | 20:36 |
| hub_cap | esp: we cant guarantee that | 20:36 |
| SlickNik | hub_cap: While I love the idea, I'm worried that this opens up the opportunity for the APIs of the different implementations to diverge to a point where they look like completely different APIs. This means that as a consumer, I have to relearn / re-work the API every time I need a different type of instance. This seems like a serious disadvantage for a managed db solution, which should make my life easier by providing somewhat of a consiste | 20:36 |
| esp | hub_cap: nope but it's a good place to start. | 20:37 |
| grapex | esp: You could of course reuse classes that were similar as base objects between the request bodies of various types. | 20:37 |
| vipul | SlickNik: +1 | 20:37 |
| imsplitbit | SlickNik: +1 | 20:37 |
| hub_cap | im not sure what SlickNik is saying | 20:37 |
| hub_cap | voting for #1 or #2? | 20:37 |
| KennethWilke | 1 i believe | 20:37 |
| vipul | neither | 20:37 |
| hub_cap | or voting against to ever have /usrs | 20:37 |
| datsun180b | so i have a half-baked idea wrt to marrying namespaces and dynamic | 20:37 |
| grapex | SlickNik: Do you mean a user switching between MySQL and Percona or something similar like that? | 20:37 |
| SlickNik | not taking a side of the #1 or #2 fence yet. | 20:37 |
| KennethWilke | may i? | 20:38 |
| hub_cap | i dont think earthpiper got to interject | 20:38 |
| hub_cap | he just said go read some shit | 20:38 |
| KennethWilke | earthpiper: gogogog | 20:38 |
| earthpiper | So the problem is | 20:38 |
| earthpiper | If we support other databases | 20:38 |
| earthpiper | stuff changes | 20:38 |
| esp | grapex: agreed but I guess I'd like to see how different each imp will be to say for sure | 20:38 |
| earthpiper | peroid | 20:38 |
| vipul | If we have a single endpoint, and a single API... why would someone be required to figure out what the body or URI shoudl be based on a type | 20:38 |
| earthpiper | vipul: that does not matter | 20:38 |
| earthpiper | how else would you do it? | 20:39 |
| earthpiper | Different DB | 20:39 |
| earthpiper | means a possible different contract to do stuff | 20:39 |
| imsplitbit | vipul: +1 | 20:39 |
| vipul | You have a genericized body | 20:39 |
| grapex | I think the issue is, we're going between MySQL and NoSQL so stuff is going to change | 20:39 |
| vipul | say someone is using Java | 20:39 |
| robertmyers | why don't we just remove the ability to create users? | 20:39 |
| robertmyers | done | 20:39 |
| grapex | I think between SQL db's things could be similar | 20:39 |
| vipul | they are likely going to be bulidng a object model of our request /responses | 20:39 |
| KennethWilke | grapex: +1 | 20:39 |
| hub_cap | robertmyers: you just made our director cry | 20:39 |
| grapex | What if we had, in addition to "mysql/instances/<instance_id>" and "postgres/instances/<instance_id>", a "sql/instancs/<instance_id>" which was a subset. | 20:39 |
| vipul | they are going to be required to build new object models evyer time we add another db? | 20:40 |
| grapex | Uses could use "sql" if they didn't care about MySQL specific details | 20:40 |
| datsun180b | well for dbs that don't have users, how do you get your data to and from the db? | 20:40 |
| hub_cap | sure but i think u have it backwards grapex | 20:40 |
| imsplitbit | datsun180b: I like your concept of "connection" | 20:40 |
| earthpiper | datsun180b: reddis does not support usetrs | 20:40 |
| KennethWilke | datsun180b: redis exists | 20:40 |
| earthpiper | redis* | 20:40 |
| hub_cap | instances/id/mysql vs instances/id/sql | 20:40 |
| earthpiper | but it does support backups | 20:40 |
| datsun180b | do you communicate with redis via telepathy | 20:40 |
| grapex | vipul: Not if we were smart and made our schema use superclasses appropriately. The amount of changes could be minimized. | 20:40 |
| vipul | I still feel like there are different ways to handle thigns that service types do not support | 20:40 |
| KennethWilke | nope, sockets | 20:40 |
| earthpiper | only sockets. | 20:40 |
| hub_cap | user sockets | 20:40 |
| datsun180b | so, a connection | 20:40 |
| hub_cap | :P | 20:40 |
| earthpiper | Oh | 20:41 |
| kevinconway | so /instances/id/sockets | 20:41 |
| earthpiper | So we switch userrs to connections... | 20:41 |
| hub_cap | ok lets stop talking about users | 20:41 |
| KennethWilke | thank you! | 20:41 |
| hub_cap | lets talk /flushkeys | 20:41 |
| KennethWilke | :) | 20:41 |
| datsun180b | instances/id/connections | 20:41 |
| grapex | Or rather, instances/id/users, whose request body is a subset of mysql/instances/id/users... | 20:41 |
| hub_cap | the goal here is _NOT_ to solve /users | 20:41 |
| imsplitbit | hub_cap: lets talk /flush | 20:41 |
| hub_cap | its to solve /any_db_operation | 20:41 |
| *** ashestakov__ has quit IRC | 20:41 | |
| imsplitbit | which applies to much more than redis or mysql or postgres | 20:42 |
| hub_cap | /rebalance_ring | 20:42 |
| datsun180b | where for mysql dbs instances/id/connections is an alias for instances/id/mysql/users | 20:42 |
| datsun180b | maybe a 301 MOVED PERM | 20:42 |
| hub_cap | datsun180b: lets not reinvent users | 20:42 |
| hub_cap | this is not a conversation about users | 20:42 |
| hub_cap | its a conversation about /anything for a specific db | 20:42 |
| datsun180b | i'm using it as an example to build a common ground | 20:42 |
| earthpiper | we don't need to fix users. we need to fix the routing for DB specific stuff. | 20:42 |
| vipul | having additional DB operations is totally fine -- leave it to guest agent to determine whether it's something it can act on or not | 20:42 |
| earthpiper | vipul: how do you pass it the message then? | 20:42 |
| earthpiper | Without extending the API interface | 20:43 |
| earthpiper | so the user agent knows it is being passed that? | 20:43 |
| earthpiper | How is that possible? | 20:43 |
| hub_cap | sure so you will have /instances/id/rebalance | 20:43 |
| vipul | you'd have to have a common rpc_api across all guest agents | 20:43 |
| juice | can we do internal rerouting/redirects | 20:43 |
| vipul | but the mysql_impl will decide it's not possible | 20:43 |
| earthpiper | How does the user | 20:43 |
| grapex | Again, why make the guest agent determine the type? The API knows the type and shouldn't even bother. In fact, it should validate that the user made a bad request well before considering talking to the guest. | 20:43 |
| hub_cap | see to me thats ugly vipul | 20:43 |
| earthpiper | wait | 20:43 |
| hub_cap | every guest has to impl, optionally, ANY call that ANY db can do? | 20:43 |
| earthpiper | It's not the matter of it being ugly | 20:43 |
| KennethWilke | vipul: i don't think the api should shove anything the user gives it into rabbit | 20:43 |
| datsun180b | i foresee a lot of noops hub_cap | 20:44 |
| earthpiper | It's a matter of how do you do it without extending the user api | 20:44 |
| vipul | fine, we can block that at the API level | 20:44 |
| vipul | with policy based config or something | 20:44 |
| earthpiper | No | 20:44 |
| hub_cap | ya datsun180b | 20:44 |
| vipul | that's not the point | 20:44 |
| earthpiper | how can the user send the message? | 20:44 |
| earthpiper | To do whatever you want? | 20:44 |
| hub_cap | to /instances/id/something | 20:44 |
| earthpiper | You have to extend the user api | 20:45 |
| vipul | the user will see a consistent API with every available 'operatation' | 20:45 |
| earthpiper | period. | 20:45 |
| hub_cap | obvi :) | 20:45 |
| grapex | How about /instances/id/void redirects dynamically to the typed request path. :) | 20:45 |
| hub_cap | see id rather have namespaced apis w/ capabilities | 20:45 |
| * juice is reading earthpipers proposal | 20:45 | |
| hub_cap | mysql/ can do users, schemas, and making_coffee | 20:45 |
| *** gcheng has joined #openstack-meeting-alt | 20:45 | |
| juice | did we all have a chance to think about this before coming to the meeting | 20:45 |
| KennethWilke | no | 20:45 |
| hub_cap | cassandra/ can do rebalance_ring, users and making_donuts | 20:45 |
| vipul | not really :) | 20:45 |
| KennethWilke | but i did | 20:45 |
| KennethWilke | :) | 20:45 |
| juice | perhaps we have bantered enough and need some time to give it some self-reflection and come back to this | 20:46 |
| KennethWilke | because i do not want to use trove for redis | 20:46 |
| SlickNik | earthpiper: I think the idea is to extend the API to every possible operation. And let the guestagent decide if it supports it or not. Not sure I like that…. | 20:46 |
| KennethWilke | i mean mysql** sorrty | 20:46 |
| hub_cap | redis/ CANT DO USERS (god tina eat your food - napolean voice) | 20:46 |
| KennethWilke | lol | 20:46 |
| imsplitbit | juice: I agree | 20:46 |
| vipul | juice: +1 i don't think we have enough background really to be able to make a call | 20:46 |
| hub_cap | u know i feel thats valid | 20:46 |
| earthpiper | SlickNik: I don't like that idea either. | 20:46 |
| hub_cap | can we meet tomorrow to discuss? | 20:46 |
| grapex | hub_cap: Google hang outs? | 20:46 |
| imsplitbit | I am still a fan of simple generic api and internally we route/return the right stuff | 20:46 |
| juice | works for me | 20:46 |
| vipul | imsplitbit: +1 that's what i was leading towards.. | 20:47 |
| hub_cap | i was thinking irc grapex | 20:47 |
| KennethWilke | i think irc as well | 20:47 |
| vipul | the user should see consistency | 20:47 |
| imsplitbit | this /sql /nosql /mysql /postgres thing seems to be too confusing for the end user to me | 20:47 |
| datsun180b | if only we had a channel we were all on all day together | 20:47 |
| grapex | hub_cap: Seems like short notice | 20:47 |
| hub_cap | see vipul id argue that /users w/ different payloads is _not_ consistant | 20:47 |
| SlickNik | I'd like to think about this some more as well. +1 to meeting tomorrow. | 20:47 |
| KennethWilke | consistency seems hard unless we offer consistent technologies behind trove | 20:47 |
| grapex | hub_cap: Maybe a bit later? | 20:47 |
| hub_cap | but /mysql/users is | 20:47 |
| grapex | We can all add to the wiki in the meanwhile | 20:47 |
| KennethWilke | and redis != mysql != mongo != thing not yet made we want in trove | 20:47 |
| hub_cap | do we need > 24 hrs to ruminate on this grapex? | 20:47 |
| vipul | hub_cap: but then you have postgres/users == mysql/users pretty much | 20:47 |
| hub_cap | or is your shcedule booked tomorrow? | 20:47 |
| imsplitbit | hub_cap: stop talking users!!!!!!!!!!!!!!!! | 20:47 |
| imsplitbit | :) | 20:47 |
| hub_cap | vipul: sure | 20:47 |
| grapex | hub_cap: Hey I know what I want | 20:47 |
| juice | does anyone know of resource for various api commands | 20:48 |
| hub_cap | for USERS | 20:48 |
| hub_cap | exactly imsplitbit | 20:48 |
| juice | like a digital copy of 7 databases in 7 weeks | 20:48 |
| imsplitbit | when I said users I meant "consumers of the api" | 20:48 |
| kevinconway | #topic users | 20:48 |
| imsplitbit | lol | 20:48 |
| SlickNik | lol | 20:48 |
| hub_cap | sorry kevinconway you dont have that power | 20:48 |
| grapex | kevinconway: LOL! | 20:48 |
| imsplitbit | /ban hub_cap | 20:48 |
| imsplitbit | lol | 20:48 |
| hub_cap | imsplitbit: even i dont have that power | 20:49 |
| hub_cap | i wouldve kicked u alreay | 20:49 |
| imsplitbit | fo rill | 20:49 |
| imsplitbit | ok lets keep talking about this | 20:49 |
| hub_cap | naw lets not | 20:49 |
| imsplitbit | maybe not today | 20:49 |
| hub_cap | lets thikn it out | 20:49 |
| hub_cap | lets discuss when we are gonna revisit | 20:49 |
| hub_cap | i want to tomorrow | 20:49 |
| imsplitbit | I just meant it's way too early to make a decision | 20:49 |
| hub_cap | cuz earthpiper is sitting twiddling his thumbs | 20:49 |
| earthpiper | imsplitbit: not its not. | 20:49 |
| imsplitbit | I would be disappointed if we ruled on this in just 50 minutes | 20:49 |
| earthpiper | it's simple | 20:49 |
| earthpiper | there is no other options really. | 20:50 |
| earthpiper | For some DB's | 20:50 |
| imsplitbit | earthpiper: it's simple to you because you see it your way | 20:50 |
| hub_cap | earthpiper: its not simple | 20:50 |
| hub_cap | +1 imsplitbit | 20:50 |
| vipul | yea I think we finally just got some context behind all this.. | 20:50 |
| hub_cap | its simple if youve been thinking about it for 2 wks | 20:50 |
| vipul | so need time | 20:50 |
| vipul | to absorbe | 20:50 |
| hub_cap | its not if you are vipul | 20:50 |
| earthpiper | Indeed my bad | 20:50 |
| imsplitbit | lol | 20:50 |
| hub_cap | and a member of the core team w/o context | 20:50 |
| imsplitbit | hub_cap: we have a crypto thing tomorrow | 20:50 |
| imsplitbit | can we schedule around that? | 20:50 |
| SlickNik | earthpiper: which is the first db service type that we're planning to try this with? | 20:51 |
| hub_cap | hmm i dont have a crypto thing tomrrow imsplitbit ;) | 20:51 |
| imsplitbit | some of us do | 20:51 |
| hub_cap | SlickNik: caché | 20:51 |
| vipul | tomorrow 2pst works for me | 20:51 |
| grapex | Some of us have pre-existing lives | 20:51 |
| earthpiper | SlickNik: I am working adding redis into trove. | 20:51 |
| earthpiper | on* | 20:51 |
| hub_cap | http://www.intersystems.com/cache/ | 20:51 |
| grapex | Or calendars that were arranged before we had a 24 hour deadline to argue what we wanted to do | 20:51 |
| imsplitbit | I can't do 2 pst | 20:51 |
| imsplitbit | ug | 20:51 |
| grapex | I have to go home midway through tomorrow to look after mine and my neighbors dogs | 20:52 |
| kevinconway | yeah, none of us CST guys are doing 2 pst | 20:52 |
| imsplitbit | earthpiper: I'd like to discuss this with you face to face behind the gym after school :) | 20:52 |
| grapex | So I'm not sure when I could get back on until about 1 pst | 20:52 |
| kevinconway | thats like… X;XX o'clock | 20:52 |
| hub_cap | ahh can u not do irc w/ the dogs grapex? understandable if not | 20:52 |
| hub_cap | id like you to participate | 20:52 |
| vipul | imsplitbit: lol | 20:52 |
| hub_cap | i want hte core team to agree | 20:52 |
| earthpiper | imsplitbit: you got bad knees dawg. | 20:52 |
| hub_cap | or ill jus tmake a decision | 20:52 |
| imsplitbit | earthpiper: and you can't run that fast :) | 20:53 |
| hub_cap | so i want vipul SlickNik grapex hub_cap to decide | 20:53 |
| grapex | hub_cap: I just don't want to pick a time when I'm in a meeting at Rax our in route | 20:53 |
| vipul | 11pst? | 20:53 |
| earthpiper | imsplitbit: I do like cake. | 20:53 |
| hub_cap | grapex: lol OF COURSE! | 20:53 |
| KennethWilke | punch and pie? | 20:53 |
| imsplitbit | seriously tho earthpiper come see me tomorrow morning I would love to have more insight | 20:53 |
| hub_cap | ok | 20:53 |
| grapex | vipul: I could try to get in place by 11pst | 20:53 |
| * hub_cap bangs the gavel | 20:53 | |
| hub_cap | everyone shut up | 20:53 |
| * imsplitbit shuts up | 20:53 | |
| hub_cap | we need to pick a time | 20:53 |
| KennethWilke | NOW | 20:53 |
| earthpiper | KennethWilke: +1 | 20:53 |
| kevinconway | i'm available at 7:15 CST | 20:53 |
| vipul | 11pst? | 20:53 |
| SlickNik | 11pst works for me. | 20:53 |
| * TheRealBill chuckles | 20:53 | |
| kevinconway | long bus ride to san antonio | 20:53 |
| vipul | dont' ask kevinconway | 20:53 |
| * grapex begins loudly speaking in tongues | 20:54 | |
| vipul | he comes up with crazy ass times | 20:54 |
| hub_cap | ok how bout this | 20:54 |
| imsplitbit | I'm ok with 11pst | 20:54 |
| hub_cap | ill just decide what i want | 20:54 |
| hub_cap | and be a dictator | 20:54 |
| *** KennethWilke has left #openstack-meeting-alt | 20:54 | |
| *** KennethWilke has joined #openstack-meeting-alt | 20:54 | |
| hub_cap | or we can be big boys and pick a time | 20:54 |
| kevinconway | might want to pus hot 11:30 pst so we can get out of lunch and get back to a station | 20:54 |
| imsplitbit | 11pst | 20:54 |
| KennethWilke | tomorrow anytime 7-4cst | 20:54 |
| imsplitbit | ok 1130 | 20:54 |
| grapex | It worked for agriculture in the Soviet Union... why not? | 20:54 |
| hub_cap | 1130 pst / 130 pst? | 20:55 |
| grapex | Sounds good | 20:55 |
| hub_cap | done | 20:55 |
| imsplitbit | 1:30 cst | 20:55 |
| vipul | okie | 20:55 |
| KennethWilke | k | 20:55 |
| kevinconway | #agree | 20:55 |
| SlickNik | okay, sounds good | 20:55 |
| datsun180b | oh 1:30 CST makes more sense | 20:55 |
| imsplitbit | #agree | 20:55 |
| robertmyers | #agree | 20:55 |
| imsplitbit | lol | 20:55 |
| datsun180b | #agree | 20:55 |
| * KennethWilke puts on his armor and tight pants | 20:55 | |
| KennethWilke | battle to the death! | 20:55 |
| imsplitbit | yeah two times in pst didn't make sense to me either datsun180b | 20:55 |
| hub_cap | lol | 20:55 |
| hub_cap | ok 5 min | 20:55 |
| imsplitbit | KennethWilke: Texas is a "Stand your ground" state | 20:56 |
| hub_cap | #topic open discussion | 20:56 |
| *** openstack changes topic to "open discussion (Meeting topic: trove)" | 20:56 | |
| imsplitbit | :) | 20:56 |
| hub_cap | anyoen have anything? | 20:56 |
| hub_cap | relevant | 20:56 |
| imsplitbit | awe | 20:56 |
| hub_cap | ya | 20:56 |
| hub_cap | this hour is monitored | 20:56 |
| SlickNik | hub_cap: so one thing that came up is the ability to tag / push to pypi | 20:56 |
| hub_cap | as in, we need to be big boys | 20:56 |
| *** jasonb365 has joined #openstack-meeting-alt | 20:56 | |
| kevinconway | i'd like to talk about users | 20:56 |
| hub_cap | cuz all of openstack is watching | 20:56 |
| hub_cap | kevinconway: do i need to reiterate? | 20:56 |
| imsplitbit | good point | 20:56 |
| hub_cap | cuz i can talk to your mgr | 20:56 |
| * hub_cap is serious | 20:56 | |
| grapex | hub_cap: Man they must be really bored! | 20:56 |
| hub_cap | we can goof off all day long in #openstack-trove but this is a real meeting | 20:57 |
| imsplitbit | yeah good point | 20:57 |
| hub_cap | SlickNik: yes lets chat | 20:57 |
| imsplitbit | anyone got anything | 20:57 |
| KennethWilke | hmm, i wish i had something else to bring up, but the api is my main concern atm | 20:57 |
| SlickNik | right now it's restricted to trove_ptl (which is a group that has only you) | 20:57 |
| hub_cap | SlickNik: had a good point | 20:57 |
| imsplitbit | oh | 20:57 |
| hub_cap | so apparently only i can push to pypi? | 20:57 |
| *** colinmcnamara has quit IRC | 20:58 | |
| hub_cap | can we change that to anyoen in core SlickNik? | 20:58 |
| SlickNik | Yeah, we can change this is we decide, but I wanted to run it by you guys first. | 20:58 |
| hub_cap | yes +1 | 20:58 |
| SlickNik | Yeah, it's a change in the ci-infra scripts | 20:58 |
| *** colinmcnamara has joined #openstack-meeting-alt | 20:58 | |
| hub_cap | i trust core | 20:58 |
| hub_cap | so i decree | 20:59 |
| vipul | <3 | 20:59 |
| hub_cap | change it SlickNik | 20:59 |
| SlickNik | grapex / vipul you guys okay with it? | 20:59 |
| vipul | SlickNik yep | 20:59 |
| *** jrodom has quit IRC | 20:59 | |
| grapex | SlickNik: Sounds good to me. | 20:59 |
| hub_cap | ok done and done | 20:59 |
| hub_cap | #action SlickNik to change the group for pypi upload | 20:59 |
| hub_cap | :) | 20:59 |
| SlickNik | thx hub_cap, was just about to action myself. | 21:00 |
| SlickNik | That's all I had | 21:00 |
| hub_cap | #endmeeting | 21:00 |
| *** openstack changes topic to "OpenStack meetings (alternate)" | 21:00 | |
| openstack | Meeting ended Wed Jul 24 21:00:13 2013 UTC. Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4) | 21:00 |
| openstack | Minutes: http://eavesdrop.openstack.org/meetings/trove/2013/trove.2013-07-24-20.00.html | 21:00 |
| openstack | Minutes (text): http://eavesdrop.openstack.org/meetings/trove/2013/trove.2013-07-24-20.00.txt | 21:00 |
| openstack | Log: http://eavesdrop.openstack.org/meetings/trove/2013/trove.2013-07-24-20.00.log.html | 21:00 |
| *** robertmyers has left #openstack-meeting-alt | 21:00 | |
| KennethWilke | ermahgerdbehr! | 21:00 |
| *** KennethWilke has left #openstack-meeting-alt | 21:00 | |
| *** TheRealBill has left #openstack-meeting-alt | 21:00 | |
| grapex | Peace | 21:01 |
| grapex | o> | 21:01 |
| grapex | ^^ Military Salute | 21:01 |
| hub_cap | o7 | 21:01 |
| datsun180b | o& | 21:01 |
| datsun180b | motorcycle accident | 21:01 |
| SlickNik | datsun180b: was just about to ask | 21:01 |
| grapex | datsun180b: ^^ Beachball riding a motorcycle | 21:03 |
| *** djohnstone has quit IRC | 21:03 | |
| *** markwash has quit IRC | 21:03 | |
| *** DandyPandy has left #openstack-meeting-alt | 21:04 | |
| *** markwash has joined #openstack-meeting-alt | 21:07 | |
| *** jmcbride has joined #openstack-meeting-alt | 21:18 | |
| *** jergerber has quit IRC | 21:18 | |
| *** zane has quit IRC | 21:19 | |
| *** jmcbride1 has quit IRC | 21:21 | |
| *** pcm_ has quit IRC | 21:21 | |
| *** jmcbride has quit IRC | 21:23 | |
| *** betsy_ has quit IRC | 21:27 | |
| *** jmcbride has joined #openstack-meeting-alt | 21:31 | |
| *** pdmars has quit IRC | 21:34 | |
| *** vipul is now known as vipul-away | 21:37 | |
| *** qwerty_nor has quit IRC | 21:39 | |
| *** qwerty_nor has joined #openstack-meeting-alt | 21:39 | |
| *** vipul-away is now known as vipul | 21:40 | |
| *** megan_w has quit IRC | 21:42 | |
| *** jmcbride1 has joined #openstack-meeting-alt | 21:42 | |
| *** jmcbride has quit IRC | 21:43 | |
| *** kevinconway has quit IRC | 21:57 | |
| *** datsun180b has quit IRC | 21:59 | |
| *** rnirmal has quit IRC | 22:14 | |
| *** lastidiot has quit IRC | 22:16 | |
| *** Riddhi has quit IRC | 22:16 | |
| *** lifeless has quit IRC | 22:26 | |
| *** lifeless has joined #openstack-meeting-alt | 22:35 | |
| *** jcru has quit IRC | 22:36 | |
| *** jmcbride1 has quit IRC | 22:53 | |
| *** jmontemayor has quit IRC | 22:58 | |
| *** colinmcnamara has quit IRC | 23:06 | |
| *** vipul is now known as vipul-away | 23:12 | |
| *** vipul-away is now known as vipul | 23:14 | |
| *** jrodom has joined #openstack-meeting-alt | 23:16 | |
| *** jasonb365 has quit IRC | 23:17 | |
| *** colinmcnamara has joined #openstack-meeting-alt | 23:20 | |
| *** lastidiot has joined #openstack-meeting-alt | 23:21 | |
| *** jrodom has quit IRC | 23:28 | |
| *** colinmcnamara has quit IRC | 23:49 | |
| *** jmcbride has joined #openstack-meeting-alt | 23:54 | |
| *** colinmcnamara has joined #openstack-meeting-alt | 23:58 | |
Generated by irclog2html.py 2.14.0 by Marius Gedminas - find it at mg.pov.lt!