19:06:48 <kgriffs> #startmeeting marconi
19:06:49 <openstack> Meeting started Thu Jun 20 19:06:48 2013 UTC.  The chair is kgriffs. Information about MeetBot at http://wiki.debian.org/MeetBot.
19:06:50 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
19:06:52 <openstack> The meeting name has been set to 'marconi'
19:06:57 <kgriffs> #topic actions from last time
19:07:00 <kgriffs> #link http://eavesdrop.openstack.org/meetings/marconi/2013/marconi.2013-06-13-19.06.html
19:07:36 <kgriffs> ok, so I added the bp for removing project id from the URI path
19:07:58 <kgriffs> the downside of doing that now is we can't, e.g., rate-limit based on project id
19:08:28 <kgriffs> I don't think OpenStack clients normally specify X-Project-ID; it's injected by keystone middleware
19:08:41 <kgriffs> anyone confirm or deny that?
19:09:38 <kgriffs> well, if anyone comes across more info on that topic, let me know
19:09:43 <malini> sure
19:09:57 <kgriffs> going down the list of actions
19:10:14 <kgriffs> flaper87 did indeed schedule the sqlalchemy for first half of H3
19:11:00 <kgriffs> i actually didn't have a chance this week to take another pass through the bps, but I think they are fairly up to date. Some things are not yet marked completed because we are missing tiny bits of functionality (e.g., getting multiple messages by id)
19:11:09 <kgriffs> but those should land in the next few days
19:11:11 * kgriffs cheers
19:11:14 <malini> cool
19:11:32 <kgriffs> Megan has been hard at work on the incubation request
19:11:44 <kgriffs> anything on that front that you'd like to share?
19:11:56 <megan_w> we're adding a few people to the list of developers
19:12:07 <megan_w> we should have something ready by mid next week
19:12:18 <kgriffs> oh, did you get Vicky on there?
19:12:26 <megan_w> i did not
19:12:29 <kgriffs> ok
19:12:30 <megan_w> but i will
19:12:37 <megan_w> vicky who?
19:12:50 <kgriffs> she was an OpenStack intern, currently in school in Argentina and has been helping a little with the client lib
19:12:54 <kgriffs> let me get her full name
19:13:03 <megan_w> and we also talked about adding a section for all of those who helped with the design, but not necessarily the code
19:13:23 <megan_w> i think this will help show that there has been true collaboration on the project
19:13:32 <kgriffs> Victoria Martínez de la Cruz < vickymsee@gmail.com>
19:13:42 <megan_w> great, I'll add her
19:14:04 <kgriffs> cool, OK.
19:14:25 <kgriffs> you can add John Hopper to the list of folks who contributed to the API design
19:14:32 <kgriffs> (he's a Racker)
19:14:50 <megan_w> k, will do
19:14:51 <kgriffs> can anyone think of other people to add?
19:15:16 <malini> do we already have zhihao, bryan , jamie ?
19:15:52 <megan_w> no, they are not on there.  I can add them as well.  are they actively working on it?
19:16:06 <kgriffs> oh, do we have Bryan Davidson and Zhihao Yuan
19:16:18 <kgriffs> let me pull up the contributors file
19:16:31 <kgriffs> ah, maybe we need a "past contributors" section
19:17:03 <kgriffs> oh, and Alejandro will soon start contributing
19:17:11 <kgriffs> (actively)
19:17:54 <megan_w> ok, i'll put an update list together.
19:17:59 <kgriffs> sounds good, thx!
19:18:49 <kgriffs> btw, Flavio said if you are only using one last name for him, then do Percoco, i.e., "Flavio Percoco"
19:18:58 <kgriffs> ok, moving on...
19:19:31 <kgriffs> malini: did you add bp for security testing and any work items to them that we already know about?
19:19:43 <malini> yes ..I added the bp
19:19:45 <kgriffs> (comprehensive security testing)
19:19:54 <malini> I am still figuring out what our work items should be
19:20:08 <kgriffs> ok, no problem
19:20:16 <malini> I tried running some DDoS on the local marconi server
19:20:25 <malini> but we need few more than just the DDoS
19:20:26 <kgriffs> next, regarding renaming "exceptions" to "errors" I never did get around to doing that
19:21:10 <kgriffs> I think I am going to de-prioritize that - do it in H3
19:21:22 <malini> ok
19:21:52 <kgriffs> is ametts in the house?
19:22:16 <malini> don't see him listed
19:22:39 <kgriffs> ok, well, let's talk about input validation next time then
19:23:04 <kgriffs> last time I checked, he had made good progress so I will update the bp
19:24:49 <kgriffs> #topic QA cluster
19:25:02 <kgriffs> so, how are we looking with the salt scripts?
19:25:11 <kgriffs> cases, whatever you call em'
19:25:34 <malini> oz_akan is making progress on the salt scripts
19:25:40 <kgriffs> "states"
19:25:49 <malini> We dont have the cluster ready yet
19:26:24 <kgriffs> ETA?
19:26:24 <malini> Meanwhile, we are getting the load test xmls ready
19:26:53 <malini> Hope to start the load tests early next week
19:27:09 <kgriffs> re the load tests, are you waiting on further feedback?
19:27:28 <malini> yes
19:27:39 <malini> I would like flaper87 to take a look at the xmls as well
19:27:52 <kgriffs> OK. He is traveling so probably won't be until next week
19:28:15 <kgriffs> I'd say just go ahead and merge that in and have him take a look after the fact
19:28:26 <malini> ok..I'll do tht
19:29:58 <kgriffs> oz_akan: so, what is left to set up with the QA cluster?
19:31:45 <oz_akan_> hi
19:31:53 <kgriffs> welcome!
19:32:27 <oz_akan_> I didn't have much progress on QA cluster, automation is still in progress
19:32:47 <oz_akan_> we already have servers but don't yet have CD
19:33:10 <kgriffs> ok, do we have memcache now?
19:33:21 <kgriffs> (and keystone middleware configured to use it)
19:35:17 <oz_akan_> I am working on a parallel environment
19:35:19 <kgriffs> not a big rush, but it would nice to have memcached set up before we do load testing
19:35:22 <oz_akan_> where we will have memcache first
19:35:44 <oz_akan_> I had done some important changes on salt forumalas
19:35:50 <kgriffs> also, haproxy for A/B testing against Atlas
19:36:00 <kgriffs> ok, that's cool
19:36:05 <oz_akan_> yes, I noted down haproxy
19:36:15 <kgriffs> let's touch bases next week and see where we are
19:36:19 <oz_akan_> ok tks
19:36:26 <kgriffs> thanks!
19:36:33 <kgriffs> so, last topic
19:36:49 <kgriffs> #topic client bp's
19:37:22 <kgriffs> so, just to give everyone an update, I commented on the common OpenStack client lib that we are incubating as part of python-marconiclient
19:38:07 <kgriffs> waiting for Flavio to get back next week and see if he agrees to just merge it and add the issues I found as blueprints
19:38:22 <malini> ok
19:38:33 <kgriffs> regarding other blueprints, I was hoping malini could register a few things and start thinking about how to go about implementing them
19:38:55 <kgriffs> first off is polling modes in the client
19:39:04 <kgriffs> I think there is already a bp for that
19:39:25 <kgriffs> #link https://blueprints.launchpad.net/python-marconiclient/+spec/polling-modes
19:39:29 <kgriffs> any questions on that?
19:40:09 <malini> so what activates a polling mode?
19:40:39 <malini> will marconi-server send messages to the client to switch modes?
19:40:39 <kgriffs> good question. We know that deactivation can be done based on a TTL
19:41:06 <malini> yeap
19:41:55 <kgriffs> as for throttling up, I guess we could either leave that up to something for the user to implement or maybe we define some kind of message format
19:42:07 <kgriffs> other thing is we could create some policy class
19:42:39 <kgriffs> so, a sample policy class would just throttle up on polling each time it's get's a message, then eventually throttle back down if it doesn't get anything for a while
19:42:55 <malini> ok
19:43:08 <kgriffs> so, something to think about
19:43:23 <kgriffs> I think it will take some experimentation
19:43:27 <malini> sure
19:43:30 <kgriffs> any other questions?
19:43:44 <malini> will have more as we get closer to implementing
19:43:58 <kgriffs> (p.s. - it would be good if you could start a wiki page)
19:44:01 <kgriffs> kk
19:44:13 <malini> will start tht
19:44:19 <kgriffs> #action malini to start a wiki page for client polling modes
19:44:36 <kgriffs> thx!
19:45:05 <kgriffs> ok, so one more: client integration with swift
19:47:01 <kgriffs> It's a common pattern with SQS and IronMQ to put a blob on S3 and then just reference it from the message, rather than embedding it
19:47:17 <kgriffs> But that's kind of a pain from what I've heard.
19:47:50 <kgriffs> so, I was thinking, it would be sweet if the client could abstract away that
19:48:11 <malini> i.e. get the BLOB & insert it into the message ?
19:48:21 <kgriffs> so, a message object would have the usual TTL and body attributes, but maybe also a "blob" or something
19:48:52 <kgriffs> and the client would under the covers PUT it to a swift container, and insert a link into the message's body document
19:49:05 <bryansd> slick
19:49:20 <malini> tht is neat
19:49:25 <kgriffs> on the other end, the receiver would then download the blob and "put that thing back where it came from"
19:49:50 <kgriffs> it cd. generate a temp URI or something, and have the object auto-expire
19:50:15 <kgriffs> ok, if that sounds like a good idea, malini could you register a blueprint?
19:50:19 <malini> sure
19:50:25 <kgriffs> excellent
19:50:34 * kgriffs plays air guitar
19:50:39 <kgriffs> ok
19:50:44 <kgriffs> #topic open discussion
19:50:52 <kgriffs> anything else before we close up shop?
19:51:07 <malini> nothing from me
19:51:11 <megan_w> i'm good
19:54:15 <kgriffs> #endmeeting