19:06:56 <kgriffs> #startmeeting marconi
19:06:57 <openstack> Meeting started Thu Jun 13 19:06:56 2013 UTC.  The chair is kgriffs. Information about MeetBot at http://wiki.debian.org/MeetBot.
19:06:58 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
19:07:01 <openstack> The meeting name has been set to 'marconi'
19:07:08 <kgriffs> #topic town hall
19:07:14 <flaper87> \o/
19:07:36 <kgriffs> ok, any folks in the room with general questions about Marconi?
19:08:18 <flaper87> tic, toc, tic, toc, tic, toc
19:08:23 <oz_akan> :)
19:08:55 <kgriffs> great, so sounds like everyone understands what's going on with the project 100% or simply doesn't care. :p
19:09:28 <kgriffs> so, general questions regarding the project before we talk about incubation?
19:10:24 * kgriffs watches a tumbleweed roll by
19:10:45 <kgriffs> ok, so we got a couple of feedback items from the dev list post
19:11:13 <kgriffs> Vish recommended we move project ID out of the url, and just get it from a header
19:11:49 <flaper87> sounds like something we could do for H-2
19:11:51 <flaper87> thoughts?
19:12:53 <kgriffs> sounds good to me. Since this changes pretty much every URI path, we should do it sooner rather than later.
19:13:16 <flaper87> right
19:13:22 <kgriffs> https://trello.com/c/oxPdEQpJ
19:13:24 <ametts> Definitely before there are clients out there in the wild that are coded to the old scheme.
19:13:27 <flaper87> we could schedule sqlalchemy's for H-3 if you agree
19:13:30 <kgriffs> Not sure if it's worth creating a bp
19:14:00 <flaper87> kgriffs: I'd say so, just to keep track in lp as well
19:14:30 <kgriffs> flaper87: k, I'll ad that. Can you set the milestone for sqlalchemy to H3?
19:14:47 <flaper87> sure
19:15:12 <kgriffs> #action kgriffs to add blueprint for moving project id to headers
19:15:25 <kgriffs> #action flaper87 to schedule sqlalchemy driver for H3
19:16:07 <flaper87> kgriffs: re sqlalchemy, I think that back-end is a replacement for sqlite
19:16:37 <flaper87> I mean, once it is done we'll just remove sqlites
19:17:24 <kgriffs> (for the folks following along at home, the sqlalchemy bp came from some other feedback we got that we should support MySQL or some other mainstream RDBMS)
19:18:00 <flaper87> re blueprints, we should start setting some of those bp as Implemented and start tracking upcoming changes as bugs or new blueprints
19:18:29 <oz_akan> HA part of mysql is very difficult compared to mongodb
19:18:29 <kgriffs> flaper87: that's fine re sqlite, since sqlalchemy supports that as a dialect
19:18:37 <kgriffs> (so we can still use for unit tests)
19:18:37 <flaper87> kgriffs: we kind of talked about that a few months ago (sqlalchemy) I'm glad Jay helped us on making up our minds about it
19:18:43 <flaper87> kgriffs: right
19:19:24 <flaper87> oz_akan: I don't think we need to do load / HA / security tests on every transport / storage we support
19:19:25 <kgriffs> flaper87: I spent some time yesterday cleaning up the bp's - i'll take another pass today
19:19:31 <flaper87> that's kind of a deployment decistion
19:19:33 <kgriffs> #action kgriffs to update bp's
19:20:20 <kgriffs> well, it seems like we will need to have a reasonable idea of performance/load that a given supported driver can handle
19:20:28 <kgriffs> (in it's vanilla configuration)
19:20:46 <kgriffs> and there's no reason we can't run security tests on all drivers
19:21:42 <flaper87> we can do it but should we? (I'm speaking of storages here)
19:21:48 <kgriffs> then we can sort of recommend different backends depending on people's needs
19:22:13 <kgriffs> well, we should do security testing. I don't want to be blamed for someone's cluster getting cracked.
19:22:32 <flaper87> agreed about security
19:22:33 <kgriffs> as for load testing, eventually I say yes, but initially we don't need to.
19:23:08 <kgriffs> (useful for comparison; maybe one of these other solutions will actually be faster or something than mongo, who knows?)
19:23:28 <oz_akan> I wonder how a RDBMS would make the queueing service better...
19:24:00 <flaper87> oz_akan: We'll need to test that
19:24:07 <kgriffs> well, the one advantage is you get auto-inc keys
19:24:17 <kgriffs> but you trade that for other things
19:25:25 <kgriffs> flaper87: agreed. we have some experimenting to do, and we don't know yet what the usage patterns are going to be with real users.
19:25:27 <oz_akan> kgriffs: yes, since this is a service, I want to think it will be easy to manage
19:26:55 <kgriffs> heh, too bad we didn't just do sqlalchemy from the beginning, since we needed sqlite for prototyping and unit testing anyway.
19:27:00 <kgriffs> Anyway, let's move on.
19:27:26 <kgriffs> So, I'm trying to see if Meghan is here from Rackspace
19:27:46 <kgriffs> actually, I think she is on vacation or something today
19:27:49 <flaper87> Meghaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaan, you there?
19:27:53 <flaper87> awwwwww :(
19:28:32 <kgriffs> so, hopefully she'll join us next time, but she will be helping us get the incubation wiki page filled out and keep track of the stuff we need to do otherwise.
19:28:45 <kgriffs> (to get incubated)
19:28:54 <flaper87> awesome, that sounds really great, we need that
19:29:15 <ametts> kgriffs:  Wanna tag that as an action for purposes of the minutes?
19:29:57 <kgriffs> #action Megan to get our incubation request page filled out
19:30:28 <kgriffs> #link https://wiki.openstack.org/wiki/Marconi/Incubation
19:31:18 <kgriffs> so, I was trying to remember how soon we needed to apply...
19:31:38 <flaper87> we said mid H-2
19:31:46 <flaper87> but I guess end H-2 is find as well
19:32:39 <kgriffs> ok, so that puts us at the end of this month, July 18 at the latest
19:33:30 <flaper87> right
19:34:10 <flaper87> #link https://wiki.openstack.org/wiki/Havana_Release_Schedule
19:35:28 <kgriffs> If we can get the wiki page updated in the next several days, then we can send to the appropriate lists and git-r-done
19:35:45 <kgriffs> #link https://wiki.openstack.org/wiki/Governance/NewProjects
19:35:55 <ametts> git has that command?  Why haven't we used it yet?
19:36:14 <kgriffs> just came out in the last release. ;)
19:36:20 <kgriffs> git r done
19:36:49 <kgriffs> #action kgriffs to follow up with Megan on preparing and submitting incubation request.
19:37:29 <kgriffs> ok, open discussion - anything folks want to discuss on the topic of the direction of the project, incubation, whatever?
19:38:09 <flaper87> o/
19:38:30 <flaper87> Don't want to push but, do we have a due date for the load tests ?
19:38:56 <kgriffs> #topic load testing
19:39:01 <flaper87> I just want to have an idea of when we'll be able to test that and get some realworld results
19:39:38 <kgriffs> +1, the sooner the better
19:39:43 <kgriffs> malini, oz_akan: ^^
19:39:49 <malini> we have the tests ready..once we have the env, we can break it :)
19:40:05 <oz_akan> hmm
19:40:15 <oz_akan> working on CD a few days
19:40:33 <oz_akan> we already have the test env with the latest code
19:40:49 <oz_akan> we can benchmark it, right Malini?
19:40:55 <malini> yes
19:41:11 <kgriffs> so, you have the load generators provisioned already as well?
19:41:27 <malini> provisioned?
19:41:43 <malini> We have load generators created manually..not yet salt-ed
19:41:43 <kgriffs> i.e., there's salt for that
19:41:46 <oz_akan> as soon as done with CICD, I am working on that
19:41:50 <kgriffs> kk
19:41:51 <flaper87> are / will be the results of those tests public? I mean, we page or something similar
19:41:53 <kgriffs> manual is fine for now
19:42:01 <flaper87> webpage*
19:42:12 <oz_akan> flaper87: yes, sure we can
19:42:13 <malini> we'll have tht
19:42:16 <kgriffs> it would be kind of cool to track those over time
19:42:18 <flaper87> awesome
19:42:20 <kgriffs> graphtastic
19:42:33 * flaper87 very happy about that
19:42:45 <malini> yes.we will store those results & use them as baseline for future releases as well
19:42:57 <kgriffs> can we dump those to graphite, maybe the nightly run?
19:43:01 <kgriffs> (from the mainline)
19:43:17 <oz_akan> after a change on master branch,we will run these tests
19:43:17 <kgriffs> or whatever, anyway, malini can u register a bp?
19:43:17 <malini> havent tried tht yet..But we sure can
19:43:24 <oz_akan> to automate them, I need to work with Malini
19:43:32 <malini> bp for graphite ?
19:43:42 <flaper87> wasn't there one?
19:43:47 <oz_akan> I think I can finish CICD by Tuesday, so next week test environment can be ready
19:44:14 <malini> we already have bp for load test https://blueprints.launchpad.net/marconi/+spec/load-test
19:44:22 <kgriffs> malini: for graphing performance and load watermark over time
19:44:41 <kgriffs> a separate one, we can do it later
19:44:45 <malini> ok
19:44:55 <kgriffs> for now, just dump them somewhere and people can make their own pretty graphs if they want. :p
19:45:10 <kgriffs> (by "them" I mean the tsung output)
19:45:36 <malini> ok :)
19:45:42 <kgriffs> ok, so we have a home for the salt and load/security tests?
19:46:12 <malini> we have a home..It'll soon have inhabitants
19:46:26 <kgriffs> excellent
19:46:27 <malini> To start with I'll add the tsung xmls
19:46:58 <kgriffs> re security tests, it would be nice to have at least some very basic ones done by H3
19:47:14 <kgriffs> maybe we need to split up the bp?
19:47:29 <malini> I havent done much on security testing yet
19:47:58 <malini> It'll be good to define some specific stuff we need by H3
19:48:18 <kgriffs> kk, let me rename this one to "basic-security-tests", and you can register another blueprint for doing more comprehensive ones.
19:48:21 <kgriffs> https://blueprints.launchpad.net/marconi/+spec/security-testing
19:49:58 <malini> Can I just keep this as is & register a new one for basic-security-tests ?
19:50:04 <kgriffs> https://blueprints.launchpad.net/marconi/+spec/security-testing-basic
19:50:05 <kgriffs> oops
19:50:06 <kgriffs> sorry
19:50:10 <malini> np
19:50:30 <malini> I'll just add a new one for comprehensive test
19:51:01 <kgriffs> kk, and feel free to add work items to those
19:51:19 <kgriffs> ok, anything else on the topic of quality?
19:51:33 <malini> no
19:51:43 <kgriffs> #action malini to add bp for comprehensive security testing
19:51:52 <kgriffs> #action malini to add work items to those bp's
19:52:46 <kgriffs> #topic rename "exceptions" modules to "errors"
19:53:24 <kgriffs> so, any objections to doing this?
19:53:36 <flaper87> nope
19:53:50 <kgriffs> seems more idomatic to call them errors, IMHO
19:53:59 <kgriffs> and may earn us brownie points with the TC
19:54:03 * kgriffs can hope
19:54:06 <flaper87> dude, out of my mind, I was just writing the "Why?" question
19:54:25 <flaper87> cool
19:54:46 <kgriffs> kk, it's super quick change
19:55:09 <kgriffs> I wasn't going to rename the exceptions to append "Error" at this time, but maybe later where it makes sense
19:55:24 <kgriffs> #action kgriffs to rename exceptions to errors
19:55:25 <flaper87> wwkk
19:55:56 <flaper87> I'll migrate the transport / storage load to stevedore
19:56:20 <kgriffs> #action flaper87 to migrate the transport / storage load to stevedore
19:56:31 <kgriffs> last item, real quick
19:56:40 <kgriffs> so, right now we aren't doing any authorization:
19:56:52 <kgriffs> https://blueprints.launchpad.net/marconi/+spec/project-id-authorization
19:57:24 <kgriffs> and we *need* to be doing it
19:57:42 <flaper87> wait, you mean the keystone thing?
19:58:11 <kgriffs> so, keystone does authentication, meaning the token is good, and passes through project id
19:58:19 <flaper87> right
19:58:50 <kgriffs> but we aren't actually enforcing anything about which account can access which project
19:59:12 <flaper87> but that's done by keystone
19:59:18 <flaper87> during the login process
19:59:20 <kgriffs> but this is from the old model of having the project id in the url
19:59:49 * kgriffs just has an ah-ha moment
20:00:11 <kgriffs> so, check me on this, but user passes auth token to api
20:00:22 <kgriffs> middleware checks auth token, injects project id header
20:00:34 <kgriffs> the marconi just uses that project id
20:00:39 <flaper87> right
20:00:41 <flaper87> :)
20:00:47 * markwash is *not* in a rush to start the glance meeting, so please take your time
20:00:48 <kgriffs> as long as the user can't specify the project id directly, we are cool
20:01:01 <kgriffs> markwash: no worries, we are wrapping up now
20:01:14 <flaper87> kgriffs: that's already enforced by keystone's log-in process
20:01:18 <flaper87> so, we're good there
20:01:27 <flaper87> it already checks user1 has permissions in project1
20:01:30 <flaper87> and so on
20:01:44 <kgriffs> sweet. OK. I haven't looked yet, but does the middleware still do X-Tenant-ID or is it using the new "project" name?
20:02:02 <kgriffs> oic, so a user can specify project header if they like?
20:02:07 * kgriffs should know this
20:02:42 <flaper87> well, it has to specify the project it wants to log-in to
20:03:01 <kgriffs> makes sense
20:03:05 <kgriffs> kk, let's wrap up
20:03:11 <flaper87> :D
20:03:13 <kgriffs> any parting thoughts
20:03:16 <kgriffs> ?
20:03:33 <flaper87> nope
20:04:02 <kgriffs> #endmeeting