15:04:30 <kgriffs> #startmeeting Marconi
15:04:31 <openstack> Meeting started Tue Feb 18 15:04:30 2014 UTC and is due to finish in 60 minutes.  The chair is kgriffs. Information about MeetBot at http://wiki.debian.org/MeetBot.
15:04:32 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
15:04:34 <flaper87> erm, you've to start the meeting
15:04:34 <alcabrera> yaaay
15:04:35 <openstack> The meeting name has been set to 'marconi'
15:04:35 <flaper87> :D
15:04:41 <flaper87> w00t
15:04:42 <alcabrera> #link https://wiki.openstack.org/wiki/Meetings/Marconi#Agenda
15:04:51 <flaper87> guntss gungts gungts
15:04:51 <alcabrera> we have a lovely schedule today
15:04:55 <kgriffs> yes
15:05:02 <kgriffs> I'm sure we will get done early. ;)
15:05:09 <malini> o/
15:05:23 <kgriffs> #topic roll call
15:05:28 <kgriffs> o/
15:05:30 <flaper87> o/
15:05:34 <sriram> o/
15:05:35 <alcabrera> \o/
15:05:36 <balajiiyer> o/
15:05:39 <malini> o/ - for real now
15:05:40 <flaper87> \o/
15:05:53 <flaper87> \o/
15:05:58 * alcabrera notes that flaper87 is present twice, no, thrice
15:05:59 <mpanetta> ~o~
15:06:11 <flaper87> mpanetta: you break dancing ?
15:06:18 <balajiiyer> I would like to take this opportunity and introduce Sriram!
15:06:21 <mpanetta> ;)
15:06:33 <malini> welcome back Sriram!!
15:06:41 <alcabrera> w00t
15:06:54 <sriram> hey guys! :)
15:07:08 <kgriffs> wilkommen!
15:07:16 <balajiiyer> Sriram joined us full-time recently and is no stranger to Marconi. He spent some time while he was interning with us.
15:07:51 * kgriffs thinks he came back just for the jokes in #openstack-marconi
15:08:06 <malini> :D
15:08:17 <sriram> yeah, was a good time. Looking forward to getting back into the groove again :D
15:08:18 <kgriffs> sriram: excellent, glad to have you back, man
15:08:40 <kgriffs> ...without that pesky "college" thing getting in the way this time. ;)
15:08:55 <flaper87> sriram: welcome :D
15:09:00 <sriram> kgriffs: haha :)
15:09:00 <kgriffs> #topic Atlanta Summit
15:09:08 <sriram> flaper87: thank you! :)
15:09:22 <kgriffs> so, summit
15:09:39 <kgriffs> talks?
15:09:44 <alcabrera> yup - that's a thing, and it's coming soon-ish
15:09:52 <alcabrera> we've submitted (afaik) two sessions
15:10:02 <kgriffs> alcabrera: so, the talk and workshop were submitted?
15:10:06 <alcabrera> yup!
15:10:08 <kgriffs> ok
15:10:18 <flaper87> we're all set
15:10:19 <alcabrera> Marconi: Please Leave a Message and Hands-on w/ Marconi
15:10:20 <sriram> cool!
15:10:21 <flaper87> we now need votes
15:10:27 <kgriffs> I looked at the latest draft on the etherpad and it seems like the talk is going to be all about teh features?
15:10:32 <flaper87> and prepare to whatever is comming
15:11:00 <alcabrera> kgriffs: that's mostly the case - :what's the future look like?:
15:11:02 <ametts> I can spread the word for votes here in Atlanta.
15:11:06 <kgriffs> It would be cool if we could somehow show the features in action or translated to real-world use cases rather than just spending 40 min hand-waving
15:11:31 <kgriffs> anyway, that's my $0.02
15:11:39 <flaper87> TBH, I'm kinda wishing that just the workshop will get accepted. The reason is that I think that'll be our best chance to showcase marconi
15:11:39 <ametts> kgriffs says that for every summit :)
15:11:48 <sriram> building a model supply chain using the queues would be super cool :)
15:11:49 <kgriffs> I haven't checked yet, but has voting opened already?
15:11:58 <flaper87> kgriffs: nop
15:12:00 <alcabrera> #note Marconi: Please Leave a Message - chock full of demo power
15:12:12 <flaper87> we can still change the abstract
15:12:13 <flaper87> AFAIK
15:12:48 <kgriffs> ok, I guess we can see what happens. If both are accepted, Hopefully the talk will get scheduled before the workshop and can serve for advertising
15:13:03 <alcabrera> I hope so, too. That'd be ideal.
15:13:21 <ametts> Maybe we could showcase a real customer.
15:13:34 <kgriffs> ametts: I think that would be great for the talk!
15:14:05 <kgriffs> megan_w: ^^^
15:14:54 <balajiiyer> kgriffs: I will talk to Megan about this
15:15:01 <flaper87> awesome!
15:15:11 <kgriffs> ok, so it looks like several of us will need to carve out some time to work on content once the votes are in, assuming *something* is accepted.
15:15:21 <alcabrera> +1
15:15:24 <flaper87> +1
15:15:27 <balajiiyer> +1
15:15:38 <ametts> That's what May 11th is for :)
15:15:39 <kgriffs> #action balajiiyer to follow up with Megan and get us a case study for the summit talk
15:15:48 <kgriffs> ametts: lol
15:15:59 <flaper87> ametts: it could also be May 16th, it depends on when the talk is scheduled
15:16:02 <flaper87> :D
15:16:04 <alcabrera> lol
15:16:09 <ametts> flaper87:  Good point.
15:16:37 <kgriffs> moving on...
15:16:40 <kgriffs> design sessions
15:16:47 <kgriffs> everyone be thinking about topics for those
15:16:53 <flaper87> I have
15:16:59 <balajiiyer> I would love to host a design session on notifications
15:17:06 <kgriffs> +1
15:17:07 <flaper87> balajiiyer: +1
15:17:20 <sriram> yeah that would be great.
15:17:40 <kgriffs> we had talked about proposing a cross-team session on versioning APIs
15:17:47 <flaper87> I think June is a great time to start the work on notifications
15:18:00 <flaper87> kgriffs: I've heard that probably that will happen
15:18:16 <flaper87> kgriffs: in that case the session won't count as Marconi's but cross-project
15:18:16 <kgriffs> also, flaper87 you probably want to do one around your work with API architecture, schemas, and stuff
15:18:32 <kgriffs> flaper87: yep!
15:18:34 <flaper87> yeah and I'd like to add queue flavors
15:18:45 <kgriffs> ah yes
15:18:49 <alcabrera> queue flavors will be exciting!
15:18:53 <sriram> queue flavors?
15:18:59 <flaper87> I strongly believe we should kick the work there off
15:19:52 <alcabrera> sriram: it's a declarative way to handle message storage. If you declare a queue with a 'fast' flavor, it might be the case that a redis-like backend will be chosen for you.
15:19:55 <flaper87> sriram: TL;DR: Allow to create different queues based on flavor tags
15:20:00 <alcabrera> similarly for 'durable', etc
15:20:14 <sriram> whoa, this is awesome! :D
15:20:15 <alcabrera> it's applicable in a sharded context
15:20:24 <alcabrera> :)
15:20:30 <flaper87> ok, those are the 2 I'd like to proposa and perhaps talk about fi they're accepted
15:21:31 <flaper87> propose*
15:21:43 <flaper87> kgriffs: knock knock ?
15:21:54 <flaper87> is my internet connection working?
15:22:00 <mpanetta> yes
15:22:05 <kgriffs> kk, sounds like we have some good ideas. Let's keep brainstorming and everyone feel free to submit session topics when that opens
15:22:34 <alcabrera> +1 - let's talk more design sessions when those open up
15:22:58 <balajiiyer> +1
15:22:59 <kgriffs> #topic SQL Alchemy
15:23:26 <alcabrera> so, lovely progress here, thanks to the efforts of flaper87 and ykaplan!
15:23:34 <balajiiyer> awesome
15:23:47 <alcabrera> we have one patch in the review queue for each of the needed controllers
15:23:53 <alcabrera> shards, catalogue, claims, messages, queues
15:23:59 <alcabrera> they all need some work, a little more love
15:24:01 <alcabrera> but we're close
15:24:03 <alcabrera> very close
15:24:14 <kgriffs> balajiiyer: I'd appreciate your reviews there too, esp. to sanity-check schema and stuff since you have SQL ninja skills
15:24:46 <balajiiyer> kgriffs: ok
15:24:53 <kgriffs> rock on
15:25:18 <kgriffs> alcabrera: any help/action you guys need besides reviews?
15:26:01 <alcabrera> hmm
15:26:07 <alcabrera> reviews, mostly
15:26:11 <kgriffs> ok
15:26:14 <alcabrera> I think that'll take care of the bulk of the work
15:26:17 <alcabrera> #link https://review.openstack.org/#/q/status:open+project:openstack/marconi+topic:bp/sql-storage-driver,n,z
15:26:18 <flaper87> yeah
15:26:19 <alcabrera> for reference
15:26:23 <kgriffs> let's git-r-done
15:26:31 <alcabrera> #note sql-driver needs reviews : all controllers are in the review queue
15:26:36 <flaper87> so, the work is pretty much done, ykaplan is making sure unittets are all set
15:26:37 <alcabrera> #note great progress
15:26:50 <flaper87> alcabrera: isn't it #info ?
15:26:54 <alcabrera> hmmm
15:26:58 <alcabrera> I think you're right
15:27:00 <alcabrera> :P
15:27:04 <flaper87> :D
15:27:16 <alcabrera> #info sql-driver needs reviews : all controllers are in the review queue
15:27:20 <alcabrera> #info great progress
15:27:26 * alcabrera felt notable today
15:27:29 <kgriffs> #topic Pecan evaluation
15:27:38 <kgriffs> balajiiyer, alcabrera
15:27:39 <alcabrera> oh goodness - so much to say here
15:27:46 <alcabrera> balajiiyer: want to open this up for us?
15:27:46 * flaper87 takes his lightsaber off
15:28:05 <balajiiyer> alcabrera: you start off with your comments, I will support it with the doc I have written :)
15:28:06 * kgriffs turns on his implanted objectifier
15:28:28 <alcabrera> kk
15:28:30 <alcabrera> well...
15:28:32 <alcabrera> hmm...
15:28:54 <alcabrera> So balajiiyer and I gave it a strong effort to see how we might support marconi under pecan
15:29:11 <alcabrera> It was painful, to say the least
15:29:21 <alcabrera> Objectively describing those pains is the challenging part
15:29:41 <alcabrera> I think, probably, the one thing that made it difficult to provide a modular solution, was pecan's object-based routing system
15:29:45 <kgriffs> is it kinda like how some people just "get" recursion, but other's don't, based on how your brain works?
15:30:00 <kgriffs> </random-thought>
15:30:10 <alcabrera> That might be part of the case.
15:30:13 <malini> we should also compare the number of github stars ;)
15:30:26 <alcabrera> And working with an object-based routing system might be okay over the long run
15:30:37 <alcabrera> and it even *seemed* like it would help modularization
15:30:39 <alcabrera> except
15:30:40 <kgriffs> malini: that might imply that more people's brains work like Falcon than Pecans. ;)
15:30:58 <alcabrera> the way to establish a RootController (which handles '/')
15:31:01 * kgriffs shuts up and listens
15:31:05 <alcabrera> doesn't allow for arguments to be passed in
15:31:07 <alcabrera> so
15:31:12 <alcabrera> things like storage, configuration, and caching
15:31:17 <flaper87> alcabrera: did you guys push this code somewhere?
15:31:18 <alcabrera> thsoe suddenly become globals
15:31:26 <alcabrera> balajiiyer: link to repo?
15:31:47 <flaper87> can I ask something? or do you want to finish up your comments first ?
15:31:55 <balajiiyer> https://github.com/balajiiyer/marconi/tree/Pecan
15:32:01 <kgriffs> alcabrera: can those not be somehow attached to per-request context?
15:32:21 <flaper87> alcabrera: At this point I'm mainly curious about:
15:32:24 <alcabrera> flaper87: I'll answer kgriffs' question then you go. :)
15:32:26 <alcabrera> so
15:32:36 <alcabrera> kgriffs: no. Request objects are globally imported.
15:32:37 <kgriffs> I suppose they could via a hook or something, but probably hacky
15:32:41 <alcabrera> from pecan import request
15:32:41 <balajiiyer> This is a WIP, queues controller is fully implemented, working on messages controller
15:33:05 <alcabrera> flaper87: what are your thoughts?
15:33:11 <flaper87> 1. What did it mean in terms of implementation details to support Pecan? How much did the API implementation had to change and whether it was improved or not by using Pecan?
15:33:51 <alcabrera> hmmmm
15:33:51 <balajiiyer> It didnt look like an improvement to me.
15:34:06 <alcabrera> so, the way it was headed, it would've been a single file implementation
15:34:06 <flaper87> 2. Do we depend on all the serialization methods / objects provided by pecan?
15:34:35 <kgriffs> That implies WSME, nicht?
15:34:59 <balajiiyer> flaper87: pecan doesnt offer serialization natively, will use WSME for that
15:35:16 <alcabrera> re 1: there's no support for PATCH or HEAD
15:35:17 <flaper87> balajiiyer: yeah, sorry, I meant to ask if we depend on WSME objects
15:35:23 <dhellmann> pecan has json support: http://pecan.readthedocs.org/en/latest/pecan_jsonify.html?highlight=json#module-pecan.jsonify
15:35:26 <dhellmann> you don't need to use wxme
15:35:27 <dhellmann> wsme
15:35:32 <flaper87> dhellmann: awesome, thanks
15:35:42 <flaper87> so, that's something we can improve in the implementation
15:35:47 <balajiiyer> Pecan's json serialization effort with jsonify might work for small projects
15:35:47 <flaper87> in case you guys didn't know that
15:36:09 <dhellmann> balajiiyer: if you have your own serializer, that works too
15:36:18 <dhellmann> I'm just correcting factual misstatements
15:36:26 <alcabrera> dhellmann: thanks!
15:36:31 <balajiiyer> dhellmann: got it, thanks
15:37:08 <alcabrera> what else...
15:37:10 <alcabrera> ah
15:37:17 <flaper87> alcabrera: balajiiyer I think you guys should talk to ryanpetrello, dhellmann and see if the implementation you have can be improved
15:37:17 <alcabrera> I haven't quite figured out how to represent particular queue objects
15:37:24 <alcabrera> so, /v1/queues/{queue}
15:37:33 <flaper87> I really want to make sure we're doing things right with Pecan
15:37:43 <kgriffs> +1
15:37:45 <dhellmann> alcabrera: did you look at the way ceilometer manages meters?
15:38:06 <alcabrera> dhellmann: no
15:38:11 <alcabrera> I've glanced at the ceilometer project, so far
15:38:42 <dhellmann> alcabrera: check out the MetersController and MeterController in http://git.openstack.org/cgit/openstack/ceilometer/tree/ceilometer/api/controllers/v2.py
15:39:06 <dhellmann> alcabrera: the _lookup() method in MetersController was working around a bug which has since been fixed in pecan, so that's not needed
15:39:10 <alcabrera> ah, overriding _lookup
15:39:19 <alcabrera> that makes sense
15:39:29 <dhellmann> you don't actually need that, you can use get() or get_one()
15:39:51 <alcabrera> I see.
15:40:11 <alcabrera> it's definitely a very different way of thinking than with falcon, so that's some relearning to do. :)
15:40:53 <alcabrera> I'm surprised that
15:41:00 <kgriffs> balajiiyer: you hadn't done much with falcon before, so is it less "relearning" and just "learning" for you?
15:41:01 <alcabrera> All of ceilometer's API seems to be implemented in a single file
15:41:12 <dhellmann> alcabrera: it's fairly small
15:41:20 <dhellmann> but that's not a requirement, it just worked out that way
15:41:41 <ryanpetrello> kgriffs: awhile back, I shared w/ you a subclass of the Pecan routing that I'd written
15:41:51 <ryanpetrello> that uses Falcon's style of routing rather than object dispatch
15:42:10 <ryanpetrello> do you recall that link?  I believe it was a gist, and am trying to find it
15:42:17 <kgriffs> hmmm
15:42:20 * kgriffs goes to look
15:42:26 <ryanpetrello> if it's the object dispatch routing that bothers you all, it's not so difficult to do it another way
15:42:43 <balajiiyer> kgriffs:  yeah, "learning" part was mostly trying to figure out how to fit it in the context of Marconi.
15:43:09 <ryanpetrello> as for the comments on global configuration, global req+resp objects, that *is* an intended feature of pecan
15:43:17 <ryanpetrello> and it uses threadlocals, in much the same way that e.g., flask does
15:43:27 <alcabrera> hmmm
15:43:59 <ryanpetrello> so it's different from the approach that e.g., pyramid uses, where you have req and resp arguments passed to every controller
15:44:16 <alcabrera> why is it an intended feature of pecan, to expose those things as globals, especially req/resp?
15:44:28 <ryanpetrello> mostly for convenience
15:44:36 <ryanpetrello> because of the @expose() serialization approach in pecan
15:44:42 <kgriffs> ryanpetrello: ok, so sounds like that approach is baked into Pecan's philosophy, which reflects the broader Python community camps of global/thread-local vs. arg passing
15:44:44 <ryanpetrello> how you generally have a controller returning a dictionary
15:44:51 <ryanpetrello> it's not as common to interact with the response directly
15:45:02 <ryanpetrello> you don't have to manually do a response.body = serialize_json(...)
15:45:09 <ryanpetrello> it's handled by the @expose decorator
15:45:16 <alcabrera> I see.
15:45:27 <kgriffs> interesting
15:45:28 <ryanpetrello> so given that many pecan controllers don't interact w/ the req/resp directly (the framework does it for you)
15:45:38 <ryanpetrello> these objects are provided in thread local context for situations where you *do* want to monkey with them
15:45:42 <ryanpetrello> e.g., setting custom response headers
15:46:07 <oz_akan_> team, I need help with feedbacks on this https://stackedit.io/viewer#!provider=gist&gistId=9071601&filename=marconi-installation-guide
15:46:24 <oz_akan_> that is marconi installation guide, that I am writing
15:46:25 <ryanpetrello> kgriffs: re your comment on philosophy, yes, exactly that
15:46:40 <oz_akan_> need to finish today, so not state of art
15:47:00 <kgriffs> oz_akan_: kk, stand by and we'll give you the floor in a minute
15:47:14 <ryanpetrello> okay, found that code, kgriffs
15:47:26 <alcabrera> ryanpetrello: thanks for searching!
15:47:33 <ryanpetrello> https://github.com/ryanpetrello/falcon/commit/a380bafdec6b8217edb6a59cebd94dfd3b408ecb
15:47:41 <ryanpetrello> I tinkered on this around the last summit
15:47:43 <kgriffs> #link https://github.com/ryanpetrello/falcon/commit/a380bafdec6b8217edb6a59cebd94dfd3b408ecb
15:47:56 <ryanpetrello> sse falcon/bench/nuts.py
15:48:09 <ryanpetrello> it's a subclass of the Pecan app that does Falcon-style routing
15:48:18 <ryanpetrello> this is just a naive example (it uses Falcon code, in fact)
15:48:20 <kgriffs> kk
15:48:33 <ryanpetrello> but it just goes to show that you don't *have to* use the object dispatch if you don't want it
15:48:40 <alcabrera> that's very good to know
15:48:58 <kgriffs> yep
15:49:15 <alcabrera> so, next steps for pecan - are there any specific questions we'd like to see addressed with further evaluation?
15:49:29 <kgriffs> so, we need to consider all the factors. If it comes down to object dispatch, then we have a workaround there.
15:49:51 <kgriffs> alcabrera: I still want to see benchmarks
15:50:09 <mpanetta> +1
15:50:12 <balajiiyer> kgriffs:  yes, I will working on it, now that I have a controller working
15:50:17 <balajiiyer> *I will be
15:50:53 <kgriffs> ryanpetrello: Doing a bit of modification to the router layer is cool; what I don't want to see happen is we go down the rabbit hole of basically rewriting Falcon inside Pecan; then it's like, what's the point?
15:51:03 <dhellmann> kgriffs: +1
15:51:13 <alcabrera> #note pecan evaluation: let's see some benchmarks, marconi:falcon, marconi:pecan
15:51:18 <alcabrera> #info pecan evaluation: let's see some benchmarks, marconi:falcon, marconi:pecan
15:51:26 <kgriffs> so other next steps
15:52:13 <ryanpetrello> kgriffs: +1
15:52:23 <ryanpetrello> that said, the routing portion of falcon is pretty simple, certainly more simple than what pecan does
15:52:33 <ryanpetrello> my concern more lies in a re-implementation of what webob provides
15:52:48 <alcabrera> what does webob provide?
15:52:59 <alcabrera> I suppose that's a rather broad question. :P
15:53:01 <ryanpetrello> a decade of experience and stability :)
15:53:04 <alcabrera> heh
15:53:09 <ryanpetrello> and the support of a *much* larger community
15:53:11 <ryanpetrello> Pyramid
15:53:15 <kgriffs> I'd like to see alcabrera and balajiiyer look at ceilometer and work with ryanpetrello to make sure our POC is done the "Pecan Way"
15:53:31 <kgriffs> ryanpetrello: so, that is a valid concern, and I don't want to discount that
15:53:32 <kgriffs> but
15:53:35 <ryanpetrello> (well, much larger *web framework* community, I should say)
15:53:43 <kgriffs> there are significant downsides to webob
15:53:59 <kgriffs> and Falcon has extensive test coverage and is being picked up by a lot of people
15:54:07 <kgriffs> so, it isn't all black-and-white
15:55:04 <kgriffs> I mean, you could make the same argument about Django vs. Pecan
15:55:27 <ryanpetrello> yep, very true
15:55:37 <ryanpetrello> (all true)
15:55:43 <ryanpetrello> so let me know how I can help w/ reviews and provide feedback
15:55:50 <ryanpetrello> looking at the implementation I saw above, it looks like you all are on the right track
15:56:04 <alcabrera> let's submit small patches to gerrit from here on, balajiiyer
15:56:07 <kgriffs> ryanpetrello: thanks for your support!
15:56:07 <ryanpetrello> but if there's a sticking point in certain areas of Pecan, ask me, and I'm happy to provide advice on what alternatives might look like
15:56:10 <ryanpetrello> yup, n
15:56:11 <ryanpetrello> *np
15:56:45 <alcabrera> ryanpetrello: thanks! I appreciate it. Looks like we'll need a lot of help to take advantage of idiomatic pecan. :)
15:56:46 <kgriffs> also, keep in mind that if it isn't something core to Pecan's design philosophy, we have the opportunity to send pull requests. :)
15:57:15 <balajiiyer> that would be my next question - I was thinking this will be like a POC, not necessarily belongs in Marconi master. kgriffs do you want me to submit patches for pecan work?
15:57:37 <kgriffs> balajiiyer: hmmm, well.
15:57:50 <kgriffs> You could always submit it flagged as WIP so we can all see it
15:58:00 <alcabrera> +1
15:58:34 <balajiiyer> Pecan is now a separate transport driver so it doesnt interfere with any other modules, so that could work
15:58:50 <alcabrera> marconi.queues.transport.pecan
15:59:26 <alcabrera> we're almost out of time - any other thoughts? :)
15:59:42 <kgriffs> man, where's the time go?!
15:59:49 <alcabrera> flaper87 ate it
15:59:55 <kgriffs> final thought
16:00:07 <kgriffs> please review api v1.1 stuff
16:00:13 <sriram> +1
16:00:39 <openstack> adrian_otto: Error: Can't start another meeting, one is in progress.  Use #endmeeting first.
16:00:44 <kgriffs> thanks everyone!
16:00:46 <kgriffs> ttfn
16:00:49 <kgriffs> #endmeeting