15:01:10 <kgriffs> #startmeeting marconi
15:01:11 <openstack> Meeting started Tue Jun 10 15:01:10 2014 UTC and is due to finish in 60 minutes.  The chair is kgriffs. Information about MeetBot at http://wiki.debian.org/MeetBot.
15:01:12 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
15:01:14 <openstack> The meeting name has been set to 'marconi'
15:01:14 <kgriffs> #topic roll call
15:01:17 <kgriffs> o/
15:01:18 <alcabrera> o/
15:01:30 <sriram> \o/
15:01:42 <malini1> o/
15:01:44 <flaper87> o.
15:01:48 <abettadapur> O
15:01:55 <malini1> ?
15:02:27 <sriram> are we approaching the land of regexes? :P
15:02:45 <tjanczuk> hello
15:03:05 <flaper87> we've got a bunch of things to discuss today and I'd really get to the unified API discussion
15:03:12 <tjanczuk> +1
15:03:18 <flaper87> lets move forward
15:03:19 <kgriffs> yep. that's the big item
15:03:27 <kgriffs> #topic review actions from last time
15:03:46 <kgriffs> megan_w to check trademarks for our shortlist of names
15:04:16 <kgriffs> megan_w: u there?
15:04:59 <kgriffs> ok
15:05:03 <kgriffs> let me pretend to be megan
15:05:04 <kgriffs> "Our trademark counsel did a search and recommended Zaqar or Naav as the best potential names with low-to-moderate risk. Tamtam came up as a moderate risk based on TamTamy, but we could still likely pursue it because the software is quite distinguishable. Both Raven and Copper pose a higher risk, because they are registered to companies in dev / cloud spaces (Ravenflow and Copper.io respectively)."
15:05:14 <kgriffs> "Do you think your team would be happy moving forward with Zaqar, Naav or Tamtam?"
15:05:57 <kgriffs> do we want to pick one of these or do another round of brainstorming?
15:05:59 <flaper87> kgriffs: can we do a vote now?
15:06:09 <flaper87> I'm happy to vote now and move this forward
15:06:20 <tjanczuk> +1
15:06:30 <flaper87> you could set a vote poll and use each one of those names as options
15:06:31 <tjanczuk> (do I get a vote?)
15:06:32 <malini1> Can someone enlighten me real quick on how to pronounce Zaqar?
15:06:45 <malini1> tjanczuk: everybody does
15:07:07 <kgriffs> malini1: I think it is za'kar ?
15:07:15 <vkmc> o-
15:07:20 <vkmc> o/
15:07:22 <flaper87> but we only take under consideration kgriffs vote because this is democracy
15:07:23 <tjanczuk> malini1: thanks. and yes, I think that is one problem with Zaqar and Naav - it needs to come with spelling instructions
15:07:25 <malini1> hmmm….http://en.wikipedia.org/wiki/Zaqar
15:07:26 <flaper87> muahahha muahahha muahahahhaa
15:07:37 <tjanczuk> Oh, I am used that kind ;)
15:07:48 <malini1> lets vote
15:08:04 <flaper87> but pronouncing tamtam is fun, it seems like we're selling chume-gums
15:08:07 <kgriffs> yes, the pronunciation/spelling did concern be a little too
15:08:27 <tjanczuk> aren't we?
15:08:40 <malini1> I tried to remember tamtam & it ended up as dumdum in my brain
15:08:42 <flaper87> tjanczuk: nope, just gummy bears and pop-tarts
15:08:45 <flaper87> :D
15:08:51 <flaper87> malini1: lol
15:08:52 <malini1> we need an easily memorizable name
15:08:56 <flaper87> kgriffs: voooooooooooooooooooooooooooooooooooooooooooote
15:09:28 <kgriffs> what did tamtam mean again?
15:09:29 <sriram> I'd go with Naav ;)
15:09:38 <flaper87> I like Naav because it's easy to write, short and it's from a language I don't know
15:09:58 <tjanczuk> tamtam is a kind of a drum that was used to send signals before internet. OK, well before internet.
15:10:03 <flaper87> and all those are scientifically provable points
15:10:15 <flaper87> tjanczuk: LOL
15:10:18 <kgriffs> #startvote Zaqar, Naav, Tamtam, Abstain
15:10:18 <malini1> kgriffs: tamtam is  a drum, rt tjanczuk ?
15:10:18 <openstack> Unable to parse vote topic and options.
15:10:29 * kgriffs can't remember the syntax
15:10:31 <kgriffs> one moment
15:10:44 <malini1> kgriffs: https://www.google.com/search?q=tamtam&espv=2&source=lnms&tbm=isch&sa=X&ei=6R-XU_SGNMqNyATQuoKgCA&ved=0CAYQ_AUoAQ&biw=1152&bih=586
15:10:54 <tjanczuk> http://en.wikipedia.org/wiki/Drums_in_communication
15:10:54 <kgriffs> ah, forgot the question
15:10:55 <kgriffs> silly me
15:11:28 <kgriffs> #startvote What should Marconi's new name be? Zaqar, Naav, Tamtam, Abstain
15:11:29 <openstack> Begin voting on: What should Marconi's new name be? Valid vote options are Zaqar, Naav, Tamtam, Abstain.
15:11:30 <openstack> Vote using '#vote OPTION'. Only your last vote counts.
15:11:36 <flaper87> #vote Naav
15:11:38 <alcabrera> #vote Naav
15:11:43 <tjanczuk> #vote tamtam
15:11:44 <sriram> #vote Naav
15:11:46 <abettadapur> #vote Naav
15:11:47 <kgriffs> #vote Naav
15:11:56 <prashanthr_> Naav since i suggested it ;)
15:11:58 <vkmc> #vote Zaqar
15:11:58 <tjanczuk> democracy at work...
15:11:58 <malini1> #vote tamtam
15:12:02 <vkmc> (it's epic)
15:12:21 <flaper87> prashanthr_: you've to use the #vote OPTION syntax
15:12:29 <prashanthr_> #vote Naav
15:12:57 <flaper87> Giving talks about Naav will be fun
15:13:13 <kgriffs> closing the vote in 10 seconds
15:13:15 <tjanczuk> You will now have two projects on your resume ;)
15:13:17 <malini1> Naav is tongue in my mothertongue :D
15:13:18 <flaper87> 9
15:13:21 <flaper87> 8
15:13:24 <flaper87> 7
15:13:26 <flaper87> 6
15:13:27 <flaper87> 5
15:13:29 <flaper87> 4
15:13:32 <flaper87> 3
15:13:34 <flaper87> 2
15:13:34 <kgriffs> #endvote
15:13:35 <openstack> Voted on "What should Marconi's new name be?" Results are
15:13:36 <flaper87> 1
15:13:37 <openstack> Zaqar (1): vkmc
15:13:37 <kgriffs> race condition
15:13:38 <flaper87> 0
15:13:38 <kgriffs> ;)
15:13:38 <openstack> Naav (6): alcabrera, kgriffs, abettadapur, sriram, flaper87, prashanthr_
15:13:39 <openstack> Tamtam (2): malini1, tjanczuk
15:13:55 <malini1> we are Project Naav now !
15:13:57 <sriram> \____/ -> Naav :P
15:13:59 <tjanczuk> Amen.
15:13:59 <flaper87> and we have a new name, Naav
15:14:05 <kgriffs> so it can mean boat or tongue?
15:14:06 * sriram needs better ascii art
15:14:07 <flaper87> now, to change everything
15:14:17 <kgriffs> oh boy
15:14:19 <malini1> quick somebody update devstack
15:14:24 <prashanthr_> Yaay :)
15:14:24 <sriram> LOL
15:14:27 <vkmc> :D
15:14:30 <flaper87> LOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOL
15:14:34 <prashanthr_> sriram: LOl quick art
15:14:40 <kgriffs> we will start the renaming next week after j-1 is cut
15:14:44 <flaper87> devstack, channel, mailing list tags, email filters, code, client,
15:14:51 <flaper87> AAHHHHH FUck trademarks, lets keep Marconi
15:14:52 <malini1> tempest
15:15:01 <kgriffs> #agreed Naav is the new Marconi
15:15:15 <tjanczuk> Seriously: I would consider the name change along with announcing the outcome of the [un]unificiation of APIs.
15:15:17 <flaper87> #agreed Marconi is the old Naav
15:15:23 <flaper87> ^^
15:15:23 <kgriffs> tjanczuk: noted
15:15:44 <kgriffs> let's come up with a game plan for Naav at next week's meeting
15:15:46 <malini1> arent we also changing the project/program name - whatever tht thing is which is currently 'queuing' ?
15:15:59 <flaper87> malini1: nope, just the codename for now
15:16:07 <kgriffs> malini1: possibly, but would be later
15:16:10 <malini1> ok
15:16:14 <flaper87> next topic ?
15:16:19 <kgriffs> ok, next
15:16:26 <kgriffs> flaper87: you took the words right out of my keyboard1
15:16:34 <kgriffs> #topic specs
15:16:50 <flaper87> :D
15:17:58 <kgriffs> How should we approach the proposed specs process?
15:18:00 <flaper87> so ?
15:18:02 <flaper87> :D
15:18:03 <kgriffs> go all in for j-2
15:18:09 <kgriffs> try it with one spec in j-2
15:18:19 <kgriffs> put it off until next cycle
15:18:21 <malini1> lets try one in j-2
15:18:23 <kgriffs> or
15:18:25 <flaper87> I would prefer not adopting the spec process until we reach the graduation point
15:18:29 <kgriffs> require it for all new feature proposals
15:18:30 <flaper87> TBH
15:18:48 <flaper87> Doing so means that we need to convert all blueprints that have been approved for J into specs
15:18:54 <flaper87> submit them, review them etc
15:19:06 <flaper87> this all will happen *after* we setup the repo, gate etc for our specs repo
15:19:07 <kgriffs> I had thought about trying it with one in j-2
15:19:15 <flaper87> and we've pretty ambitious goals for J
15:19:18 <malini1> I said let's try one, so we have a better understanding of the pros/cons
15:19:28 <kgriffs> but... would it be a pain to do most bp's one way, and one a different way.
15:19:46 <kgriffs> flaper87 has a good point
15:20:12 <kgriffs> we may not have bandwidth for implementing a new process right now
15:20:26 <kgriffs> let's vote
15:20:46 <flaper87> We can start setting up the whole thing in background (I can help with that) but lets not make J depend on it
15:20:57 <sriram> +1
15:21:02 <malini1> anybody has insights into if it'll become a grad req?
15:21:33 <flaper87> All new blueprints would go through that process but not existing ones and it's certainly not blocking our progress nor occupping our bandwidth
15:21:43 <flaper87> malini1: not yet but we can ask
15:21:53 <kgriffs> flaper87: yes, let's be sure to bring that up
15:22:01 <kgriffs> so...
15:22:09 <flaper87> I don't think so, yet. It started as an experiment so I think we should give the process more time before making it a grad request
15:22:15 <kgriffs> require new ones to go through the process, but not existing ones?
15:22:26 <malini1> kgriffs: starting when?
15:22:29 <flaper87> also, the important thing is to have things setup for future blueprints
15:22:54 <flaper87> Lets do this, I'll take care of it
15:23:04 <flaper87> I'll start setting up things for the marconi-spec
15:23:08 <flaper87> in background
15:23:15 <kgriffs> ok, let's start requiring new bps for j-2
15:23:18 <kgriffs> sorry
15:23:20 <flaper87> slowly and without requiring intervention from other folks in the team
15:23:23 <kgriffs> specs for new bps in j-2
15:23:26 <malini1> can we do a pilot on 1 or2 bps, so we don't come up with any absurd template ?
15:23:32 <flaper87> once that's done, we'll sync up again and decide
15:23:36 <kgriffs> so, if you have an idea, don't register a blueprint. submit a spec from now on
15:23:48 <kgriffs> malini1: mmm, good point
15:23:58 <flaper87> malini1: I think we can follow other projects templates
15:24:00 <kgriffs> we did talk about using template to keep things light and learn as we go
15:24:20 <malini1> flaper87: some of the other projects have really detailed specs
15:24:23 <kgriffs> flaper87: we may want to mark parts as optional or something if they become too time-consuming.
15:24:27 <malini1> I wud hate to write down all tht info
15:24:47 <flaper87> most of the parts in those templates are optional
15:24:48 <kgriffs> anyway, we can start with another project's template and adjust it for our needs
15:24:51 <flaper87> it's up to us, really
15:25:17 <kgriffs> ok, so for now let's just get the plumbing done and we can work on a template
15:25:22 <flaper87> it must evolve overtime, but I'd really hate to waste time on this when we've real code to write
15:25:24 <malini1> We should keep it really light weight, so it add value & doesnt become another process in the way
15:25:36 <kgriffs> malini1: we might use the Redis Pool as an experimental spec
15:25:36 <malini1> flaper87: +1
15:25:47 <kgriffs> alcabrera: ^^
15:25:50 <kgriffs> ok
15:25:55 <sriram> good point.
15:25:57 <kgriffs> let me drop an action and let's move on
15:26:18 <kgriffs> #action flaper87 to do the plumbing for specs
15:26:41 <alcabrera> redis pool sounds like a reasonable thing to experiment w/ spec-ing
15:27:06 <flaper87> topic++
15:27:31 <kgriffs> #topic FYI: Keystone token changes
15:27:40 <kgriffs> this is a quick one
15:28:03 <kgriffs> just wanted to make everyone aware of the work that is going on around keystone auth tokens
15:28:06 <kgriffs> http://markmail.org/message/2w7xzjq6i7mfcpez#query:+page:1+mid:7afzhoztzla4jgr3+state:results
15:28:55 <tjanczuk> 8K tokens? Is Keystone moving its database to cookies?
15:29:00 <kgriffs> basically, UUID tokens are probably going away, and so our HTTP request size is going to go up a little bit. Keystone team is trying to keep the size under control.
15:29:04 <flaper87> that work is quite important for us
15:29:16 <malini1> yayyy!!
15:29:25 <flaper87> they also mentioned they're trying to shrink it
15:29:38 <kgriffs> they are doing some algorithmic things to shrink it
15:29:42 <kgriffs> also compression
15:29:43 <tjanczuk> One more reason to look into websockets
15:29:48 <sriram> how much overhead would it add?
15:30:24 <kgriffs> I'm a little fuzzy on whether the keystone middleware will have to do decompression on each request, but I suspect so, and I've been encouraging the use of snappy or lz4 for that... we'll see
15:30:58 <kgriffs> tjanczuk: speaking of websockets, we will need to periodically check for revocation and token expiration
15:31:31 <kgriffs> anyway, something to start noodling on
15:31:44 <kgriffs> reply to the email thread with your thoughts/questions/concerns
15:31:44 <tjanczuk> even so I expect it to be less of an issue than doing to for every HTTP request
15:31:53 <kgriffs> tjanczuk: yep
15:32:01 <kgriffs> or we can just wait for HTTP 2.0
15:32:07 * kgriffs ducks
15:32:21 <flaper87> LOL
15:32:21 <kgriffs> #topic Discuss GET messages on a non existing queue returns 204
15:32:24 <tjanczuk> or quantum computin
15:32:29 <kgriffs> vkmc, alcabrera ^^^
15:33:11 <alcabrera> ah
15:33:13 <alcabrera> this bug
15:33:16 <alcabrera> #link https://bugs.launchpad.net/marconi/+bug/1243752
15:33:17 <uvirtbot> Launchpad bug 1243752 in marconi "GET messages on a non existing queue returns 204" [Low,In progress]
15:33:19 <vkmc> !
15:33:31 <alcabrera> iirc
15:33:44 <tjanczuk> what would you expect to see? 404?
15:33:44 <alcabrera> the question for this was - how do we want to address this for v1.0 vs. v1.1
15:33:52 <sriram> yes, it should be a 404
15:33:57 <alcabrera> I think v1.0 expects a 404, and v1.1 expects a 204
15:34:20 <flaper87> yup, I think just v1.0 should return 404
15:34:40 <alcabrera> cool
15:34:43 <flaper87> in v1.1 queues are lazy so, 204 seems correct
15:34:59 <vkmc> ok, so we have to change the behaviour in v1.0 and keep it in v1.1
15:35:00 <alcabrera> so we need to double check v1.0, fix it if it doesn't return 404, and then close off the bug. :)
15:35:35 <malini1> we decided to keep the 204 in 1.0 due to performance concerns
15:35:53 <alcabrera> ah
15:35:56 <tjanczuk> you mean one extra request to check if queue exists?
15:36:03 <malini1> IIRC we changed it to 204 from 404 after a benchmark
15:36:21 <kgriffs> with my caching patch, that will help perf
15:36:24 <malini1> tjanczuk: yes
15:36:34 <vkmc> it's semantically correct for v1.1 to return a 204, and also more efficient
15:36:41 <vkmc> I'm a bit concerned about tests
15:36:47 <vkmc> for this case
15:36:48 <flaper87> Should we worried about this v1.0 detail ?
15:36:53 <flaper87> worry*
15:37:00 <kgriffs> great question
15:37:10 <malini1> flaper87: I dont think we should
15:37:19 <flaper87> I mean, v1.1 will be out not far from now, the client semantics will remain the same
15:37:28 <flaper87> ok, then lets close it as won't fix
15:37:28 <kgriffs> TBH, nobody has complained that I am aware of.
15:37:36 <peoplemerge1> impact to existing clients?
15:37:44 <tjanczuk> Does this really boil down to whether you  think of queues as first class citizens? If first class -> 404. If not -> 204 is OK.
15:38:08 <kgriffs> peoplemerge1: basically, if a queue does not exist, we don't give them a hint to go create it first
15:38:15 <kgriffs> we just pretend it exists
15:38:18 <flaper87> tjanczuk: that's part of the reason, yes.
15:38:27 <flaper87> but I don't think that's enough of a reason to change v1.0
15:38:39 <flaper87> I'd just focus on v1.1 unless there's a critical issue to fix in v.10
15:38:41 <tjanczuk> I was thinking more of vNext
15:39:06 <kgriffs> ok, I am going to close this as won't fix unless anyone vehemently disagrees.
15:39:30 <alcabrera> works for me
15:39:34 <vkmc> works for me too
15:39:35 <malini1> This one keeps reappearing every 2 months :-S
15:39:49 <kgriffs> malini1: in what way? are we getting complaints?
15:40:28 <malini1> kgriffs: it keeps coming back from somebody in the team
15:40:36 <malini1> but not from any users
15:40:39 <kgriffs> ok
15:40:39 <kgriffs> #agreed close bug #1243752 as won't fix
15:40:40 <uvirtbot> Launchpad bug 1243752 in marconi "GET messages on a non existing queue returns 204" [Low,In progress] https://launchpad.net/bugs/1243752
15:40:55 <flaper87> topic++
15:40:57 <vkmc> we could mark it as a won't fix and add the reasons in the bug report
15:40:59 <sriram> yeah, I had some questions on this when I worked on lazy queue create.
15:41:25 <vkmc> just to keep track of it in the future
15:41:50 <kgriffs> speaking of that, and the fact that it would be sort of impossible to return 404 with an AMQP driver...
15:41:58 <malini1> On the same note, does it make sense to keep 'check queue existence' API with lazy queue in place for 1.1 ?
15:42:17 <malini1> sorry for jumping 2 topics ahead in the agenda
15:42:17 <flaper87> malini1: probably not
15:42:20 <kgriffs> malini1: probably not
15:42:26 <flaper87> kgriffs: seriously ?
15:42:39 <kgriffs> kgriffs: seriously?
15:42:40 <tjanczuk> it is possible with AMQP 0.0
15:42:41 <kgriffs> oops
15:42:42 <tjanczuk> 0.9
15:42:48 <malini1> kgriffs & flaper87 are in the same firmware version
15:42:51 * kgriffs can't let them know my secret
15:43:13 <flaper87> ok, lets move on
15:43:22 * kgriffs curses quantum entanglement
15:43:26 <kgriffs> #topic Reconsidering the unified API model
15:43:37 <tjanczuk> ununify!
15:43:57 <kgriffs> so...
15:44:03 <kgriffs> a nice light topic
15:44:06 <tjanczuk> I left my thoughts on the ML yesteday
15:44:15 <flaper87> I loved Mark's email
15:44:30 <tjanczuk> What were the key points?
15:44:35 <kgriffs> tjanczuk: if I understand correctly, you proposed an Option C - scrap the feed semantics and just do claims?
15:45:00 <tjanczuk> No, I proposed to make the queue semantics the "MUST", and anything else a "MAY"
15:45:15 <flaper87> Mark's email: http://lists.openstack.org/pipermail/openstack-dev/2014-June/037108.html
15:45:16 <tjanczuk> The exact mechanics of "MAY" are TBD
15:45:18 <kgriffs> oic
15:46:16 <kgriffs> I think Gordon had some good questions
15:46:31 <flaper87> we've 10mins left so, lets start throwing something out there
15:46:40 <tjanczuk> I am not sure I see how Mark's point is relevant to this unification topic?
15:46:43 <kgriffs> and I liked Mark's thoughts about "don't do it just because you feel pressured and you don't really see any value in it"
15:47:12 <flaper87> tjanczuk: it's not relevant to the unification topic but to how much we want to change our API/product based on the store driver
15:47:19 <flaper87> what benefits would all that bring?
15:47:25 <flaper87> do we really need it? etc etc etc
15:47:32 <flaper87> all those are valid questions
15:47:43 <kgriffs> flaper87: I think you made a good point that we don't know enough yet to make a good decision.
15:47:53 <flaper87> I really really really think we need to sort out what our base features are
15:48:02 <flaper87> what we want to deliver as part of marconi in terms of API
15:48:04 <kgriffs> personally, I think we need to see POC for AMQP and redis, do some benchmarks and see how they affect the api
15:48:06 <tjanczuk> I thought the unification topic is valid on its own, regardless of how many drivers Marconi (NaaV) aspires to support?
15:48:09 <flaper87> and what we want to kee as optional
15:48:21 <flaper87> kgriffs: agreed
15:48:28 <flaper87> vkmc: you around?
15:48:33 <flaper87> are you reading this?
15:48:51 <kgriffs> tjanczuk: I feel like they are interrelated. Since once of the pressures for splitting the API is the fact that it can't all be supported by AMQP
15:49:06 <kgriffs> splitting/reducing
15:49:23 <flaper87> I think our current API is valid as is to provide useful features and cover several scenarios. I'm not saying it is perfect, nor that we shouldn't change it
15:49:39 <flaper87> I'm saying that we need to have more information and experience to do that
15:49:49 <kgriffs> yes
15:49:52 <flaper87> Julien's and Doug's suggestions were good too
15:49:52 <kgriffs> one more point
15:50:10 <prashanthr_> kgriffs: Sure we can have a POC.
15:50:10 <malini1> we are running out of time
15:50:16 <kgriffs> actually, reiterating what flaper87 said earlier
15:51:29 <kgriffs> first, we must decide whether we want to simplify. Do we want to continue to support multiple messaging patterns?
15:51:53 <tjanczuk> I think that is exactly the top question to ask.
15:51:55 <malini1> sorry my brain interpreted 11:49 as 11:59, ignore my comment
15:52:06 <kgriffs> second, if we do, do we continue striving to do that by affordances, or by doing things that are more prescriptive, such as implementing the notion of exchanges
15:52:46 <kgriffs> the feeds portion of the API was designed to work at the level of affordances, meaning, here are some basic semantics that let you do several different things
15:53:08 <kgriffs> however, it can be difficult to map that to a broker such as AMQP
15:53:33 <tjanczuk> In general the broader the surface, the narrower the implementation choices.
15:53:43 <kgriffs> which brings us to the second question; what does support AMQP buy us?
15:53:44 <tjanczuk> Currently the only pragmatic implementation choices are DB based.
15:53:57 <kgriffs> tjanczuk: correct
15:54:07 <flaper87> kgriffs: note that this is not only true for AMQP
15:54:14 <flaper87> but lets use it as the reference
15:54:20 <flaper87> since it's the one we're working on
15:54:25 <tjanczuk> To me AMQP boils down to the benefit of being able to use backends folks already use and know how to operate. The protocol is really insubstantial.
15:54:27 <kgriffs> but I am not familiar with every broker out there, so we could be wrong
15:54:39 <flaper87> tjanczuk: I agree
15:54:45 <tjanczuk> (There may also be perf benefits, but that remains to be seen).
15:54:45 <flaper87> I think I mentioned this in the thread too
15:54:56 <kgriffs> well, sure, but many people also already know how to operate NoSQL
15:55:10 <tjanczuk> AGPL
15:55:12 <flaper87> lets also mention we bring something to those brokers too (an easier way to scale(TM))
15:55:30 <kgriffs> AGPL is a good point. Hence our experiment with Redis
15:55:30 <flaper87> that said, do we think this is enough of a reason to change the API ?
15:55:42 <kgriffs> flaper87: good point; the scaling thing
15:55:43 <flaper87> regardless our choice, I think we should still pursue the POC road
15:55:45 <tjanczuk> yes, that is a benefit, but currently it feels the cost is too large
15:56:21 <flaper87> I don't think redis is a drop-in replacement for mongodb
15:56:22 <flaper87> :/
15:56:23 <tjanczuk> So I did the POC on Rabbit. With current shape of APIs it is impossible to use Rabbit.
15:56:37 <kgriffs> (4 minutes)
15:56:43 <tjanczuk> The APIs just don't map to Rabbit capabilities.
15:56:43 <flaper87> tjanczuk: what things are supported?
15:57:14 <tjanczuk> Publishing a message. Currently you cannot even consume a message (at least until the POP change comes in).
15:57:16 <vkmc> flaper87, I am!
15:57:35 <tjanczuk> I can do a more details summary on ML after this.
15:57:47 <flaper87> tjanczuk: that would be awesome
15:57:55 <flaper87> thanks a lot for your work there
15:58:04 <flaper87> I'll put more thoughts on this
15:58:33 <flaper87> As a closing question, based on latest feedback: Would kafka be a better choice for now?
15:58:41 <tjanczuk> NP. I also had some thoughts on the "core" APIs and how they could be shaped such that one can support a broader set of backends (Mongo, AMQP etc). Anyone interested in seeing this?
15:58:46 <kgriffs> better choice than AMQP?
15:58:51 <flaper87> kgriffs: yup
15:59:05 <flaper87> as in, route efforts there and lets give AMQP more time
15:59:35 <flaper87> tjanczuk: yup
15:59:57 <flaper87> ok, I think we ran out of time
16:00:03 <kgriffs> TBH, more people have been asking for Kafka as a backend than Rabbit or Qpid, at least what I can tell
16:00:15 <tjanczuk> flapper87: check out this: https://github.com/tjanczuk/narconi#endpoint-synopsis
16:00:19 <kgriffs> flaper87: let's do a little POC or something for kafka
16:00:25 <flaper87> it was a great meeting. I'd love to follow up on #openstack-marconi
16:00:27 <kgriffs> final thought, then I will end meeting
16:00:30 <flaper87> kgriffs: Ok, I can play with that
16:00:38 <kgriffs> let's be careful not to let the tail wag the dog
16:00:43 <kgriffs> the API *is* the product
16:01:04 <tjanczuk> +++1
16:01:09 <flaper87> kgriffs: EXACTLY! well, said
16:01:13 <flaper87> well said*
16:01:20 <kgriffs> and several long-time openstacker's have cautioned us about trying to support too many backends
16:01:28 <kgriffs> saying, it will distract us from our mission
16:01:33 <kgriffs> that is all
16:01:37 <kgriffs> #endmeeting