15:01:41 <flaper87> #startmeeting Marconi
15:01:42 <openstack> Meeting started Tue Apr  8 15:01:41 2014 UTC and is due to finish in 60 minutes.  The chair is flaper87. Information about MeetBot at http://wiki.debian.org/MeetBot.
15:01:43 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
15:01:45 <openstack> The meeting name has been set to 'marconi'
15:01:56 <flaper87> stupid but, it ain't infer the meeting name from the noise we make
15:02:04 <sriram> hah
15:02:04 <flaper87> argh, type systems to the rescue
15:02:05 <sriram> o/
15:02:10 <flaper87> What's up guys ?
15:02:15 <flaper87> #topic roll call
15:02:22 <flaper87> \o/
15:02:29 <flaper87> gungts gungts gungts gungts
15:02:38 <flaper87> alcabrera: malini sriram Obulpathi  ?
15:02:40 <sriram> o/ o/ o/
15:02:42 <flaper87> >.>
15:02:43 <Obulpathi> yep ..
15:02:43 <malini> o/
15:02:45 <Obulpathi> Ii am here
15:02:46 <alcabrera> <      3
15:02:53 <malini> kgriffs is in a shuttle with no wifi
15:03:02 <malini> & wanted us to move the meeting if possible
15:03:14 <flaper87> #topic What to do with kgriffs
15:03:25 <alcabrera> upgrade him
15:03:28 <flwang> o/
15:03:30 <flaper87> I say we tie him to his chair where he has enough internet access
15:03:31 <alcabrera> that fixes everything
15:03:33 <malini> clone him ?
15:03:38 <flaper87> we leave him there and that's it
15:03:38 <alcabrera> malini: +1
15:03:49 <alcabrera> HA kgriffs|afk v2.1.5 is the latest
15:03:49 <flaper87> malini: and what? Have 2 of them ?
15:03:54 <flaper87> ough, I'm now scared
15:04:10 <cpallares> lol @ meeting topic
15:04:11 <malini> I didnt know they put the scare chip on flaper87
15:04:33 <flaper87> malini: for robots scare == "Loaded Guns"
15:04:51 <alcabrera> fear not the catapult, for it leads to great heights
15:04:54 <sriram> robotic world domination..and it begins
15:05:00 <flaper87> it's just a way to make humans understand that anything could happen when a robot is in that state
15:05:15 <flaper87> kgriffs will read the best meeting logs EVER!
15:05:28 <flwang> :-D
15:05:38 <alcabrera> hahaha
15:05:45 <flaper87> anyway, lets see what we can discuss now and then we can call the meeting off until he is around
15:05:50 <alcabrera> sounds good to me
15:05:51 <flaper87> I know he wanted to share some things
15:05:57 <flaper87> I won't be around after 18:30 my time
15:05:59 <Obulpathi> sounds good
15:06:06 <sriram> cool
15:06:12 <flaper87> #topic stop talking about kgriffs, Get back to business
15:06:17 <alcabrera> #link https://wiki.openstack.org/wiki/Meetings/Marconi#Agenda
15:06:19 <flaper87> #link https://wiki.openstack.org/wiki/Meetings/Marconi
15:06:21 <alcabrera> there's business
15:06:23 <alcabrera> twice
15:06:24 <flaper87> damn, you're so fast
15:06:27 <flaper87> :P
15:06:30 <alcabrera> ;)
15:06:39 <flaper87> (you can figure who's chairing the meeting from the topics)
15:06:43 <flaper87> anyway, moving forward
15:06:48 <alcabrera> (so true)
15:06:59 <alcabrera> so, Juno priorities
15:06:59 <flaper87> #link http://eavesdrop.openstack.org/meetings/marconi/2014/marconi.2014-04-01-15.01.html
15:07:02 <alcabrera> oh
15:07:04 <alcabrera> actions
15:07:06 <alcabrera> yes
15:07:09 <flaper87> wait, you ain't going to skip the last week actions
15:07:14 <alcabrera> haha
15:07:16 * alcabrera tried, failed
15:07:18 <flaper87> erm, 2 actions on me, lets skip this
15:07:21 <flaper87> :P
15:07:33 * alcabrera tried again, succeeded
15:07:40 <flaper87> so, FAQ hangout: Checked
15:07:49 <flaper87> Sending the invite to the list: TotalFailure
15:08:06 <alcabrera> ah well
15:08:06 <flaper87> malini: any news w.r.t Trusty and the gate ?
15:08:08 <alcabrera> next time
15:08:27 <malini> flaper87: Trusty doesnt come out till April 17, rt?
15:08:42 <alcabrera> that's right
15:08:48 <alcabrera> we'll have to wait a bit more
15:08:50 <flaper87> #info Trusty lands on earth on April 17th
15:09:10 <flaper87> #question Will it be trustworthy ?
15:09:15 <flaper87> ok, bad joke and that tag doesn't exist
15:09:19 <flaper87> moving forward
15:09:22 <malini> :D
15:09:27 <flaper87> #topic Juno priorities
15:09:34 <flaper87> #link https://etherpad.openstack.org/p/marconi-juno-priorities
15:09:43 * flaper87 tries to parse that etherpad
15:10:07 <flaper87> Lets all read it very quickly and see if it makes sense
15:10:14 * alcabrera begins scan
15:10:25 <flaper87> and there goes malini, always thinking about tests
15:10:29 <malini> :D
15:10:54 <alcabrera> so far
15:10:57 <alcabrera> I'm pretty happy with it
15:11:00 <alcabrera> except
15:11:03 <sriram> what do the KPIs mean? in the etherpad?
15:11:08 <alcabrera> "Efficiency improvements of stock drivers by X%"
15:11:13 <alcabrera> I'm glad that's mark as a maybe
15:11:26 <alcabrera> sriram: key perf indicators
15:11:30 <flwang> sriram: I think it's for new health endpoint
15:11:36 <malini> sriram: Key Perf Indices
15:11:41 <flwang> alcabrera: am I right?
15:11:53 <alcabrera> flwang: yes, and possibly for new X/stats endpoints
15:11:54 <sriram> flaper87,malini: Oh thanks.
15:12:04 <flaper87> I'm not sure about the message pack stuff
15:12:14 <flaper87> that's kind of "underground-priority" for me
15:12:15 <alcabrera> flaper87: that's a maybe for me, too
15:12:26 <alcabrera> see...
15:12:29 <flaper87> ok
15:12:31 <alcabrera> we'd be juggling API v1.1 +
15:12:37 <flaper87> indeed
15:12:38 <alcabrera> adding support for smart content-type handling
15:12:43 <alcabrera> not an easy refactoring there
15:12:58 <flaper87> security test-suite
15:13:03 <flaper87> mmh, interesting
15:13:12 <flaper87> not sure how important during Juno, though
15:13:16 <malini> We should try to recruit some OSSG folks
15:13:36 <alcabrera> I'd like to know what that means: what are we guarding against? Are we also going to monitor our logging to make sure no sensitive data goes out?
15:13:39 <alcabrera> malini: +1
15:13:55 <flaper87> alcabrera: re logging, yeah!
15:13:55 <alcabrera> e.g., security unit tests for info leaks?
15:14:13 <flaper87> I read that as: Have a test suite that does really simple Pen Test on the API
15:14:21 <flaper87> but that's kinda a full-time job
15:14:28 <malini> we really need somebody in OSSG to tell us what will be acceptable
15:14:31 <alcabrera> it really is. :P
15:14:35 <flaper87> anyway, we can figure that out later!
15:14:35 <malini> flaper87: it is
15:14:52 <flaper87> #info hire kgriffs to work on the security test-suite
15:15:48 <flaper87> The only thing I love when kgriffs is not around is that I can assign random things to him :P
15:15:53 <flaper87> wait, I do that when he's around too
15:15:57 <flaper87> anyway, moving forward
15:16:00 <alcabrera> w00t
15:16:01 <alcabrera> yup
15:16:01 <flaper87> Any comments folks?
15:16:05 <alcabrera> hmmm
15:16:07 <alcabrera> one more look
15:16:13 <flaper87> If any, don't make them!
15:16:20 <flaper87> just kidding, add them to the etherpad
15:16:22 <flwang> flaper87: do you think we need some effort for common openstack client?
15:16:28 <flaper87> we'll have to iterate on those again
15:16:35 <flaper87> flwang: I'm working on that already
15:16:39 <alcabrera> k, I'm all good to continue
15:16:50 <flaper87> However, I'd like to keep client things separate from the server side things
15:16:54 <sriram> The list looks good to me.
15:16:56 <flwang> flaper87: you don't mention that never, cooooooooooooooool
15:17:00 <flaper87> since the client doesn't quite follow the server release cycle
15:17:15 <flaper87> flwang: I did mention it: $ openstack queue create YOYOY
15:17:17 <flaper87> remember ?
15:17:18 <flwang> flaper87: got it
15:17:20 <flaper87> :P
15:17:30 <flaper87> ok, moving forward for real :D
15:17:41 <flaper87> #topic v1.1 proposed changes
15:17:55 <flaper87> #topic pop tarts
15:17:57 <flaper87> erm, I mean
15:18:03 <flaper87> #topic pop semantics
15:18:35 * malini eager to learn more on tht
15:18:45 <flaper87> I'm not sure what kgriffs|afk wanted to discuss here but I think we could start brainstorming a bit about the semantics of this
15:19:00 <flaper87> malini: you're assigned to that blueprint, right ?
15:19:05 <malini> yes
15:19:08 <flaper87> awesome
15:19:18 <flaper87> #info malini will implement the pop endpoint
15:19:22 <alcabrera> hurray!
15:19:28 <flwang> haha
15:19:30 <malini> But I would love us to discuss how it should look
15:19:33 <flaper87> if I don't see tarts comming out of the pop endpoints, I'll get REALLY MAD!
15:19:39 <malini> :D
15:19:54 <flwang> flaper87: +2
15:19:56 <flaper87> malini: so, the whole idea is to "pop" messages out of a queue
15:20:07 <flaper87> The pop endpoint will work pretty much like the get endpoint
15:20:08 <malini> yes..claim + delete in one
15:20:16 <flaper87> the biggest difference is that it deletes the message
15:20:23 <flaper87> yeah
15:20:32 <flaper87> claim.limit(1).delete()
15:20:43 <flwang> flaper87: and I remembered on key discussion point is if we need a new endpoint for that
15:20:58 <malini> I thought we did not want a new endpoint
15:20:59 <flwang> on/one
15:21:21 <flaper87> Didn't we?
15:21:25 * flaper87 forgot about that
15:21:38 * flaper87 gets the blueprint
15:21:46 <malini> IIRC we want it be a param in an existing endpoint
15:21:54 <flaper87> not helpful (the blueprint)
15:21:55 * alcabrera looks at the spec
15:21:58 <flaper87> #link https://blueprints.launchpad.net/marconi/+spec/api-v1.1-pop-operation
15:22:14 <alcabrera> currently: DELETE /v1.1/queues/{queue_name}/messages{?ids,pop}
15:22:20 <alcabrera> it's a WIP
15:22:40 <alcabrera> we still haven't reached consensus as to how to make it fit in the API
15:22:42 <malini> alcabrera: where is the spec ?
15:22:45 <flaper87> oook, so I guess there's a GET ...../id{?pop}
15:22:50 <sriram> I thought we were leaning towards having it in an existing endpoint. I thought it was documented by kgriffs somewhere
15:23:09 <flaper87> I'm not fully against this *but* i think it'll make implementing other transports more difficult
15:23:24 <flaper87> Also, I read `pop` as a *command*
15:23:25 <alcabrera> the lates I have
15:23:27 <alcabrera> is
15:23:29 <alcabrera> #link https://wiki.openstack.org/wiki/Marconi/specs/api/v1.1#Delete_Multiple_Messages
15:23:45 <flwang> flaper87: yep, it's most like an action
15:23:52 <flaper87> otherwise it should probably be: GET .../id{?delete}
15:23:52 <malini> hmm..from the link it is not a 'single message' pop
15:23:53 <flwang> instead of a parameter
15:24:34 <malini> flaper87: why is it a GET & not a POST ?
15:24:59 <flaper87> because it wouldn't be posting anything in the queue but rather getting things from the queue
15:25:03 <alcabrera> it should be a POST, since it modifies state
15:25:09 <alcabrera> GETs are idempotent
15:25:09 <flaper87> mmmh
15:25:12 <alcabrera> pops delete
15:25:13 <malini> hmm..but since we delete after the GET, tht will be weird
15:25:30 <flaper87> see, another good reason to make it a separate endpoint
15:25:46 <alcabrera> I'm very favorable towards an alt-endpoint
15:25:47 <flaper87> Do we support limit on deletes?
15:25:55 <flaper87> AH wait, now I get that DELETE thing
15:26:10 <malini> flaper87: we need to give the ID on delete
15:26:14 <malini> so tht wont work
15:26:21 <flaper87> I guess kgriffs|afk was thinking to re-use delete operations instead of adding a pop endpoint
15:26:23 <malini> or maybe it will ?
15:26:29 <Obulpathi> so, how do we make sure that client got the message?
15:26:49 <flaper87> Obulpathi: in this case we don't care. It's up to the client
15:26:51 <Obulpathi> if the server just returns the message and deletes it .. won't htat be a problem ... in case of unreliable communication?
15:27:02 <Obulpathi> ok .. gotcha
15:27:04 <malini> Obulpathi: tht is the trade off the app designer has to make
15:27:20 <malini> you can either claim & delete - or pop
15:27:22 <flaper87> Obulpathi: if the client needs that pattern (get & ack) then it has to claim 1 message and then delete it from the client side
15:27:37 <Obulpathi> thanks flaper87 :)
15:27:53 <Obulpathi> so a seperate endpoint means ??
15:28:05 <sriram> so pop cant delete a claimed message correct?
15:28:07 <alcabrera> adding a new path to the API
15:28:08 <malini> Obulpathi: a new API call
15:28:08 <flaper87> so, I think the idea of re-using delete is nice: DELETE /............/messages/?{pop}
15:28:10 <alcabrera> e.g.
15:28:18 <malini> sriram: it should pop a claimed message
15:28:21 <malini> not*
15:28:23 <alcabrera> something like: /v1/queues/{name}/messages/pop
15:28:29 <alcabrera> Obulpathi: ^
15:28:32 <Obulpathi> ... instead of riding on the get ...
15:28:35 <alcabrera> yup
15:28:37 <Obulpathi> cool
15:28:48 <flaper87> "riding on the get" <- lol
15:28:51 <flaper87> I like that
15:28:53 <Obulpathi> that would be clean ... rather than piggy backing on get
15:28:56 <sriram> malini: understood, makes sense.
15:29:00 <alcabrera> the tricky part
15:29:02 <alcabrera> is
15:29:07 <alcabrera> given RESTful design principles
15:29:14 <alcabrera> an endpoint shouldn't be an action
15:29:22 <alcabrera> /pop
15:29:24 <malini> from http://www.w3.org/Protocols/rfc2616/rfc2616-sec9.html  'The DELETE method requests that the origin server delete the resource identified by the Request-URI.'
15:29:36 <Obulpathi> so should we have something like POP URI?
15:29:39 <malini> so pop on DELETE might not be a good idea
15:29:59 <alcabrera> malini: good point
15:30:06 <flaper87> malini: not sure I follow
15:30:08 <alcabrera> Obulpathi: no, since POP is not a valid HTTP verb
15:30:13 <flaper87> ah
15:30:14 <flaper87> gotcha
15:30:19 <Obulpathi> yep .. true .. new verbs are not good
15:30:22 <flaper87> I should have read the first part of your message too
15:30:24 <flaper87> :P
15:30:30 <Obulpathi> :D
15:30:36 <malini> flaper87: DELETE /v1.1/queues/fizbit/messages?pop=5 we are not specifying what to delete
15:30:39 <flaper87> so, no good fit for DELETE
15:30:43 <sriram> flaper87: pop=3, does not specify the actual resource URI to delete, I think thats what she is getting at.
15:30:51 * sriram must learn to type faster
15:30:53 <flwang> I think based on DELETE is more reasonable
15:31:00 <flwang> given alcabrera said
15:31:07 * flaper87 should learn to *read* everything
15:31:12 <Obulpathi> how about POST?
15:31:19 <Obulpathi> nop ...
15:31:38 <flaper87> I guess it'll have to be a GET /pop
15:31:40 <malini> POST /v1.1/queues/{queue_name}/claims{?limit, pop}
15:31:42 <malini> ?
15:31:49 <flaper87> or post
15:32:00 <flaper87> POST reads wrong
15:32:08 <malini> flaper87: why?
15:32:20 <alcabrera> POST in the spec talks about creating a subordinate resource
15:32:33 <flaper87> it's maybe just me: I read that as: posting (as in sending) stuff to the server
15:32:45 <flaper87> not getting / deleting stuff from it
15:32:48 <sriram> Then it has to be a GET
15:32:48 <alcabrera> flaper87: that's how the HTTP spec treats POST, yup
15:33:11 <alcabrera> sriram: maybe, if we can express the notion of popping as idempotent
15:33:11 <flaper87> then GET /pop
15:33:14 <malini> but it cannot be GET either, coz we delete it :(
15:33:23 <alcabrera> hmmm
15:33:23 <sriram> but I'm not 100% with this, as we are actually deleting stuff
15:33:27 <malini> Thts why we need a new POP verb :D
15:33:32 * sriram creates a new verb
15:33:39 * flaper87 kicks http rfc out of the window and just fucking votes for GET
15:33:42 <malini> I new that a few week early ;)
15:33:56 <malini> though it was coz of caffeine withdrawal
15:34:01 <sriram> lol
15:34:07 <alcabrera> GET might be the way to go
15:34:16 <Obulpathi> +1
15:34:26 <alcabrera> so, here's the catch
15:34:28 <sriram> what does the rfc say for GET?
15:34:51 <flaper87> sriram: pretty much that you can do anything with it, just be nice
15:34:54 * flaper87 ducks
15:35:00 <alcabrera> #link http://www.w3.org/Protocols/rfc2616/rfc2616-sec9.html#sec9.3
15:35:04 <alcabrera> sriram: ^6
15:35:26 <sriram> alcabrera: thanks for the link
15:35:26 <malini> they dont say anything abt modifying it ;)
15:35:31 * sriram ninja reads
15:35:31 <flaper87> to be fair, /pop is indeed getting stuff from the server
15:35:36 <flaper87> and sending it to the client
15:35:43 <alcabrera> and it is an idempotent "action"
15:35:50 <flaper87> it does delete the resource, though
15:35:51 <malini> but its like going to the museum & taking the painting with you
15:36:00 <flaper87> but I don't care much about that
15:36:13 <flaper87> (re deleting)
15:36:31 <flaper87> malini: isn't that something good?
15:36:31 <alcabrera> if you pop, you will always perform the same operation. pop n (x:xs) = x : pop (n-1) xs; pop 0 _ = []; pop _ [] = []
15:36:40 <flaper87> you'd have a new paint (unless you brun it down)
15:36:49 <flaper87> burn*
15:37:08 * flaper87 votes for pop
15:37:08 <malini> flaper87: yeah..except for a new visitors & your photos in the news :D
15:37:13 <flaper87> erm, get pop
15:37:18 <flaper87> LOL
15:37:25 <alcabrera> lol
15:37:27 <malini> wonder what other queue implementations do
15:37:29 <alcabrera> get very pop
15:37:50 <flaper87> #info we all pretty much agree on GETing POP-tarts out of the API instead of POSTing them
15:38:05 <flwang> but GET is most like a READ-ONLY action
15:38:17 <flaper87> #info kgriffs if you're reading this, please, run! Malini is thinking about stealing paints from museums
15:38:17 <flwang> flaper87: not me :D
15:38:36 <flaper87> flwang: LOL
15:38:42 <malini> maybe pop should just be a client operation?
15:38:56 <flaper87> malini: but we need to support it in the server too
15:39:05 <flaper87> I mean, have a way to actually pop the message
15:39:13 <flaper87> that's why I thought re-using DELETE was cool
15:39:20 <flaper87> because we could make pop a client side thing only
15:39:29 <flwang> flaper87: so we not just tag the DELETE action?
15:39:30 <flaper87> but YOU destroyed my dream
15:39:32 <flaper87> :(
15:39:41 <malini> mission accomplished :D
15:39:46 <malini> now lets do whatever
15:39:53 <sriram> hmm, interesting
15:40:15 <flwang> we/why
15:40:18 <sriram> so it now means the message is now gone in the clients view, but still exists on the server?
15:40:21 <flaper87> so, lets give it another week
15:40:32 <flaper87> malini: you can still work on it, we'll figure the verb out later
15:40:48 <malini> sure..we can discuss it in #openstack-marconi
15:40:54 <sriram> +1
15:40:58 <flaper87> #info discuss the pop verb further
15:40:59 <malini> I'll do some homework meanwhile
15:41:02 <flaper87> LOL pop verb
15:41:22 <flaper87> I pop, you pop, I popped, I pownped
15:41:22 <flaper87> etc
15:41:26 <flaper87> I had pownped
15:41:29 <flaper87> anyway
15:41:48 <flaper87> any other comment?
15:42:16 <alcabrera> I'm all popped out
15:42:19 <malini> not from me
15:42:20 <flaper87> #topic queue metadata
15:42:37 <flaper87> So, there's a plan for removing queue metadata
15:42:45 <flaper87> any objections? concerns?
15:42:58 <malini> megan_w: ?
15:43:11 <malini> She is away :(
15:43:16 <flwang> because we're going to embrace the no-queue Marconi?
15:43:21 <alcabrera> no objections from me, since the name can always be used as a proxy for queue metadata
15:43:28 <flaper87> flwang: that's one reason
15:43:45 <flwang> flaper87: may I know the others :)?
15:43:54 <flaper87> flwang: just if you pay for them
15:44:10 <flwang> one cup of beer on the summit
15:44:19 <flaper87> flwang: so, other reasons are: 1) We're actually not using (violates YAGNI)
15:44:29 <flaper87> flwang: don't lie to me, you said you won't be there :(
15:44:51 <flwang> flaper87: it's not sure :D
15:44:56 <flaper87> 2) It adds more endpoints thatw e don't need
15:45:03 <flaper87> flwang: AWESOME! Then 2 beers
15:45:07 <flaper87> or wine
15:45:07 <Obulpathi> I can pay for beer for you flaper87
15:45:11 * flaper87 prefers wine
15:45:11 <flwang> my travel has been approved by IBM internal, but... you know that
15:45:15 <flaper87> Obulpathi: w000000000000000000000000t
15:45:22 <flaper87> I'll take beer if you pay
15:45:23 <Obulpathi> for flwang too :)
15:45:23 <flaper87> :D
15:45:24 <malini> yayy kgriffs
15:45:41 <flaper87> ok, moving forward
15:45:46 <flaper87> so, no concerns on that ?
15:45:58 <flaper87> I'll be more than happy to remove it
15:46:05 <flaper87> any migration plan we should consider ?
15:46:14 <alcabrera> yes, let's talk migration
15:46:15 <alcabrera> so
15:46:16 <flaper87> What happens if some folks were using the metadata?
15:46:23 <alcabrera> exactly
15:46:27 <Obulpathi> so what is all in metadata btw?
15:46:40 <alcabrera> metadtaa is an opaque field attached to a queue
15:46:43 <alcabrera> it's created using a PUT
15:46:44 <flwang> flaper87: so as for 1) We're actually not using , who are 'we'?
15:46:46 <kgriffs> o/
15:46:49 <malini> Obulpathi: https://wiki.openstack.org/wiki/Marconi/specs/api/v1#Queue_Metadata
15:46:53 <flaper87> kgriffs: YOOOO
15:46:55 <alcabrera> PUT /v1/queues/{name}/metadata JSON_THING
15:46:56 <flaper87> #chair kgriffs
15:46:56 <openstack> Current chairs: flaper87 kgriffs
15:47:03 <flwang> flaper87: marconi team or the marconi consumer?
15:47:05 <Obulpathi> got it .. thanks for link malini
15:47:06 <alcabrera> kgriffs: glad to see you here! It's been lively today.
15:47:14 <kgriffs> where did you end up on the pop thing?
15:47:21 <malini> that must be a big chair :D
15:47:32 <sriram> heh
15:47:58 <malini> kgriffs: we didnt reach an agreement, & plan to continue the discussion in marconi channel
15:48:00 <kgriffs> and.. did you discuss adding pop to the claim endpoint?
15:48:12 <kgriffs> (instead of messages)
15:48:17 <kgriffs> s/endpoint/resource
15:48:23 <kgriffs> malini: ok
15:48:27 <sriram> kgriffs: new endpoint, deciding on the verb, all sorts of discussions
15:48:37 <malini> we did & somebodyd didnt like it..I dont remember why (already)
15:48:58 <kgriffs> ok, we can discuss further in #openstack-marconi
15:49:02 <alcabrera> +1
15:49:34 <kgriffs> ok, so now we are talking about metadata
15:49:43 <flaper87> kgriffs: yes sir!
15:49:53 <flaper87> kgriffs: you have to read the meeting logs after we finish
15:49:55 * flaper87 ducks
15:50:00 <kgriffs> heh, trying
15:50:08 <flaper87> kgriffs: after, after :D
15:50:33 <kgriffs> so, i think we were going to try and see if any Rackspace public cloud users were using metadata
15:50:36 <flaper87> soooo, I'm having this really evil idea of disabling metadata right away
15:50:45 <flaper87> kgriffs: good point
15:50:47 <alcabrera> flaper87: that's where I'm leaning. ;)
15:50:53 <flaper87> alcabrera: :P
15:51:05 <kgriffs> if it is pretty rare, or nobody is using it, we can remove it
15:51:13 <flaper87> rm -Rf /metadata
15:51:13 <flwang> flaper87: so as for 1) We're actually not using , who are 'we'?
15:51:20 <Obulpathi> why did we have it in the first place?
15:51:27 <alcabrera> flwang: marconi consumers on the public cloud
15:51:27 <flwang> flaper87: marconi team or the marconi consumer?
15:51:33 <flaper87> flwang: both?
15:51:37 <alcabrera> flwang: e.g., like RAX Cloud Queues customers
15:51:47 <Obulpathi> ok
15:51:51 <alcabrera> that's my concern wrt to metadata migration, if any
15:51:56 <sriram> disabling/removing metadata would be a first step towards making queues act like topics.
15:52:03 <flwang> alcabrera: thanks, so after scan the RAX Marconi db, we can know that, right?
15:52:04 <flaper87> I don't think there's a really good path to migrate metadta
15:52:04 <kgriffs> Obulpathi: gold plating, speculation. But we have had a hard time coming up with use cases for it. Some users may have some, though, which is why I want to do a sanity check.
15:52:04 <flwang> haha
15:52:08 <flaper87> there's nothing to migrate
15:52:25 <flaper87> that's more like: Put it somewhere safe because you ain't see it again
15:52:27 <kgriffs> balajiiyer: can we get that report by the next meeting?
15:52:28 <Obulpathi> ok
15:52:48 <kgriffs> wrt migration...
15:53:19 <kgriffs> I was thinking, they can still set/get it via the 1.0 API
15:53:46 <kgriffs> but the metadata resource simply won't exist in the 1.1 API
15:53:58 <flwang> kgriffs: it make sense for me
15:53:59 <Obulpathi> till when 1.0 will be supported?
15:54:01 <flaper87> yeah but deploying 2 versions of the API is not very nice
15:54:12 <kgriffs> so, unless we are going to say you can only access queue X from the same API you created it, I think users can go back and forth
15:54:13 <sriram> I agree
15:54:14 <flaper87> it gets really weird when you need to interact with the service
15:54:20 * flaper87 has done that with glance
15:54:26 <kgriffs> flaper87: agreed, but we have to for backwards-compat
15:54:30 <flaper87> also, the 1.0 and 1.1 are the same major
15:54:37 <balajiiyer> kgriffs: yeah, I will try to get it for you. can you add an action item?
15:54:39 <flaper87> which makes it even weirder
15:54:45 <sriram> flaper87: good point
15:55:08 <kgriffs> #action balajiiyer to get report on queue metadata usage by Rackspace customers
15:55:11 <flaper87> I would say, if we need to migrate (because there are folks using it) then, lets disable "setting" metadata on 1.1 and keep get
15:55:19 <flaper87> then we'll remove get
15:55:38 <flaper87> just to give people enough time to test other ways to maintain their queue metadata
15:55:46 <kgriffs> that could work
15:55:47 <malini> flaper87: +1
15:55:51 <Obulpathi> +1
15:55:55 <alcabrera> +1
15:55:58 <flwang> but we must release two versions before we deprecate it
15:56:06 <alcabrera> that's a sane deprecation strategy
15:56:07 <flaper87> flwang: ssssssssssssssshhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhh
15:56:10 <kgriffs> we would need to note in the docs that metadata is "Deprecated" and so is "read-only" in the 1.1 api
15:56:12 <alcabrera> and rm it all together for v2.0
15:56:29 <flaper87> flwang: I would consider Ith and Jth as the 2 versions
15:57:00 <flaper87> ok, we should open dicussion for 2 mins and then end the meeting
15:57:04 <alcabrera> +1
15:57:06 <flaper87> #topic open discussion
15:57:09 <kgriffs> #note if we want to deprecate metadata, first make it read-only in 1.1
15:57:24 <kgriffs> lazy-create I think everyone is cool with, right?
15:57:28 <alcabrera> very
15:57:31 <flaper87> kgriffs: Fuck Yeah!
15:57:37 <flwang> kgriffs: or is it possible to do survey for current RAX Marconi user?
15:57:42 <sriram> Yep. I will be taking it up :D
15:57:47 * flaper87 wants to give Obulpathi a ver warm welcome to the team
15:57:51 <sriram> lazy-create i mean.
15:58:00 <malini> anything lazy is good
15:58:04 <sriram> Welcome Obulpathi :)
15:58:05 <Obulpathi> thanks flaper87 ...
15:58:08 <malini> Welcome again Obulpathi
15:58:17 <Obulpathi> and sriram and malini too :D
15:58:24 <malini> you get a sign on bonus - chocolate pop-tart
15:58:30 <flaper87> Folks, we need lot of community work so, get out there, give flyers away on your busses, make pizzas with Marconi's logo, etc
15:58:34 <flwang> kgriffs: about if the metadata is really useful
15:58:41 <flaper87> and print the FAQ on those pizzas too
15:58:46 <kgriffs> flwang: yes, balajiiyer will take care of that
15:58:47 <sriram> I think we need to create pop-coin like bitcoin :P
15:58:55 <flwang> kgriffs: instead of kicking our brain in our private channel
15:59:05 <alcabrera> yes, welcome Obulpathi. :)
15:59:18 <Obulpathi> thanks alcabrera
15:59:20 <kgriffs> flwang: I'm a big fan of talking to users more and speculating less, in general. :D
15:59:24 <flwang> kgriffs: got it, it would be great
15:59:36 <kgriffs> so, malini will chair next meeting
15:59:39 <flwang> kgriffs: cool
15:59:40 <alcabrera> w00t
15:59:42 <kgriffs> I will be traveling back from PyCon
15:59:53 <sriram> go malini! :)
15:59:53 <alcabrera> kgriffs: enjoy! :D
16:00:05 <alcabrera> close
16:00:07 <malini> we'll make sure to give kgriffs all the #action ;)
16:00:07 <ametts> Ya'll watch out... malini is mean!
16:00:14 <flaper87> thanks folks!
16:00:18 <flaper87> tty next week
16:00:21 <sriram> see ya
16:00:23 <Obulpathi> tty next week
16:00:23 <flaper87> #endmeeting