16:03:13 <kgriffs> #startmeeting marconi
16:03:14 <openstack> Meeting started Mon Aug 19 16:03:13 2013 UTC and is due to finish in 60 minutes.  The chair is kgriffs. Information about MeetBot at http://wiki.debian.org/MeetBot.
16:03:15 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
16:03:18 <openstack> The meeting name has been set to 'marconi'
16:03:21 <flaper87> <o/
16:03:31 <kgriffs> #link https://wiki.openstack.org/wiki/Meetings/Marconi#Agenda
16:03:47 <kgriffs> #topic 	•	Review actions from last time
16:03:58 <kgriffs> #link http://eavesdrop.openstack.org/meetings/marconi/2013/marconi.2013-08-12-16.04.html
16:04:12 <kgriffs> 2a.
16:04:28 * flaper87 hides
16:04:33 <kgriffs> cppcabrera and flaper87 ^^^
16:04:35 <kgriffs> :D
16:04:41 <cppcabrera> :P
16:04:42 <cppcabrera> Lessee...
16:04:53 <cppcabrera> No progress.
16:05:03 <flaper87> didn't had a chance! But I do think the client is becoming quite urgent now!
16:05:14 <flaper87> (lets talk about that later)
16:05:25 <kgriffs> ok
16:05:34 <kgriffs> #action cppcabrera and flaper87 to turn apiclient-marconi etherpad into bps/bugs
16:05:42 * kgriffs malini to update the etherpad and start working on the re-factor
16:06:05 <kgriffs> malini: ?
16:06:08 <malini> I started working on the refactoring
16:06:18 <malini> will have patches for tht coming soon
16:06:30 <malini> As in today or tomorrow :)
16:07:28 <malini> I havent started on the tox part yet
16:07:35 <kgriffs> ok, cool
16:07:45 <malini> will work with flaper87 on TOXifying the tests
16:07:59 <kgriffs> #action malini to work with flaper87 on TOXifying the tests
16:08:07 <flaper87> <o/
16:08:12 <cppcabrera> +1 - looking foward to tox support.
16:08:16 * kgriffs kgriffs,flaper87, et al. to stop using Trello and focus efforts on getting/keeping Launchpad up to date
16:08:29 <kgriffs> so, I have been trying to keep bp's up to date
16:08:30 * flaper87 hasn't looked at trello in years
16:08:35 <flaper87> :D
16:08:39 <kgriffs> and I've added a few new ones based on trello cards
16:08:56 <flaper87> I think it was a good call
16:08:58 <cppcabrera> I like how quickly and efficiently this was started. The title page approach is great (Openstack - Marconi (Old, No Longer Used))
16:08:59 <kgriffs> but I'm sure there is some lower-priority stuff that I've forgotten about that doesn't have a bp yet
16:09:09 <kgriffs> so
16:09:14 <kgriffs> I like it too
16:09:19 <flaper87> Although, LP is not the best tool out there, keeping everything in it seems good
16:09:31 <kgriffs> kgriffs.stress -= 10
16:10:24 <kgriffs> I am talking with a dev tools guy at Rackspace who is interested in writing something that makes Launchpad more friendly. We'll see how that goes.
16:10:40 <flaper87> awesome!
16:10:52 <kgriffs> anyway, if you don't see a pet feature of yours in Launchpad-land, please register it as a blueprint or bug
16:11:27 <kgriffs> FWIW, I created an Icehouse series and Icehouse-1 milestone
16:12:02 <kgriffs> so that is available for long-range planning
16:12:04 <kgriffs> any questions re. project management?
16:12:34 <flaper87> just a suggestion
16:12:34 <kgriffs> shoot
16:12:36 <kgriffs> I don't understand
16:12:36 <kgriffs> where all this is coming from
16:12:36 <kgriffs> I thought we were fine?
16:12:52 <flaper87> based on OS workflow, it is a good practice to set the "Expected" release when creating blueprints. That's what will trigger the review / discussion about it
16:12:53 * kgriffs couldn't resist
16:13:00 <flaper87> LOOOL
16:13:07 <kgriffs> ah, ok
16:13:29 <kgriffs> I will do that from now on. Forgot about that. Everyone else please do that as well.
16:13:45 <cppcabrera> Release as in "H3", "I1", etc.?
16:13:52 <flaper87> just to be clear, blueprints are not expected to be reviewed unless they are targeted
16:13:54 <flaper87> cppcabrera: yeah
16:14:08 <flaper87> that will help us all to keep track of new releases and "in-progress" ideas
16:14:15 <flaper87> hope that makes sense
16:14:17 <kgriffs> #action kgriffs to back-fill "Expected" release on bps
16:14:17 <cppcabrera> cool. thanks for the workflow heads up, flaper87.
16:14:52 <megan_w_> does that mean there needs to be some discussion about priority of a feature before a blueprint is made?
16:16:12 <flaper87> megan_w_: nope, the blueprint can be created. The author sets the target release, then the blueprint is dicussed and finally re-targeted if needed
16:16:22 <megan_w_> got it
16:16:26 <amitgandhi> +1
16:16:32 <flaper87> #link https://wiki.openstack.org/wiki/Blueprints
16:17:09 <flaper87> ok, moooving on!
16:17:10 <kgriffs> FWIW, you can just set the milestone and a script will update series goal for you
16:17:10 <flaper87> :D
16:17:14 <kgriffs> yep
16:17:19 <flaper87> kgriffs: +1
16:17:31 * kgriffs malini to verify/repro https://bugs.launchpad.net/marconi/+bug/1211386
16:17:49 <kgriffs> I think it's safe to assume this was done. :p
16:17:51 <malini> kgriffs: its done
16:18:06 * kgriffs cppcabrera to merge marconi cell bp's
16:18:18 <cppcabrera> Done.
16:18:18 <malini> kgriffs:launchpad doesnt have a better status to indicate that :(
16:18:35 <kgriffs> for the record, can you provide the link?
16:18:37 <malini> Going forward, I'll add a comment tht the fix is verified
16:18:42 <oz_akan_> kgriffs: we still haven't defined placement service
16:18:50 <oz_akan_> kgriffs: which I think affects the definition of a cell
16:18:51 * kgriffs loves saying "for the record" when it is literally correct
16:19:05 <cppcabrera> #link https://blueprints.launchpad.net/marconi/+spec/placement-service
16:19:13 <kgriffs> oz_akan_: thanks segue dude!
16:19:15 * kgriffs flaper87, cbbcabrera to schedule another placement service and/or cell architecture discussion
16:19:22 <flaper87> kgriffs: done
16:19:32 <zyuan_> when?
16:19:35 <flaper87> we reviewed the last draft on Monday
16:19:40 <flaper87> (last Monday)
16:19:42 <flaper87> or Tuesday ?
16:19:43 <kgriffs> can we break out discuss in #openstack-marconi after this?
16:19:44 <flaper87> mmh
16:19:52 <flaper87> kgriffs: sure
16:20:06 <cppcabrera> Yeah, placement service needs more thinking - the research continues.
16:20:08 <kgriffs> I wanted to share some more thoughts from last thursday
16:20:24 <kgriffs> #action team to finalize placement service architecture (high-level)
16:20:36 <kgriffs> ok, that's it for actions from last time
16:20:50 <kgriffs> #topic incubation
16:20:54 <cppcabrera> 40 minutes left for everything else - nice. :)
16:21:05 <flaper87> w0000t
16:21:05 <kgriffs> I would like to propose that we apply for incubation now
16:21:12 <ametts> +1
16:21:12 <megan_w_> we really need to get this rolling
16:21:14 <flaper87> yeahhh
16:21:15 <megan_w_> +1
16:21:18 <kgriffs> ok
16:21:19 <cppcabrera> Yes, let's.
16:21:28 <kgriffs> megan_w_: would you like to spearhead that?
16:21:42 <megan_w_> yes
16:21:53 <kgriffs> Trove just went though the process, so you can sync up with them for ideas
16:22:00 <flaper87> so, if we propose this now, it will be reviewed this week and we'll have to attend the next week's TC meeting
16:22:14 <kgriffs> ok
16:22:27 <megan_w_> good to know
16:22:44 <kgriffs> megan_w_: can you remind folks to attend that meeting?
16:22:57 <kgriffs> also, do you have the wiki page handy?
16:22:57 <megan_w_> yes.  i will figure out when it is and then remind people :)
16:23:09 <megan_w_> https://wiki.openstack.org/wiki/Marconi/Incubation
16:23:12 <megan_w_> that's the applicaiton
16:23:24 <kgriffs> kk
16:23:24 <kgriffs> https://wiki.openstack.org/wiki/Governance/Approved/Incubation
16:23:34 <kgriffs> #link https://wiki.openstack.org/wiki/Governance/Approved/Incubation
16:23:41 <kgriffs> #link https://wiki.openstack.org/wiki/Marconi/Incubation
16:24:18 <kgriffs> #action megan_w_ to apply for incubation this week and invite everyone to the TC meeting
16:24:34 <kgriffs> questions/comments on the topic before we move on?
16:24:55 <cppcabrera> I'm happy and looking forward to feedback from the OS community.
16:25:20 * kgriffs hopes we get a cool mentor
16:25:20 <megan_w_> one thing
16:25:24 <cppcabrera> +1 for incubation - sooner rather than later.
16:25:24 <cppcabrera> That's all from me.
16:25:41 <megan_w_> we'll want to be a "core" project, right?
16:25:55 <flaper87> yup
16:26:04 <megan_w_> great, just double checking
16:26:11 <kgriffs> megan_w_: "During the incubation process, the project will be required to submit regular status updates to the community describing the status and progress of the project."
16:26:17 <kgriffs> can you also take care of that?
16:26:20 <megan_w_> eys
16:26:21 <flaper87> I think we'll need to create a new program, TBH
16:26:23 <megan_w_> yes
16:26:47 <kgriffs> what do you mean by "program"?
16:26:52 <flaper87> but that will happen when coming out from incubation
16:26:56 <kgriffs> megan_w_: thanks!
16:28:30 <flaper87> kgriffs: https://wiki.openstack.org/wiki/Programs
16:28:30 <flaper87> #link https://wiki.openstack.org/wiki/Programs
16:28:30 <flaper87> we might want to have a Messaging program
16:28:31 <flaper87> where Marconi fits
16:28:31 <kgriffs> ah
16:28:31 <kgriffs> I've only ever heard people say "project"
16:28:31 <kgriffs> gtk
16:28:38 <kgriffs> or Queeus
16:28:40 <kgriffs> Queues
16:28:46 <kgriffs> whatever, we can figure that out later
16:28:50 <flaper87> yup
16:28:52 <Alex_Gaynor> Projects and programs are different things, I think marconi is a project
16:28:54 <cppcabrera> Program seems equivalent to project, with the added implication of greater communication, I think.
16:29:37 <kgriffs> ok, mooooving on
16:29:47 <ametts> Alex_Gaynor: If Marconi is a project, does it fall under a particular Program?
16:29:49 <flaper87> Alex_Gaynor: yup but it will fall into a program
16:29:51 <ametts> If so, which one?
16:30:16 <Alex_Gaynor> I guess we also need a queueing program then
16:30:20 <kgriffs> so, a program can have multiple projects under it
16:30:23 <flaper87> and there's no program for messaging (or similar to what marconi does)
16:30:25 <flaper87> correct
16:30:33 <flaper87> anyway, we can figure that out later
16:30:35 <kgriffs> like, the client for example
16:30:41 <flaper87> after incubation
16:30:45 <kgriffs> so, messaging is probably the better name
16:30:47 <kgriffs> anyway
16:30:57 <kgriffs> #topic Proposal: Add another core reviewer
16:31:35 <kgriffs> I'd like us to start thinking about this since it would decrease MTTA on patches
16:31:41 <kgriffs> (I just made that up)
16:31:48 <kgriffs> Mean Time to Approval
16:31:50 <zyuan_> MTTA.....
16:31:51 <flaper87> :P
16:32:02 <zyuan_> ETA
16:32:03 <kgriffs> I should trademark that
16:32:05 <flaper87> we'll need that during incubation as well
16:32:13 <zyuan_> estimated time of approval
16:32:17 <kgriffs> heh
16:32:24 <kgriffs> so...
16:32:36 <Alex_Gaynor> kgriffs: that'd be a fun metric to track across projects
16:32:37 <cppcabrera> :P
16:32:38 <oz_akan_> what is the requirement to be core reviewer?
16:32:51 <kgriffs> flaper87: what are your thoughts on that?
16:33:04 <kgriffs> Alex_Gaynor: true
16:33:06 <flaper87> Alex_Gaynor: There's a script that tracks that! The longest waiting review and so on
16:33:11 <flaper87> kgriffs: I agree with you
16:33:25 * ametts thinks kgriffs and flaper87 need to be confident that another reviewer will lead the project in the direction it needs to go.
16:33:26 <flaper87> cppcabrera: the requirement is to contribute a lot with meaningful reviews and patches
16:33:28 <kgriffs> flaper87: I can haz script?
16:33:29 <zyuan_> so, what's the requirements?
16:33:44 <flaper87> kgriffs: yup, will find it for you
16:33:58 <kgriffs> excellent
16:34:14 <kgriffs> ok
16:34:15 <cppcabrera> Also, the core reviewer should be consistently available.
16:34:38 <kgriffs> I think it is also a commitment to be an ongoing/active contributor to the project
16:34:39 <malini> cppcabrera: you just made that up ;)
16:34:48 <flaper87> cppcabrera: correct, IIRC some of you won't work fulltime on Marconi for long, I could be wrong
16:34:50 <megan_w_> should we have an application process of sorts for someone who thinks they would be a good fit for the role?
16:34:52 <cppcabrera> I did, malini. It's a thought. :D
16:35:09 <Alex_Gaynor> Other openstack projects work via nomination AFAIK
16:35:09 <malini> cppcabrera: +1 for that :)
16:35:16 <flaper87> the workflow is that core devs nominate people
16:35:31 <flaper87> that are a good fit for the project and have contributed for quite some time
16:35:36 <amitgandhi> its important to not just be a consistent active contributor, but as ametts thought - be able to guide the project in the right direction
16:35:37 <kgriffs> (by sending an email to dev list, typically)
16:35:42 <flaper87> I'd be very happy to have cppcabrera malini and zyuan_ in the team
16:35:49 <kgriffs> amitgandhi: correct
16:35:58 <flaper87> (i don't think we need an email this time)
16:36:05 <kgriffs> they must be wise in whatsoever things are entrusted them.
16:36:14 <flaper87> I'd be very happy to have y'all, but based on contributions I guess that's what makes more sense
16:36:21 <kgriffs> (probably not, since the team is still relatively small)
16:36:52 <amitgandhi> with great power comes great responsibility
16:36:52 <flaper87> amitgandhi: ametts +1
16:36:57 <kgriffs> ok, let's think about it and propose someone next week
16:37:00 <zyuan_> hahah
16:37:05 <flaper87> kgriffs: +1
16:37:17 <megan_w_> just one more for now?
16:37:20 <oz_akan_> do we need to add just one person, or can we add two?
16:37:31 <cppcabrera> Works for me. Direction, vision, reliability, and commitment for core reviewers.
16:37:31 <kgriffs> great question
16:37:32 <flaper87> oz_akan_: we can add as many as necessary
16:37:45 <flaper87> it's all based on the contributions and the work people have done
16:37:52 <kgriffs> I'd say 2 for now
16:38:02 <oz_akan_> how is contribution measured?
16:38:07 <flaper87> oz_akan_: reviews
16:38:23 <flaper87> patches reviwed and proposed
16:38:46 <kgriffs> ok, we've got to move
16:38:58 <oz_akan_> ok
16:39:01 <cppcabrera> Agreed. Next topic?
16:39:05 <kgriffs> #topic Proposal: enable logging for #openstack-marconi, and/or meetbot?
16:39:27 <kgriffs> so, this just happened for metering
16:39:32 <kgriffs> and I thought it was a good idea
16:39:40 <flaper87> +1
16:39:48 <kgriffs> if nothing else, have meetbot in there to record ad-hoc meetings for posterity
16:39:53 <flaper87> it's great for folks w/o an IRC bouncer
16:40:00 <kgriffs> true dat
16:40:04 <flaper87> kgriffs: and that, +1
16:40:05 <cppcabrera> flaper87: yeeesss
16:40:07 <megan_w_> +1
16:40:13 * cppcabrera is one of those people
16:40:17 <Alex_Gaynor> +1
16:40:30 <kgriffs> anybody know if teams are on their own to run bots like that or if openstack-infra can help?
16:40:59 <Alex_Gaynor> infra has a thing, as far as I know
16:41:19 <flaper87> I'm not sure either, I think they do have something
16:41:23 <kgriffs> OK, I will ask
16:41:28 <flaper87> man, this guys rock!
16:41:32 <kgriffs> #action kgriffs to set up a bot for #openstack-marconi
16:42:28 <kgriffs> #topic Python Client: https://wiki.openstack.org/wiki/Python_Marconi_Client
16:42:29 <kgriffs> flaper87: I'll let you lead this discussion
16:43:16 <flaper87> so, I'm a bit worried about marconi client now. I think we should give it some love.
16:43:20 <flaper87> I haven't seen alessio around
16:43:32 <zyuan_> flaper87: before placement?
16:43:33 <flaper87> and the cleanup work that was supposed to be done is stalled
16:43:42 <zyuan_> which one has a higher priority
16:43:48 <flaper87> zyuan_: placement
16:43:51 <amitgandhi> placement has a higher priority
16:43:53 <kgriffs> but
16:43:58 <kgriffs> not everyone is working on placement
16:43:58 <flaper87> but, we can split efforts
16:44:01 <Alex_Gaynor> There's a handful of patches in review now, I tried to do some reviews on them
16:44:02 <flaper87> exactly
16:44:10 <flaper87> Alex_Gaynor: +1 thanks!
16:44:11 * kgriffs creeped out again
16:44:26 <cppcabrera> The cllient definitely could use some love.
16:44:31 <cppcabrera> *client
16:44:41 <amitgandhi> so either client or other perf optimizations
16:44:47 <cppcabrera> I've got a few touch ups to left on the message controller.
16:45:01 <cppcabrera> s/to//
16:45:08 <flaper87> so, I'm about to make a radical proposal. Since the work to be don in Alessio's code seems huge, I'd say we should revert it and buld our own client code
16:45:08 <amitgandhi> do we need client for incubation?
16:45:20 <flaper87> based on request and taking auth pieces from other projects
16:45:23 <flaper87> amitgandhi: no, we don't
16:45:37 <kgriffs> alex_gaynor: do you have bandwidth to help more with python-marconiclient?
16:45:40 <cppcabrera> flaper87: since we haven't heard from alessio in a very long time, I'm in favor of this.
16:45:58 <flaper87> but users would appricate having something like: marconi queue-create blah
16:46:02 <kgriffs> and/or someone else from the Rackspace developer advocate group?
16:46:15 <Alex_Gaynor> kgriffs: I can either make time or get another person from my team to help
16:46:35 <kgriffs> that would be FAN-TAS-TIC
16:46:36 <flaper87> Alex_Gaynor: that would be great
16:46:40 <megan_w_> awesome
16:46:48 <amitgandhi> +1 to Alex_Gayner !!!
16:47:02 <ametts> jdprax Did a quick-n-dirty marconi client a while back.
16:47:04 <cppcabrera> That'd be awesome, alex_gaynor. I love submitting patches and helping with client-dev, but doing the research on writing an idiomatic wrt to OS client is tough.
16:47:12 <ametts> Maybe that's a starting point.
16:47:15 <kgriffs> #action Alex_Gaynor to take point on python-marconiclient under flaper87's direction
16:47:40 <kgriffs> you did volunteer, didn't you? ;)
16:47:45 <Alex_Gaynor> hehe
16:47:47 <ametts> #link https://github.com/painterjd/python-marconiclient
16:48:00 <kgriffs> +1
16:48:04 <Alex_Gaynor> Does the wikipage still represent the desired API?
16:48:11 <kgriffs> that doesn't use the proposed oslo client lib
16:48:29 <flaper87> so, that being said, if we all agree, I'll submit a patch reverting Alessio's patch and work on a base http client and structure to extend and clomplete
16:48:40 <flaper87> as a starting point for the client
16:48:52 <cppcabrera> alex_gaynor: Mostly, yes. I'm still unsure whether to go with verbs as functions (the openstack way - list, get, post, etc.) vs. using nouns (client.queues, queues.messages, etc.()
16:49:22 <cppcabrera> I prefer the latter, personally, but it seems most OS clients use the former.
16:49:39 <kgriffs> #action cppcabrera to assist with python-marconiclient design and implementation
16:49:47 <flaper87> lol
16:49:51 <cppcabrera> ^^ kgriffs +1 (I did volunteer. :P )
16:50:00 <flaper87> actions for free. Who wants one?
16:50:02 <flaper87> :D
16:50:02 <kgriffs> ok, so I think we have 3 hands on it now
16:50:05 <flaper87> yup
16:50:34 <oz_akan_> cppcabrera: don't forget placement service
16:50:45 <cppcabrera> That's my focus, oz_akan_.
16:50:57 <kgriffs> anyone else is always welcome to help, of course, but I want to make sure we have a core team
16:50:57 <cppcabrera> :)
16:51:07 <kgriffs> ok
16:51:15 * amitgandhi must hold cppcabrera back from running towards client full steam haha
16:51:30 <kgriffs> last item for today (other agenda items will have to wait for next time)
16:51:34 <oz_akan_> amitgandhi: :)
16:51:38 <kgriffs> #topic Finalize semantics around deleting claimed messags
16:51:42 <cppcabrera> :P
16:51:50 <kgriffs> afaik, this is the last remaining question mark re the API
16:52:14 <flaper87> yep, I think so
16:52:24 <kgriffs> so, the heart of the issue is...
16:52:41 <zyuan_> btw, does this still takes effects? https://review.openstack.org/#/c/37140/
16:52:59 <zyuan_> cppcabrera: ^^
16:53:15 <kgriffs> whether clients that do not know the Claim ID can delete claimed messages
16:53:22 <cppcabrera> zyuan_: Yeah, that's still current. I've been slow to patch but I've kept review comments in mind.
16:53:33 <kgriffs> or was there another issue here?
16:54:18 <flaper87> TBH, I'd say you can't delete claimed messages without claim-id
16:54:35 <ametts> flaper87: +1
16:54:38 <oz_akan_> +!
16:54:40 <zyuan_> both make sense
16:54:45 <oz_akan_> sorry 1
16:54:46 <kgriffs> so if i provide an incorrect claim, or no claim ID at all, return 403?
16:54:58 <zyuan_> the file lock on windows forbit you to delete the file
16:55:16 <zyuan_> while the file locks on unix are all advirisory
16:55:23 <malini> what abt scenarios that involve just notification ?
16:55:23 <ametts> I think the concern was over "cancel" semantics.  To my mind, one doesn't cancel tasks by deleting claimed messages from the queue.
16:55:35 <zyuan_> *advisory
16:56:03 <ametts> malini: just notification would be UNCLAIMED messages
16:56:08 <cppcabrera> amitgandhi made a really good analogy on that previously - it seems like poor communication for a "master" to delete a message ("task") a worker is taking care of without notifying them.
16:56:14 <kgriffs> malini: then claims wouldn't be involved
16:56:22 <ametts> there would be no claim id to provide.
16:56:40 <amitgandhi> deleting a claim should be intentional
16:56:41 <cppcabrera> So cancellation as a scenario seems like a bad idea to me the more I think about it. It should require a new message to do so, which puts me in a place where I favor requiring the claim ID.
16:56:47 <malini> so we are talking ant needing claim ID, only for claimed messages - correct?
16:56:50 <flaper87> but allowing claim deletion w/o claim-id will make the API inconsistent.
16:57:01 <flaper87> malini: yup
16:57:02 <amitgandhi> malni: yes
16:57:05 <kgriffs> just realized something
16:57:06 <zyuan_> flaper87: why?
16:57:26 <ametts> cppcabrera: excatly.  Put "start task" and "cancel task" on the queue as separate messages.
16:57:30 <kgriffs> if you require claim ID in all cases, then a producer could attempt to redact a message
16:57:39 <kgriffs> if it is already claimed, the DELETE would fail
16:57:44 <flaper87> zyuan_: because the whole point of claims is that you can operate on claimed messages if you have a claim-id
16:57:49 <kgriffs> otherwise, the delete succeeds
16:57:54 <kgriffs> which, I think, is what you want
16:57:57 <zyuan_> you don't provide claim id when you get a claimed message right?
16:58:05 <kgriffs> should be OK to recall a message until it is claimed
16:58:07 <zyuan_> so in my point of view it's consistent
16:58:18 <zyuan_> flaper87: no
16:58:38 <kgriffs> 30 seconds, then we vote
16:58:46 <zyuan_> flaper87: the purpose of a claim is to use claim as a view to the messages
16:58:53 <ametts> kgriffs:  In theory, a producer should never know a consumer's claim id anyway.
16:58:54 <zyuan_> not to control
16:59:02 <zyuan_> and btw
16:59:04 <ametts> The whole point of a queue is to decouple applications
16:59:15 <kgriffs> correct
16:59:19 <kgriffs> so, in that sense, it is like email
16:59:19 <zyuan_> by enfocring this, the normal pub-sub is supposed to be slower
16:59:20 <flaper87> ametts: correct
16:59:21 <kgriffs> you can send it
16:59:41 <kgriffs> but once it has left the email server under your control, you can't recall it
16:59:45 <zyuan_> ametts: exactly, decoupling
17:00:06 <flaper87> mmmh, actually, I think I agree with you, zyuan_
17:00:32 <oz_akan_> I think problem is if we want to support publisher-subscriber and producer-consumer for the same queue at the same time
17:00:41 <zyuan_> "view" means, you can operate the thing under this view in whatever way you want
17:00:50 <oz_akan_> I believe if a message claimed, then user choose to use producer-consumer
17:00:53 <zyuan_> but if you want to take the advantage, obey the view
17:00:58 <oz_akan_> and he would like to have this claimed message sage
17:00:59 <oz_akan_> saf
17:01:01 <oz_akan_> safe
17:01:09 <kgriffs> #startvote require claim_id in all cases when deleting a message that is claimed? Yes, No, Abstain
17:01:10 <openstack> Begin voting on: require claim_id in all cases when deleting a message that is claimed? Valid vote options are Yes, No, Abstain.
17:01:12 <openstack> Vote using '#vote OPTION'. Only your last vote counts.
17:01:28 <zyuan_> #vote No
17:01:35 <oz_akan_> #vote Yes
17:01:57 <amitgandhi> #vote Yes
17:01:59 <zyuan_> don't tell me anyone want to require claimed_id when GET a message
17:02:00 <cppcabrera> #vote Yes
17:02:00 <malini> #vote No
17:02:06 * flaper87 still thinking
17:02:32 <kgriffs> #vote no
17:02:45 <ametts> #vote Yes
17:02:55 <flaper87> #vote Yes
17:02:56 <oz_akan_> if a worker claims a message and another deletes it, what is the point in claiming messages
17:03:11 <flaper87> oz_akan_: that's what made up my mind :D
17:03:20 <oz_akan_> mine too :)
17:03:23 <zyuan_> oz_akan_: we don't care, our design don't care
17:03:27 <kgriffs> it's a safeguard for application bugs
17:03:44 <zyuan_> if our design cares, then the design breaks
17:03:49 <zyuan_> (in many ways)
17:03:49 <kgriffs> and for edge case (where a claim expires before a worker is done with it, and get's picked up by another worker)
17:03:51 <flaper87> I'm open to discus it further if you guys want
17:03:53 <zyuan_> (you will see)
17:04:04 <amitgandhi> claims are eventually released, at whcih point it can be deleted by the producer
17:04:10 <oz_akan_> amitgandhi: +!
17:04:12 <kgriffs> anyone want to change their vote?
17:04:13 <oz_akan_> +1
17:04:15 <oz_akan_> no
17:04:26 <oz_akan_> not me I mean
17:04:52 <kgriffs> #endvote
17:04:53 <openstack> Voted on "require claim_id in all cases when deleting a message that is claimed?" Results are
17:04:54 <openstack> Yes (5): amitgandhi, ametts, oz_akan_, cppcabrera, flaper87
17:04:55 <openstack> No (3): malini, zyuan_, kgriffs
17:05:16 <kgriffs> I'm OK with the majority as it stands
17:05:41 <zyuan_> democracy is to protect the minority
17:05:41 <kgriffs> can I get a volunteer to make the change?
17:05:45 <zyuan_> (it was said that)
17:05:48 <kgriffs> heh
17:06:17 <cppcabrera> I'm happy either way - only by using the system and let others take it for a spin will we learn what really works.
17:06:18 <kgriffs> given that Flaper87 voted yes, and mine was a "soft" no (in my mind), I think this decision should stand
17:06:22 <cppcabrera> s/let/letting
17:06:26 <zyuan_> at least, that what i learn in US university
17:06:30 <kgriffs> cppcabrera: +1 zillion
17:06:39 <oz_akan_> oh so our votes are halg
17:06:41 <flaper87> cppcabrera: +1
17:07:45 <kgriffs> votes matter, but core team members I think have the final say.
17:08:11 <oz_akan_> uep
17:08:17 <oz_akan_> why can't I type today
17:08:21 <kgriffs> I think that is kinda how openstack works
17:08:30 <kgriffs> #endmeeting