| *** vipul is now known as vipul|away | 00:19 | |
| *** vipul|away is now known as vipul | 00:20 | |
| *** esp has joined #openstack-meeting-alt | 00:50 | |
| *** esp has quit IRC | 00:54 | |
| *** sacharya has joined #openstack-meeting-alt | 01:02 | |
| *** grapex has quit IRC | 01:25 | |
| *** esp1 has joined #openstack-meeting-alt | 01:45 | |
| *** vipul is now known as vipul|away | 01:49 | |
| *** vipul|away is now known as vipul | 01:50 | |
| *** demorris has joined #openstack-meeting-alt | 01:58 | |
| *** kagan has quit IRC | 02:08 | |
| *** demorris has quit IRC | 02:17 | |
| *** demorris has joined #openstack-meeting-alt | 02:17 | |
| *** cp16net is now known as cp16net|away | 02:39 | |
| *** sacharya1 has joined #openstack-meeting-alt | 02:44 | |
| *** sacharya has quit IRC | 02:47 | |
| *** grapex has joined #openstack-meeting-alt | 02:55 | |
| *** grapex has quit IRC | 02:57 | |
| *** grapex has joined #openstack-meeting-alt | 02:57 | |
| *** esp1 has left #openstack-meeting-alt | 02:58 | |
| *** demorris has quit IRC | 03:06 | |
| *** cp16net|away is now known as cp16net | 03:09 | |
| *** bdpayne has quit IRC | 03:11 | |
| *** imsplitbit has joined #openstack-meeting-alt | 03:23 | |
| *** demorris has joined #openstack-meeting-alt | 03:59 | |
| *** demorris has quit IRC | 04:00 | |
| *** demorris has joined #openstack-meeting-alt | 04:01 | |
| *** bdpayne has joined #openstack-meeting-alt | 04:10 | |
| *** bdpayne has quit IRC | 04:22 | |
| *** imsplitbit has quit IRC | 04:34 | |
| *** demorris has quit IRC | 04:35 | |
| *** sacharya1 has quit IRC | 06:10 | |
| *** SlickNik has left #openstack-meeting-alt | 06:33 | |
| *** grapex has quit IRC | 06:47 | |
| *** grapex has joined #openstack-meeting-alt | 06:48 | |
| *** grapex has quit IRC | 07:28 | |
| *** dhellmann-afk has quit IRC | 12:01 | |
| *** sacharya has joined #openstack-meeting-alt | 13:02 | |
| *** sacharya has quit IRC | 13:09 | |
| *** demorris has joined #openstack-meeting-alt | 13:38 | |
| *** sacharya has joined #openstack-meeting-alt | 13:48 | |
| *** imsplitbit has joined #openstack-meeting-alt | 14:15 | |
| *** dhellmann has joined #openstack-meeting-alt | 14:17 | |
| *** imsplitbit has quit IRC | 14:34 | |
| *** amyt has joined #openstack-meeting-alt | 14:53 | |
| *** amyt has quit IRC | 14:57 | |
| *** amyt has joined #openstack-meeting-alt | 14:58 | |
| *** jcru has joined #openstack-meeting-alt | 15:01 | |
| *** cloudchimp has joined #openstack-meeting-alt | 15:18 | |
| *** djohnstone has joined #openstack-meeting-alt | 15:22 | |
| *** rnirmal has joined #openstack-meeting-alt | 15:54 | |
| *** cp16net is now known as cp16net|away | 15:57 | |
| *** grapex has joined #openstack-meeting-alt | 16:14 | |
| *** grapex has quit IRC | 16:16 | |
| *** grapex has joined #openstack-meeting-alt | 16:17 | |
| *** dhellmann has quit IRC | 16:18 | |
| *** esp1 has joined #openstack-meeting-alt | 16:42 | |
| *** esp1 has left #openstack-meeting-alt | 16:42 | |
| *** esp1 has joined #openstack-meeting-alt | 17:15 | |
| *** dhellmann has joined #openstack-meeting-alt | 17:18 | |
| *** esp1 has left #openstack-meeting-alt | 17:23 | |
| *** demorris_ has joined #openstack-meeting-alt | 17:32 | |
| *** demorris_ has quit IRC | 17:33 | |
| *** demorris_ has joined #openstack-meeting-alt | 17:33 | |
| *** demorris has quit IRC | 17:36 | |
| *** demorris_ is now known as demorris | 17:36 | |
| *** jcru is now known as jcru|away | 17:45 | |
| *** amyt_ has joined #openstack-meeting-alt | 18:32 | |
| *** djohnstone has quit IRC | 18:32 | |
| *** amyt has quit IRC | 18:32 | |
| *** amyt_ is now known as amyt | 18:32 | |
| *** djohnstone1 has joined #openstack-meeting-alt | 18:32 | |
| *** edsrzf has joined #openstack-meeting-alt | 18:43 | |
| *** cppcabrera has joined #openstack-meeting-alt | 18:43 | |
| *** kagan has joined #openstack-meeting-alt | 18:51 | |
| *** bryan has joined #openstack-meeting-alt | 18:52 | |
| *** bryan is now known as bryansd | 18:52 | |
| *** jcru|away is now known as jcru | 18:55 | |
| *** jamie-rax has joined #openstack-meeting-alt | 18:56 | |
| *** ametts-atl has joined #openstack-meeting-alt | 19:02 | |
| *** kgriffs has joined #openstack-meeting-alt | 19:02 | |
| kgriffs | hey everyone | 19:04 |
|---|---|---|
| kgriffs | I've been under the weather this week, so if I sound a bit scatter-brained, that's my excuse. ;p | 19:05 |
| cppcabrera | Here's the Trello to help keep things organized: https://trello.com/board/openstack-marconi/511403287d138cd6200078e0 | 19:05 |
| kgriffs | Thanks. | 19:06 |
| kgriffs | #startmeeting marconi | 19:06 |
| openstack | Meeting started Thu Feb 21 19:06:34 2013 UTC. The chair is kgriffs. Information about MeetBot at http://wiki.debian.org/MeetBot. | 19:06 |
| openstack | Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. | 19:06 |
| *** openstack changes topic to " (Meeting topic: marconi)" | 19:06 | |
| openstack | The meeting name has been set to 'marconi' | 19:06 |
| kgriffs | #note Trello board - https://trello.com/board/openstack-marconi/511403287d138cd6200078e0 | 19:07 |
| kgriffs | #topic Dev kickoff | 19:07 |
| *** openstack changes topic to "Dev kickoff (Meeting topic: marconi)" | 19:07 | |
| kgriffs | So, first I just wanted to mention that earlier today I met with several Rackspace devs in Atlanta, as well as Flavio from Red Hat (via G+ Hangout) to kick off Marconi development. | 19:08 |
| kgriffs | So, the Trello board will be spruced up and populated with a bunch more stuff in the very near future. | 19:09 |
| cppcabrera | +1 | 19:09 |
| dhellmann | nice | 19:10 |
| kgriffs | Flavio is going to see if he can sweet-talk some of his fellow Red Hat devs to contributing at least part time. | 19:10 |
| cppcabrera | Is there a github repository available at this time? Initial commit, perhaps? | 19:10 |
| kgriffs | It sounds like he (Flavio/flaper87) will be able to contribute mostly full-time to the project, at least to help us get it off the ground. | 19:10 |
| kgriffs | Yes. | 19:10 |
| kgriffs | Scaffolding is there. | 19:11 |
| kgriffs | https://github.com/stackforge/marconi | 19:11 |
| cppcabrera | I'll add the link to the Trello board description. | 19:11 |
| kgriffs | No real code yet, but that will be arriving in the next few days. | 19:11 |
| *** Oz_Akan has joined #openstack-meeting-alt | 19:12 | |
| dhellmann | kgriffs: let me know when I can put you on the openstack-atlanta meetup talk schedule ;-) | 19:12 |
| kgriffs | Heh. :D | 19:12 |
| kgriffs | I definitely need to get involved. | 19:12 |
| kgriffs | #action kgriffs to stop being lazy and go to openstack-atlanta meetups. | 19:13 |
| dhellmann | haha | 19:14 |
| kgriffs | OK, so the plan for development is to track tasks in Trello. Later on we will probably leverage launchpad, at least for bugs. | 19:15 |
| dhellmann | kgriffs: there are several dreamhost devs here in atl, too, and we have an interest in marconi, so keep us in the loop | 19:15 |
| kgriffs | hey, sweet. | 19:15 |
| dhellmann | I may be able to commit some resources during H | 19:15 |
| cppcabrera | note: next OpenStack ATL meetup is tonight - Quantum is the focus. | 19:16 |
| *** cp16net|away is now known as cp16net | 19:16 | |
| dhellmann | cppcabrera: mark is tweaking his presentation now :-) | 19:17 |
| ametts-atl | Any Dreamhost devs close to Rackspace's Atlanta office near Gwinnett Arena? Ya'll should stop by for lunch or something. | 19:17 |
| dhellmann | ametts-atl: we meet in decatur, but could meet somewhere half way | 19:18 |
| dhellmann | let's arrange something offline, I didn't mean to derail the meeting | 19:19 |
| kgriffs | no worries. Will do | 19:19 |
| kgriffs | #action ametts-atl, dhellmann, kgriffs to arrange Metro ATL meetup | 19:20 |
| kgriffs | OK, one more thing on the topic of code | 19:20 |
| kgriffs | (a) We have an aggressive timeline | 19:21 |
| kgriffs | b. We can't compromise on quality | 19:21 |
| kgriffs | So, v1 needs to simple with great test coverage | 19:22 |
| kgriffs | re the timeline, we need to have something demo-able (not feature complete) for the summit. | 19:22 |
| *** imsplitbit has joined #openstack-meeting-alt | 19:22 | |
| kgriffs | ...but | 19:22 |
| cppcabrera | We need to define a CONTRIBUTORS file in the github. That'll help unify initial development. | 19:22 |
| kgriffs | good idea | 19:23 |
| kgriffs | #action kgriffs to add commited contributors to CONTRIBUTORS file | 19:23 |
| kgriffs | So, I need to redo the milestones on launchpad to reflect this | 19:24 |
| cppcabrera | Maybe a HACKING file, too. (style conventions, etc.) | 19:24 |
| kgriffs | #action kgriffs to update milestones | 19:24 |
| kgriffs | So, basically, for milestones we have: | 19:24 |
| ametts-atl | How about (c) simple start should lay an extensible foundation for everything else to come later on | 19:24 |
| kgriffs | yes | 19:25 |
| kgriffs | we need a good foundation that is flexible enough to accomodate the stuff on the "future features" list on the spec (or at least a good number of them) | 19:25 |
| kgriffs | See also: https://wiki.openstack.org/wiki/Marconi/specs/grizzly | 19:26 |
| kgriffs | But it also needs to be functional enough that it can be used by real apps and services. | 19:26 |
| kgriffs | #topic Milestones | 19:27 |
| *** openstack changes topic to "Milestones (Meeting topic: marconi)" | 19:27 | |
| *** david4 has joined #openstack-meeting-alt | 19:28 | |
| kgriffs | m1 - Demo at Portland Summit (Ready to go by the prev. Thursday, April 11) | 19:28 |
| kgriffs | #note m1 - Demo at Portland Summit (Ready to go by the prev. Thursday, April 11) | 19:28 |
| kgriffs | #note Also hoping to conduct some feedback sessions on the API and architecture during the summit | 19:29 |
| ametts-atl | #link http://www.openstack.org/summit/portland-2013/vote-for-speakers/presentation/647 | 19:29 |
| ametts-atl | We need everyone to vote for this session -- so we'll actually have a forum to conduct the demo! | 19:30 |
| kgriffs | +1 | 19:30 |
| kgriffs | #note m2 - Feature Complete by mid-may (May 13) | 19:30 |
| kgriffs | #note m3 - Production Ready in the summer (June/July) | 19:31 |
| kgriffs | Queuing is a big gaping whole in the OpenStack portfolio, so we need to ship something to the community in the next 6 months. | 19:32 |
| dhellmann | ametts-atl: there are also open space rooms | 19:32 |
| kgriffs | That will then set us up nicely for the fall summit when we can discuss the next batch of features | 19:33 |
| ametts-atl | dhellman: Yeah, but vote for this session anyway. This will be our chance to really start building Marconi momentum in OpenStack. :) | 19:33 |
| kgriffs | whole => hole. :p | 19:33 |
| dhellmann | ametts-atl: of course! :-) | 19:33 |
| kgriffs | OK, so anything else for general discussion before we move on to API? | 19:34 |
| kgriffs | #topic API - Claim Messages | 19:35 |
| *** openstack changes topic to "API - Claim Messages (Meeting topic: marconi)" | 19:35 | |
| kgriffs | #note Etherpad for API draft - https://etherpad.openstack.org/queuing-api | 19:36 |
| kgriffs | Scroll down to "Claim Messages" | 19:36 |
| kgriffs | (about 3/4 way to the bottom) | 19:36 |
| cppcabrera | Ctrl + F works well, too. | 19:37 |
| kgriffs | So, the original proposal is still there, But I added (in green) | 19:37 |
| kgriffs | heh | 19:37 |
| kgriffs | Sometimes Etherpad doesn't like Ctrl + F, but if it works, awesome. | 19:37 |
| kgriffs | anyway... | 19:38 |
| kgriffs | Highlighted in green, you can see the proposed change to using POST and defining a "claims" resource. | 19:38 |
| dhellmann | +1 | 19:39 |
| kgriffs | OK, so any major objections to going with this approach? I like it better than trying to PATCH or POST against the "messages" collection - seems more natural and RESTy | 19:40 |
| kgriffs | Is the document structure OK as-is? | 19:42 |
| kgriffs | (shown in the draft as JSON) | 19:42 |
| cppcabrera | LGTM | 19:42 |
| dhellmann | one comment on renewal: | 19:42 |
| dhellmann | I'm not sure why a separate claim id couldn't be generated for each message | 19:43 |
| kgriffs | OK, let's move on to that | 19:43 |
| dhellmann | (that's listed as a downside in the new section on the POST call) | 19:43 |
| kgriffs | It could be. | 19:43 |
| dhellmann | using a separate claim id for each message, or having the claim id and message id be a 2 part key would allow renewing a claim on a single message at a time | 19:43 |
| dhellmann | actually, I like the latter. patch the claim with a timeout and optionally include a list of the messages you want? the others are not renewed. | 19:44 |
| kgriffs | So, if we did that, it would be a side-effect of creating a claim | 19:44 |
| dhellmann | or is that too complicated? | 19:44 |
| dhellmann | side-effect? | 19:45 |
| kgriffs | may be too complicated | 19:45 |
| dhellmann | ok, keep it simple this time around | 19:45 |
| kgriffs | well, I was just thinking that workers can always claim smaller batches of messages in order to mitigate the problem of a big block getting held up for too long. | 19:47 |
| dhellmann | kgriffs: true | 19:48 |
| kgriffs | A claim could include separate id's for each message, allowing them to be renewed independently, but maybe it's not worth the complexity. | 19:48 |
| ametts-atl | Is there any reason to un-claim a message before the timeout expires? | 19:49 |
| *** carimura has joined #openstack-meeting-alt | 19:49 | |
| ametts-atl | As in "I took 100 messages, but I'm not compatible with request #44, so I'm un-claiming it". | 19:49 |
| dhellmann | ametts-atl: I would think the client would have a way to subscribe so it only saw messages it should (something like ampq topics?) | 19:50 |
| kgriffs | Yeah, that could be handled by using multiple queues and/or tags (the latter if proposed as a post-v1.0 feature) | 19:51 |
| ametts-atl | Ok - I don't disagree. Just throwing it out there in case it was a rationale for separate ids? | 19:51 |
| dhellmann | ametts-atl: a better case is, I claimed 100 but am being told to shut down so I want to release my claim on the ones I haven't finished with | 19:52 |
| kgriffs | If you really needed to do something like that, you could skip the message, process and DELETE all the ones you can, and at the end, release the claim so the skipped messages go back into the pool | 19:52 |
| dhellmann | kgriffs: that sounds like it takes care of the use case I just described | 19:53 |
| kgriffs | yeah | 19:53 |
| kgriffs | I just added a note to etherpad. I think it gets us most of the way there. | 19:54 |
| kgriffs | So, that strategy combined with claiming messages in small-ish batches should alleviate the need to renew claims on a per-message basis. | 19:55 |
| dhellmann | yes | 19:55 |
| kgriffs | It's also nice, because i probably want to do batch renewals regardless | 19:55 |
| kgriffs | OK, well, let's run with that and see what kind of trouble it gets us into. :D | 19:56 |
| cppcabrera | Agreed regarding batching. A message at a time is probably too chatty. :P | 19:56 |
| kgriffs | Anything else before we move on? | 19:57 |
| kgriffs | I think releasing and querying claims are pretty straightforward | 19:58 |
| kgriffs | I'd like to touch on renewing a claim, though. | 19:58 |
| kgriffs | #topic API - Renew a Claim | 19:59 |
| *** openstack changes topic to "API - Renew a Claim (Meeting topic: marconi)" | 19:59 | |
| kgriffs | So, personally, I'm leaning towards using PUT | 19:59 |
| cppcabrera | Hmmm... would that imply a worst case 64KB PUT? | 20:01 |
| kgriffs | no, you are just setting the ttl for the claim | 20:02 |
| cppcabrera | Ah,, I see. | 20:02 |
| cppcabrera | +1 for PUT. Looks simpler. | 20:02 |
| kgriffs | However, it isn't quite right because PUT can imply that you are creating the claim, when really we want to update an existing claim. I guess we could allow the client to generate the claim ID and just get rid of the separate POST method | 20:03 |
| kgriffs | (…imply creating OR updating) | 20:04 |
| *** vipul is now known as vipul|away | 20:04 | |
| dhellmann | kgriffs: I think the server really ought to generate the claim id | 20:04 |
| kgriffs | PATCH is fun, but also strange because you are resetting age, even though age is a dynamic value based on diff between create time and server time | 20:04 |
| dhellmann | otherwise you have to deal with duplicates | 20:04 |
| kgriffs | #agreed server should generate IDs | 20:05 |
| dhellmann | why isn't post the right verb? | 20:05 |
| dhellmann | post a new age to the claim | 20:05 |
| dhellmann | or not age, but timeout? | 20:06 |
| bryansd | I think you could make the same argument against PATCH, against PUT as well | 20:08 |
| kgriffs | I know that it is common to use POST in APIs when PATCH is really what is meant - json-patch is an attempt to to clear that up | 20:08 |
| cppcabrera | Renew claim sounds to me like a modifying operation, which feels closest to the semantics of PUT, imho. | 20:08 |
| dhellmann | kgriffs: patch makes sense, too, I thought we were looking for an alternative | 20:09 |
| dhellmann | patch is saying "change this attribute you're storing to this value" | 20:09 |
| dhellmann | post is saying "update the attribute based on some algorithm and this input I'm providing" | 20:09 |
| dhellmann | IOW, patch seems like setattr() vs. a method call | 20:10 |
| kgriffs | (where the algorithm is not uniform across services) | 20:10 |
| dhellmann | kgriffs: right | 20:10 |
| cppcabrera | dhellmann: I can definitely see patch as setattr. Nice comparison. | 20:10 |
| dhellmann | so in a patch the client controls the new value precisely, but in a post the server is in control | 20:11 |
| dhellmann | which is the case for updating the ttl? | 20:11 |
| *** jamie-rax has quit IRC | 20:11 | |
| kgriffs | well, it isn't updating the ttl | 20:11 |
| kgriffs | that stays at 30 seconds, say | 20:11 |
| kgriffs | I guess you could change it | 20:11 |
| kgriffs | actually, you probably should be able to | 20:11 |
| dhellmann | sorry, not ttl, but expiration | 20:11 |
| dhellmann | does the client get to pick a precise time, or does it ask for an extension of a certain length, or just an extension without specifying a length? | 20:12 |
| kgriffs | I think we need a way to update ttl and expiration | 20:12 |
| kgriffs | good question | 20:12 |
| dhellmann | kgriffs: ttl feels like a property of the queue, rather than the claim, no? | 20:12 |
| kgriffs | hmmm. | 20:12 |
| *** atljamie has joined #openstack-meeting-alt | 20:13 | |
| kgriffs | Well, I kinda like being able to reset the expiration and set a different TTL if it's taking me a while to process a certain batch for some reason. | 20:13 |
| dhellmann | do claims have ttls or just expirations? (and if both, what's the difference?) | 20:13 |
| kgriffs | so, ttl is like "30 seconds from the time the claim was created or last renewed" | 20:14 |
| dhellmann | what happens at that time? | 20:14 |
| dhellmann | the claim is expired? | 20:14 |
| kgriffs | the claim expires and is automatically released | 20:14 |
| dhellmann | ok | 20:14 |
| dhellmann | and an expiration is the exact time at which that should occur? | 20:14 |
| dhellmann | or is it all controlled via the ttl? | 20:15 |
| kgriffs | maybe not exact, but within, say, a few seconds. | 20:15 |
| dhellmann | well, yeah, but it's a timestamp rather than a # of seconds | 20:15 |
| kgriffs | So, I imagine in the backend there will be some kind of garbage collector that runs periodically and removes expired claims | 20:15 |
| kgriffs | so, a claim has a "create" or "renewed at" timestamp, plus a ttl | 20:15 |
| kgriffs | so, ts + ttl = expiration time | 20:15 |
| dhellmann | got it | 20:16 |
| dhellmann | so the ttl is the life of the claim and the expiration time is updated when the renewal comes in by taking the current time and adding the ttl | 20:16 |
| dhellmann | so it feels like you want to be able to change the ttl value at the same time as doing a renewal, but it doesn't make sense to change the ttl without doing a renewal | 20:17 |
| kgriffs | right, I think that makes sense | 20:17 |
| dhellmann | that says to me ttl may be an optional argument to the rewnewal call, rather than a patch of the claim itself | 20:17 |
| kgriffs | I like PUT because it says, "overwrite this existing claim with a new one and this new ttl" | 20:18 |
| dhellmann | doesn't the claim also include the associated messages, though? | 20:18 |
| kgriffs | Well, that's where things get gray | 20:18 |
| dhellmann | you aren't replacing those in the PUT, so you're not providing a whole new version of the claim | 20:18 |
| kgriffs | Conceptually, a claim isn't a container or parent of messages | 20:19 |
| dhellmann | hmm | 20:19 |
| kgriffs | well, at least, that is the way we would have to spin it | 20:19 |
| kgriffs | normalized | 20:19 |
| dhellmann | the messages aren't in the queue at that point any more, so if they don't live in the claim where do they live? | 20:19 |
| kgriffs | so, a claim is ticket with a list of message IDs written on it | 20:20 |
| dhellmann | ok | 20:20 |
| kgriffs | they are in the queue; in fact, if an observer wanted to GET them, it could. | 20:20 |
| dhellmann | ah, ok, that wasn't clear | 20:20 |
| kgriffs | the idea is that in a work-queuing scenario, all the clients are well-behaved and get their messages only by creating claims, and always include claim IDs when deleting messages. | 20:21 |
| kgriffs | it's more of a unified concept than the disjoint one you have with SQS and SNS | 20:21 |
| dhellmann | ok | 20:21 |
| kgriffs | The nice thing is that it allows you to audit/debug what is going on by running one or more observers. | 20:22 |
| dhellmann | so if you put a claim to renew it, does that imply you can update the message id list for the claim at the same time? | 20:22 |
| dhellmann | kgriffs: sure, that makes sense | 20:22 |
| kgriffs | dhellmann: good point. Maybe PATCH is better after all because it is more specific? | 20:23 |
| kgriffs | actually, wait a sec. | 20:23 |
| kgriffs | that's an interesting thought | 20:23 |
| kgriffs | if I could update the list of messages, then I could allow ones I could release ones that I want to skip. | 20:24 |
| dhellmann | I still feel like this renewal is a POST, since the client isn't actually setting the value of the expiration time, just asking to have it updated. | 20:24 |
| dhellmann | kgriffs: yeah, you just rejected that idea a few minutes ago :-) | 20:24 |
| kgriffs | :p | 20:25 |
| dhellmann | only as a complex api, so I took that to mean maybe in a later version | 20:25 |
| cppcabrera | I'm out, guys. I have another metting in 3 minutes. TTL expired. ;) | 20:27 |
| kgriffs | heh | 20:27 |
| dhellmann | heh | 20:27 |
| cppcabrera | *meeting | 20:27 |
| kgriffs | no worries | 20:28 |
| kgriffs | we are running long this time | 20:28 |
| kgriffs | #note json-patch supports removing specific fields | 20:29 |
| kgriffs | PUT is like all-or-nothing, right? Basically, the client gives the entire entity that should replace the existing one? | 20:30 |
| dhellmann | kgriffs: yes, that's my understanding | 20:30 |
| atljamie | Mine too. | 20:30 |
| bryansd | #agreed | 20:30 |
| kgriffs | So, you would have to give the entire list of associated messages. | 20:31 |
| dhellmann | kgriffs: right | 20:32 |
| kgriffs | I guess it would have to be just their IDs to reduce traffic | 20:32 |
| dhellmann | true | 20:32 |
| kgriffs | but then, that doesn't match what the result of a POST gives back, which is the full messages. We might change that to a just a list of IDs, and then the client would have to request each message body in separate requests. | 20:33 |
| kgriffs | Not exactly efficient. | 20:33 |
| dhellmann | yeah, this is why PUT for renewal feels wrong :-) | 20:33 |
| kgriffs | OK, let's look at PATCH for a minute | 20:35 |
| kgriffs | Say that a claim entity is represented something like this (I'll put it into etherpad) | 20:35 |
| bryansd | I'm liking this json-patch draft. Looks like the "remove" operation is great for removing messages I want to release my claim on, and the "replace" operation would be great for resetting a claim's age to 0. | 20:36 |
| kgriffs | you could also optionally replace the ttl | 20:36 |
| kgriffs | { | 20:37 |
| kgriffs | "messages": { | 20:37 |
| kgriffs | "message-id-foo": { | 20:37 |
| kgriffs | ... | 20:37 |
| kgriffs | } | 20:37 |
| kgriffs | } | 20:37 |
| kgriffs | } | 20:37 |
| kgriffs | so, if you remove "/messages/message-id-foo" that would do the trick | 20:37 |
| bryansd | exactly | 20:37 |
| kgriffs | if messages is a list, I don't think the remove operation works | 20:38 |
| * kgriffs is pulling up the json-patch spec | 20:38 | |
| dhellmann | using a hash to return the messages in the claim will lose the ordering, won't it? | 20:38 |
| kgriffs | ah, that is a good point | 20:39 |
| kgriffs | I suppose you could still order them (roughly) by timestamp | 20:39 |
| dhellmann | making the client order them seems, … rude? | 20:40 |
| dhellmann | :-)( | 20:40 |
| kgriffs | yes, although I don't think we are going to support guaranteed ordering anyway, just that you won't get duplicates. | 20:41 |
| dhellmann | ah, ok | 20:41 |
| dhellmann | hmm | 20:41 |
| dhellmann | why not ordering? | 20:41 |
| dhellmann | it's not really a queue if order isn't ensured, is it? | 20:42 |
| kgriffs | Still under discussion… it could be done, but adds complexity in terms of how to scale-out individual queues. | 20:42 |
| dhellmann | we're at almost 1:45, should we carry over to next week? | 20:42 |
| kgriffs | well, SQS doesn't guarantee it | 20:42 |
| kgriffs | yeah, I think we will have to | 20:43 |
| dhellmann | this was a good discussion, thanks! | 20:43 |
| kgriffs | thanks everyone for your time | 20:44 |
| kgriffs | I think once we figure out claims the remaining bits of the API draft will be pretty smooth sailing | 20:44 |
| dhellmann | +1 | 20:45 |
| bryansd | cool | 20:45 |
| *** atljamie has quit IRC | 20:46 | |
| kgriffs | OK, so everyone go sleep on that and think about whether we need guaranteed ordering, or if best-effort is good enough (where most of the time things are ordered) | 20:46 |
| dhellmann | :-) | 20:47 |
| kgriffs | I will say that with guaranteed ordering you can't scale a single queue horizontally, but maybe that's OK. | 20:47 |
| kgriffs | cheers | 20:47 |
| kgriffs | #endmeeting | 20:47 |
| *** openstack changes topic to "OpenStack meetings (alternate) || Development in #openstack-dev || Help in #openstack" | 20:47 | |
| openstack | Meeting ended Thu Feb 21 20:47:42 2013 UTC. Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4) | 20:47 |
| openstack | Minutes: http://eavesdrop.openstack.org/meetings/marconi/2013/marconi.2013-02-21-19.06.html | 20:47 |
| openstack | Minutes (text): http://eavesdrop.openstack.org/meetings/marconi/2013/marconi.2013-02-21-19.06.txt | 20:47 |
| openstack | Log: http://eavesdrop.openstack.org/meetings/marconi/2013/marconi.2013-02-21-19.06.log.html | 20:47 |
| *** bryansd has left #openstack-meeting-alt | 20:53 | |
| *** vipul|away is now known as vipul | 20:55 | |
| *** ametts-atl has left #openstack-meeting-alt | 20:56 | |
| *** bdpayne has joined #openstack-meeting-alt | 20:57 | |
| *** carimura has quit IRC | 21:03 | |
| *** vipul is now known as vipul|away | 21:10 | |
| *** jcru is now known as jcru|away | 21:10 | |
| *** jcru|away is now known as jcru | 21:16 | |
| *** vipul|away is now known as vipul | 21:36 | |
| *** vipul is now known as vipul|away | 21:37 | |
| *** vipul|away is now known as vipul | 21:37 | |
| *** cp16net is now known as cp16net|away | 21:46 | |
| *** vipul is now known as vipul|away | 21:52 | |
| *** cp16net|away is now known as cp16net | 21:53 | |
| *** david4 has quit IRC | 21:56 | |
| *** dhellmann has quit IRC | 22:03 | |
| *** dhellmann has joined #openstack-meeting-alt | 22:04 | |
| *** Oz_Akan has quit IRC | 22:06 | |
| *** cppcabrera has left #openstack-meeting-alt | 22:11 | |
| *** grapex has quit IRC | 22:24 | |
| *** dhellmann has quit IRC | 22:31 | |
| *** grapex has joined #openstack-meeting-alt | 22:38 | |
| *** djohnstone1 has quit IRC | 22:54 | |
| *** vipul|away is now known as vipul | 23:02 | |
| *** imsplitbit has quit IRC | 23:09 | |
| *** amyt_ has joined #openstack-meeting-alt | 23:10 | |
| *** amyt has quit IRC | 23:14 | |
| *** amyt_ is now known as amyt | 23:14 | |
| *** jcru is now known as jcru|away | 23:20 | |
| *** jcru|away is now known as jcru | 23:28 | |
| *** sacharya has quit IRC | 23:35 | |
| *** kgriffs has quit IRC | 23:39 | |
| *** cloudchimp has quit IRC | 23:40 | |
| *** demorris has quit IRC | 23:40 | |
| *** rnirmal has quit IRC | 23:41 | |
Generated by irclog2html.py 2.14.0 by Marius Gedminas - find it at mg.pov.lt!