15:02:59 <kgriffs> #startmeeting marconi
15:02:59 <openstack> Meeting started Tue May 27 15:02:59 2014 UTC and is due to finish in 60 minutes.  The chair is kgriffs. Information about MeetBot at http://wiki.debian.org/MeetBot.
15:03:00 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
15:03:01 <sriram> \o o/
15:03:02 <openstack> The meeting name has been set to 'marconi'
15:03:02 <kgriffs> #topic roll call
15:03:05 <kgriffs> o/
15:03:14 <sriram> o/
15:03:21 <mpanetta> o/
15:03:22 <Obulpathi> o/
15:04:24 <kgriffs> It seems we are missing Mr. Percoco
15:04:28 <malini> o/
15:04:43 <malini> Mr. Percoco said he cant make it today
15:04:51 <malini> He has a python meetup to go to
15:05:27 <kgriffs> oic
15:05:47 <kgriffs> #topic review actions from last time
15:05:55 <kgriffs> #link http://eavesdrop.openstack.org/meetings/marconi_team_meeting/2014/marconi_team_meeting.2014-05-20-15.01.html
15:06:07 <kgriffs> 1. kgriffs to address over vs. under cloud in FAQ, mention on home page
15:06:43 <kgriffs> I added a section to the FAQ about this - feel free to improve upon my first attempt at addressing the question
15:07:09 <kgriffs> #link https://wiki.openstack.org/wiki/Frequently_Asked_Questions_(Marconi)
15:07:24 <kgriffs> I still need to add a note about it to the home page
15:07:35 <kgriffs> I'll do that right after this meeting
15:07:48 <kgriffs> 2. kgriffs to document roadmap and send to ML for feedback
15:08:14 <kgriffs> done
15:08:30 <kgriffs> #link https://wiki.openstack.org/wiki/Roadmap_(Marconi)
15:08:53 <kgriffs> we obviously have tons to do, but we also have lots of contributors now, so I am optimistic. :D
15:09:26 <kgriffs> any questions/comments/concerns/rude remarks about the roadmpa?
15:09:44 <malini> I am good
15:10:16 <malini> I am positive abt  completing the Tempest tests, but not so much abt getting reviews for it
15:11:20 <kgriffs> sounds like they need more core reviewers?
15:11:32 <kgriffs> or more reviewers that are active?
15:11:59 <malini> they have  ton of patches coming in everday :(
15:13:47 <kgriffs> i bet... hmmm. Well, maybe one of us on the team can work towards becoming a core reviewer to help lighten their load so other reviewers have more time for incubated projects. :)
15:14:17 <kgriffs> malini: maybe we can bring this up with devenanda and jarrett
15:14:30 <malini> sure - tht'll be great!
15:14:47 <kgriffs> see if between the three projects we can come up with 1-2 folks
15:14:58 <kgriffs> I'll send an email to the ML
15:15:17 <kgriffs> #action kgriffs to reach out to ironic, barbican wrt tempest patch backlog
15:16:11 <kgriffs> 3. megan_w to check trademarks for our shortlist of names
15:17:33 <kgriffs> megan_w|afk: ^^^
15:17:47 <kgriffs> lots of people missing today. :(
15:17:56 <kgriffs> #action megan_w to check trademarks for our shortlist of names
15:17:57 <Obulpathi> yes :(
15:18:11 <kgriffs> #action flaper87 to summarize 0.9 vs. 1.0 discussion in the context of openstack, add to AMQP driver bp, send to ML
15:18:15 <sriram_p> ls
15:18:30 <kgriffs> #action kgriffs, megan_w to get some feedback on AMQP 1.0 from Rackspace ops
15:19:17 <kgriffs> #topic Remove "Get a Specific Message" in v1.1?
15:19:44 <kgriffs> So, this keeps coming up as a point of confusion
15:20:16 <kgriffs> it adds to the "this API is strange for a message bus" factor
15:20:31 <kgriffs> also, it is perceived as a blocker for implementing certain kinds of backends
15:21:35 <kgriffs> finally, IMO it doesn't add any value to the API; I haven't been able to think of a reason anyone would need to get a message by ID, but I could be totally wrong - please tell me if you have a use case in mind
15:21:48 <malini> kgriffs: +1
15:22:10 <malini> if somebody needs to get a specific message by id, they could do it waith the multiple messages API call too
15:22:16 <kgriffs> Obulpathi: what do you think?
15:22:45 <Obulpathi> kgriffs: I don't see a use case for get the message by id
15:22:52 <sriram> yes, in the case of distributive task queues and such it shouldnt matter.
15:23:16 <kgriffs> malini: good point. should we get rid of this one as well? https://wiki.openstack.org/wiki/Marconi/specs/api/v1.1#Get_a_Set_of_Messages_by_ID
15:23:33 <Obulpathi> +1
15:23:43 <sriram> does SQS have support for it by any chance?
15:23:48 * sriram digs into it
15:24:06 <kgriffs> sriram: I don't believe so, but please double-check
15:24:18 <sriram> on it
15:24:23 <prashanthr_> then will the delete single message by id also be deprecated ?
15:24:34 <Obulpathi> no ..
15:24:37 <kgriffs> prashanthr_: yes
15:24:41 <kgriffs> oops
15:24:42 <kgriffs> no
15:24:47 <kgriffs> sorry, misread
15:24:50 <kgriffs> deletes remain
15:25:09 <prashanthr_> okay.
15:25:18 <Obulpathi> client shuld be able to delete the message once it works on it .. so we need that
15:25:32 <malini> if we dont support get by message id, what is the point of ever returning content-location/ message ids?
15:25:37 <kgriffs> but... hmmm, that gets me to thinking about something, but I guess that would be a 2.0 type change
15:25:51 <kgriffs> malini: for the deletes?
15:25:52 <vkmc> I don't see the need of getting a message by ID either... iirc consumers want first n messages in the queue and that's all
15:26:09 <kgriffs> for 2.0 we could do something a little more drastic
15:26:16 <Obulpathi> +1
15:26:48 <kgriffs> like, we assign a "delete" id when you claim messages, and you use that to delete things. then delete only makes sense within the context of claiming messages
15:27:06 <kgriffs> iirc, that's basically how SQS works
15:27:07 <sriram> yes
15:27:18 <malini> kgriffs: I like tht
15:27:29 <kgriffs> although, if you take away the feed endpoints, that is basically what we have today in any case
15:27:54 <kgriffs> I'll make a note of this idea in the 2.0 notes so we can discuss later
15:28:18 <Obulpathi> can we delete the message using the claim id itself?
15:28:23 <kgriffs> anyway, sounds like we are in agreement that we should remove getting one or more messages by id in v1.1
15:28:51 <kgriffs> Obulpathi: you mean, delete the claim deletes all the associated messages?
15:28:52 <sriram> I cant find evidence of SQS supporting getting a message by id either.
15:29:04 <sriram> kgriffs: +1, we can remove it.
15:29:06 <Obulpathi> kgriffs: yes
15:29:16 <malini> Obulpathi: as is, claimed messages are deleted with message id + claim id
15:29:38 <Obulpathi> ok :)
15:29:43 <Obulpathi> malini: :)
15:29:47 <kgriffs> Obulpathi: possibly, but we will need to decide if we want to encourage deleting multiple messages at a time, or if that is an anti-pattern; food for thought
15:30:05 <kgriffs> I'll note that idea on the 2.0 spec as well
15:30:12 <Obulpathi> oh got it .. we can claim multiple message in a single clain ..
15:30:25 <Obulpathi> *claim
15:30:38 <Obulpathi> so we need ability to delete messages individually
15:30:53 <kgriffs> #agreed remove support for GET single, multiple messages by ID in API v1.1
15:31:06 <sriram> yes multiple messages can have the same claim id.
15:31:11 <kgriffs> Obulpathi: yes, probably, but let's keep thinking about it
15:31:16 <Obulpathi> ok
15:31:19 <sriram> +1
15:31:20 <kgriffs> moving on...
15:31:52 <kgriffs> #action kgriffs to create the bp and update the v1.1 spec for removing support of GET by ID
15:32:34 <kgriffs> I'm going to skip some of these agenda items until next time, since I really need flaper87|afk to be here
15:32:47 <malini> ok..
15:32:50 <kgriffs> that brings us to...
15:32:53 <kgriffs> #action Adding a base test class for v1.1
15:32:57 <kgriffs> sriram: ^^^
15:33:01 <sriram> yes
15:33:13 <kgriffs> #link https://blueprints.launchpad.net/marconi/+spec/decoupling-unit-tests
15:33:17 <sriram> we need this to be done ASAP.
15:33:55 <malini> abettadapur: does your v1.1 functional tests patch add a new base class for 1.1 ?
15:34:05 <kgriffs> ok. I think some of the decoupling has already happened, or maybe I am thinking of some work i did in an abandoned patch. :p
15:34:11 <abettadapur> it does not
15:34:30 <sriram> the tests are for both v1 and v1.1 right now, we dont want to be doing ifs to check for api version.
15:34:34 <abettadapur> (though it shouldn't need to, because functional uses an existing server no?)
15:35:07 <kgriffs> I'm OK with this work, but I would like to find a way to share tests for functionality that is identical between 1.0 and 1.1
15:35:32 <malini> I think other projects do this by adding new base classes
15:35:39 <sriram> especially for changes that are breaking v1, we need to have the unit tests in there for new features, to get a jenkins +1 :P
15:35:55 <kgriffs> I suppose we could have a "v1.x" base class with shared tests
15:36:10 <kgriffs> then "v1.0" and "v1.1" inherit from that?
15:36:44 <sriram> hmm, so the v1.x will have the superset of all features?
15:36:48 <Obulpathi> or .. is there a way we can read the return code fmo a config file?
15:37:11 <Obulpathi> *form a config file .. depending on the version
15:37:34 <kgriffs> Obulpathi: the pattern we have been using for minor differences is to inherit from a base class with the test, then set a class variable for the return code or something
15:37:57 <Obulpathi> ok ... cool
15:37:58 <kgriffs> alternatively, the base class can have a "protected" helper
15:38:02 <kgriffs> like def _do_this_test
15:38:04 <malini> Obulpathi: it wont be just the return codes tht differ..we will have deprecated/new APIs etc.
15:38:12 <sriram> malini: +1
15:38:19 <kgriffs> and then you have in the child, do_this_test that calls _do_this_Test, passing in the expected return code
15:38:22 <Obulpathi> malini: ok
15:38:24 <malini> We need to do some research into how other projects did this
15:38:31 <malini> This is not a new problem :)
15:38:36 <Obulpathi> +1
15:38:51 <kgriffs> sure. Flavio will have some ideas based on his work on other projects
15:38:58 <sriram> yes, we need to get this figured out soon. for other patches to land.
15:39:10 <kgriffs> fwiw, the class variable pattern was originally his idea, so may have come from another proj
15:39:24 <kgriffs> ok
15:39:32 <kgriffs> malini: I made you "approver" for the design on the bp
15:39:47 <malini> cool!
15:40:04 <kgriffs> who would like to do the implementation?
15:40:23 <sriram> I can do it, once I'm done with marconi-bench
15:40:36 <malini> we need this by J-1 , rt?
15:40:37 <kgriffs> malini: just set definition to "approved" when we figure out a direction
15:40:43 <kgriffs> malini: yes
15:40:44 <sriram> malini: yes
15:40:54 <kgriffs> ok, I'll assign to you sriram
15:40:58 <kgriffs> and target for j-1
15:41:12 <sriram> cool, lots of work to do :D
15:42:12 <kgriffs> #topic Updates on blueprints
15:42:28 <kgriffs> #link https://launchpad.net/marconi/+milestone/juno-1
15:42:44 <kgriffs> Malini: API V1.1 - Pop operation
15:43:09 <malini> kgriffs: I got some comments from flaper87|afk - working on tht now
15:43:16 <malini> will have this by J-1
15:44:05 <kgriffs> sriram: API v1.1 - Lazily Create Queues
15:44:27 <sriram> kgriffs: got some comments from flaper87|afk as well.
15:44:37 <sriram> will address them, and should be by j-1
15:45:00 <sriram> will also need the unit tests here after we have a separate base class there.
15:45:23 <Obulpathi> anyone assigned to work on health endpoint?
15:45:34 <sriram> that might be a blocker for now, or do we want to do something else there.
15:45:59 <kgriffs> Obulpathi: flwang was working on that, but I haven't heard from him for a couple weeks...
15:46:14 <Obulpathi> kgriffs: cool
15:46:25 <malini> he might be in the middle of his move
15:46:33 <Obulpathi> any open issues I can take on?
15:47:18 <kgriffs> is anyone working on "API v1.1 header changes."
15:47:46 <malini> I think I saw abettadapur assigned to it somewhere?
15:48:11 <Obulpathi> yes, I think he is working on that
15:48:36 <kgriffs> ah, ok. I need to assign the bp to him then
15:48:46 <kgriffs> Obulpathi: how about this one?
15:48:47 <kgriffs> https://blueprints.launchpad.net/marconi/+spec/api-version-discovery
15:49:13 <Obulpathi> sure
15:49:25 <kgriffs> we would want to check around with some other projects to see if there is a de-facto standard way to do this.
15:50:04 <kgriffs> Obulpathi: assigned you
15:50:09 <abettadapur> i have the header changes completed
15:50:18 <abettadapur> i just need the unit tests to be compliant
15:50:21 <Obulpathi> kgriffs: :)
15:50:26 <kgriffs> abettadapur: rock on
15:50:29 <abettadapur> i can help sriram if he would like
15:50:38 <kgriffs> Obulpathi: I think you can also take "API v1.1 Request Document Changes"
15:50:49 <kgriffs> and maybe also "API v1.1 Response Document Changes"
15:50:56 <sriram> awesome, we can talk about that.
15:51:03 <kgriffs> but we should check with Fei to see if he has started those or not
15:51:04 <Obulpathi> ok ...
15:51:15 <Obulpathi> abettadapur: Good work :)
15:51:20 <kgriffs> Obulpathi: watch for flwang in IRC and catch him if you can. :)
15:51:47 <Obulpathi> kgriffs: ok
15:51:58 <kgriffs> abettadapur: is there a patch submitted already?
15:52:05 <kgriffs> #link https://blueprints.launchpad.net/marconi/+spec/api-v1.1-header-changes
15:52:15 <abettadapur> no there isn't
15:52:24 <abettadapur> it would be rejected by jenkins, so i havent done that
15:52:39 <kgriffs> ok, I was just making sure since I didn't see a reference on the whiteboard
15:52:50 <kgriffs> abettadapur: remind me what your launchpad ID is?
15:53:01 <abettadapur> abettadapur i think
15:53:12 <abettadapur> no
15:53:14 <abettadapur> alexbettadapur
15:53:34 <kgriffs> abettadapur: ok, you are now assigned to the bp
15:53:41 <abettadapur> ok
15:53:45 <kgriffs> it's all official now
15:53:46 <kgriffs> :)
15:53:52 <Obulpathi> :)
15:54:06 <kgriffs> vkmc: are you going to be working on this? https://blueprints.launchpad.net/marconi/+spec/storage-amqp
15:54:26 <vkmc> kgriffs, I'm yeah
15:55:22 <vkmc> kgriffs, I wanted to hear your opinion about what AMQP version to support
15:55:34 <vkmc> yours and everyone else in Marconi of course
15:56:24 <kgriffs> vkmc: btw, I assigned the bp to you, and also set you as "drafter". That means it's up to you to come up with a design and get flaper87's blessing. :)
15:56:39 <kgriffs> vkmc: who is your mentor?
15:56:41 <vkmc> kgriffs, thanks for that
15:56:46 <vkmc> kgriffs, alcabrera and flaper87 :)
15:56:50 <kgriffs> ok
15:57:46 <kgriffs> re 0.9 vs. 1.0
15:57:57 <kgriffs> Flavio is discussing the state of 1.0 in RabbitMQ
15:58:43 <vkmc> I see, great
15:58:46 <kgriffs> I think if we can get the rabbit team to commit to doing a little more work on their 1.0 plugin, 1.0 is the way to go
15:59:11 <kgriffs> vkmc: so, I'd sync up with flaper87|afk on that
15:59:35 <vkmc> cool!
15:59:44 <vkmc> just one thing I'm doubtful about...
16:00:31 <vkmc> I saw that oslo.messaging is adding support for AMQP 1.0 https://blueprints.launchpad.net/oslo.messaging/+spec/amqp10-driver-implementation too
16:00:53 <vkmc> isn't Oslo a common lib which we might use?
16:01:19 <dims> vkmc, it's not ready yet
16:01:22 <adrian_otto> kgriffs: all done?
16:01:25 <kgriffs> vkmc: we won't use it as a backend per se, but we might use it to RPC to other services
16:01:29 <kgriffs> adrian_otto: yep
16:01:33 <adrian_otto> tx
16:01:38 <thomasem> o/
16:01:40 <kgriffs> ok folks, let's wrap this up
16:01:48 <kgriffs> thanks everyone!
16:01:51 <kgriffs> #endmeeting