20:31:48 <notmyname> #startmeeting
20:31:49 <openstack> Meeting started Wed May 16 20:31:48 2012 UTC.  The chair is notmyname. Information about MeetBot at http://wiki.debian.org/MeetBot.
20:31:50 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
20:32:04 <notmyname> three things to talk about. shouldn't take long, I hope
20:32:13 <notmyname> 1) status of what to split out
20:32:19 <notmyname> 2) 1.5.0 release timeframe
20:32:25 <notmyname> 3) keystone stuff
20:32:38 <notmyname> #topic splitting stuff out of swift
20:33:10 <notmyname> I'd like to list the middleware we have (or had) and if anyone things it should stay in or be discussed, please speak up
20:33:18 <notmyname> swift3?
20:33:35 <chmouel> I that should def be split out
20:33:41 <notmyname> chmouel: were you goign to work with fujita on that?
20:33:52 <notmyname> he has the code split out, but no docs/packaging/etc
20:34:10 <chmouel> notmyname: I haven't get it touch with him yet (is he on IRC) but i can do as an action to get thing forward
20:34:18 <notmyname> someone could easily propose a patch to add that to hig gihub repo
20:34:31 <notmyname> cool
20:34:37 <notmyname> acl middleware?
20:34:53 <redbo> I'd prefer it stay in
20:35:03 <chmouel> yeah it used by all middleware
20:35:06 <notmyname> ya, I think that makes sense
20:35:09 <chmouel> auth middleware
20:35:11 <gholt> Those are really helper functions for other middleware tbh, so yeah stays.
20:35:21 <gholt> tempauth? stays
20:35:28 <notmyname> same with catch_errors, emcache
20:35:47 <notmyname> tempauth could depend on what we decide with keystone
20:35:48 <gholt> Did you mean tempauth?
20:36:09 <dfg> i don't think so- need tempauth for saio
20:36:12 <notmyname> no. acl.py
20:36:17 <gholt> I can't imagine separating tempauth. It's whole existence is to provide a test harness for the core swift repo.
20:36:55 <notmyname> domain_remap, formpost, tempurl, ratelimit? (they've all been removed. was that good for all of them?)
20:37:07 <notmyname> oh and staticweb too
20:37:30 <notmyname> anyone think they should stay in?
20:37:36 <redbo> I kind of do
20:37:48 <notmyname> all of them? why?
20:37:50 <pandemicsyn> ratelimit seems like a core thing
20:37:55 <torgomatic> I'd like to see ratelimit in
20:37:58 <chmouel> I think rate limit as well
20:38:11 <notmyname> anyone want to argue ratelimit should be out?
20:38:13 <gholt> I'm fine either way with all of those. I separated the ones I did to try to be consistent and hopefully not make other contributors upset that "their" stuff didn't get in.
20:39:02 <gholt> That seems like an action item for me then: Revert ratelimit removal.
20:39:12 <redbo> I don't know, staticweb and formpost seem like a good features.
20:39:18 <notmyname> domain_remap and cname_lookup (forgot that one) are pretty lightly used (I think). I'm fine with keeping those out. anyone think they should go back in?
20:39:25 <gholt> It's not good or not, it's in core repo or not.
20:39:49 <gholt> I don't want people to think "not in core; it must suck" or something. It's just division of reponsibilities.
20:39:57 <notmyname> ya, do we want to be responsible for maintaining that code and tie it's functionality to swift releases?
20:39:58 <chmouel> +1
20:40:07 <notmyname> s/it's/its
20:40:30 <redbo> I don't want people to say "Well we got swift, but to get this feature everyone uses, we've gotta go to github.com/dpgoetz"
20:40:43 <gholt> Not sure what "that" is in the context, but I'm already responsible for staticweb, formpost, tempurl, swauth
20:40:47 <pandemicsyn> is it more about deciding what should be a  "core feature" ?
20:40:54 <chmouel> redbo: that would be a packaging problem ?
20:41:27 <redbo> and we don't know if it's been tested to the same rigor as swift core, and we don't know what versions of swift it's been integration tested with
20:41:29 <dfg> is it "core repo" or "standard prod deploy".  don't we want to make standard deployements of swift as easy / robust as possible?  i'm worried about testing separate repos
20:41:52 <pandemicsyn> as the token ops guy im 100% with dfg
20:42:23 <notmyname> ya, we want installs to be as easy as possible, but we also want to keep the scope as small as reasonable
20:42:27 <gholt> Are we just talking about ratelimit? Or everything again?
20:42:56 <redbo> was maintaining these things really causing anyone pain?
20:43:06 <gholt> [Pronouns are irritating. :)]
20:43:08 <dfg> i'm talking about everything (sorry) i just want a good reason for the bugs that will happen because of this
20:43:44 <gholt> Dang, would've been cool for all this speak up while the geritt review was up. Hehe :)
20:43:45 <chmouel> I think it's because it opens door for other middleware to be added in swift core
20:43:58 <notmyname> redbo: I think swift3 compat causes some pain
20:43:59 <dfg> i was i little busy with SOS...
20:44:05 <gholt> dfg: :P
20:44:23 <redbo> Well, we can pull swift3 out, especially if the primary maintainers don't mind.
20:44:49 <notmyname> ya, and 3rd party APIs are to be separate now, per openstack policy (aws, cdmi, etc)
20:45:19 <redbo> while I reject their right to mandate that, I agree with the conclusion ;)
20:45:27 <notmyname> heh
20:45:29 <gholt> I guess I'll go back to my position that maybe caused a lot of this ruckus. I personally don't want to maintain CDMI and ZFS code. I feel it's pretty complicated and my brain in kinda full. If that's just my problem, I'll deal.
20:45:57 <torgomatic> gholt: +1
20:46:17 <pandemicsyn> theres a set of features that Swift has to have or ship with to make it a viable product for operations teams, but i don't think it has to be a "keep all" or "discard all" type of scenario
20:46:18 <redbo> I'm fine with that, I just don't like that that logic lead to a lot of things that I consider useful features to be pulled out of swift.
20:46:21 <notmyname> gholt: I don't think it's just your problem
20:46:26 <dfg> if there was a plan for how they'd all be tested i'd feel better.  before I approve commits I run unittests and functests.  those just became a lot less meaningful.
20:46:59 <dfg> (i do other stuf too :p)
20:47:17 <notmyname> ok, so swift3 should stay out. should all of the others come back in? or should some of them stay out too?
20:47:31 <notmyname> (and the next thing is the separation of the client libs and CLI)
20:48:04 <chmouel> should we make a vote with that #vote thing?
20:48:07 <redbo> I don't know, staticweb is the only thing that's kind of big enough to stand on its own.  But I think it's a pretty sweet feature and should probably be part of core.
20:48:09 <pandemicsyn> notmyname: im indifferent on tempurl/formpost, but stuff like ratelimit/healthcheck/tempauth should stay for sure
20:48:13 <notmyname> would you like to vote on each of them or have a bulk vote?
20:48:32 <gholt> Have to vote on the vote. :)
20:48:35 <notmyname> heh
20:48:38 <chmouel> ah
20:48:54 <pandemicsyn> prevote survey
20:49:07 <redbo> no exit polling
20:49:08 <notmyname> #startvote all middleware except swift3 should be included (or re-added) to swift: yes no
20:49:20 <notmyname> is that not how that works?
20:49:33 <gholt> Fingers crossed
20:49:38 <gholt> vote: yes
20:49:39 <notmyname> yes for include it, no for keep it separate
20:49:43 <chmouel> i think it's #agreed
20:49:46 <notmyname> #vote yes
20:49:52 <gholt> #vote yes
20:50:03 <chmouel> #agreed
20:50:05 <redbo> gholt's mom got exit polled.  After she voted in the last election.
20:50:12 <redbo> #vote yes
20:50:19 <pandemicsyn> #vote yes
20:50:19 <torgomatic> #vote yes
20:50:36 <dfg> #vote yes
20:50:40 <notmyname> #endvote
20:50:40 <gholt> shamockery
20:50:47 <chmouel> #vote yes
20:50:50 <notmyname> heh
20:51:00 <notmyname> I don't think I did that right, but we have a decision
20:51:11 <notmyname> #agreed keep or readd all the middleware except swift3
20:51:29 <notmyname> ok, so the client lib and CLI
20:51:33 <gholt> That includes Swauth.
20:51:35 <notmyname> chmouel: are you working on splitting that out?
20:51:36 <gholt> Joking joking
20:51:47 <redbo> I would now like to read glange's absentee vote.    glange: #vote discgolf
20:51:53 <redbo> I don't think he knew what we'd be voting on
20:51:55 <chmouel> notmyname: yeah my only concern is if we want to add the direct_api there
20:52:05 <notmyname> ya, what should be pulled out?
20:52:15 <chmouel> gholt: ^^
20:52:19 <notmyname> this would be stuff pulled out into a separate repo but still managed by the swift core team
20:52:38 <gholt> I'm not sure why really, if everything else is in.
20:52:47 <gholt> Just package stuff differently.
20:53:02 <chmouel> yeah well it would make easier for a lot of people to include it in pip
20:53:12 <chmouel> and not have to keep copy with bug or outdated in their own repos
20:53:18 <redbo> well, should swauth be in a repo that's controlled by the group, or just by you?
20:53:20 <chmouel> or have them to use python-cloudfiles
20:53:36 <redbo> gholt: ^ what I said
20:53:43 <notmyname> redbo: you'll have to beg him for collaborator access :-)
20:53:59 <notmyname> chmouel: is that solvable simply by packaging or does it require separate code locations
20:54:00 <gholt> or fork it and move on, hehe
20:54:07 <redbo> all of my precious swauth ideas wasted
20:54:15 <chmouel> notmyname: it is code location
20:54:16 <notmyname> the other openstack projects have separate code repos for their associated client libs
20:54:29 <chmouel> notmyname: as a pip cannot do subpackage
20:54:32 <notmyname> ah ok
20:54:56 <notmyname> so what needs to be in that separate code repo? just the client.py? the CLI? direct_client?
20:55:01 <pandemicsyn> separate client libs make sense
20:55:09 <notmyname> ya, I like the idea too
20:55:12 <pandemicsyn> breaking out the cli seems odd
20:55:15 <chmouel> definitively bin/swift and swift.common.client
20:55:17 <annegentle> how shall we do docs for the separate code use cases?
20:55:29 <torgomatic> client.py and the CLI sound good; not sure about direct_client
20:55:30 <notmyname> annegentle: how is it done for nova/glance/etc?
20:55:40 <notmyname> annegentle: I'd assume the same way
20:56:00 <chmouel> yeah the cli and the client is a different package for all other os projects
20:56:09 <annegentle> "important" use cases are documented in priority order, however we haven't had to have people go to separate code repos for those yet.
20:56:29 <notmyname> annegentle: ah. I thought that was already done for all the other projects
20:56:39 <notmyname> chmouel: is it not?
20:56:59 <annegentle> mostly stuff that has been split out from nova has had its own API
20:57:04 <notmyname> (to clarify, this is to move this code to another openstack repo, but with the same -core team (ie us))
20:57:28 <pandemicsyn> ahh, in that case moving the cli makes sense
20:57:38 <pandemicsyn> thought the cli would move to some random persons github
20:57:52 <notmyname> ok. anyone opposed to moving just the client lib and CLI to a separate openstack repo still managed by us?
20:58:11 <chmouel> (this is by the way ready here for just the CLI and client https://github.com/chmouel/python-swiftclient )
20:58:42 <notmyname> chmouel: can you working with mtaylor and jeblair about getting that set up in openstack?
20:58:53 <chmouel> notmyname: yep will do that
20:58:54 <notmyname> (chmouel is getting a big list of stuff to do)
20:59:10 <annegentle> we're already pondering this on doc-core with the additional options to the .conf files, such as https://review.openstack.org/#/c/7479/
20:59:17 <chmouel> hey hey and i'm on leave tomo and friday
20:59:30 <notmyname> ok, swift 1.5.0 release date
20:59:43 <notmyname> #topic swift 1.5.0 release
20:59:53 <notmyname> we'll release it when it's ready. what are we calling ready?
21:00:06 <notmyname> 1) getting the middleware situation cleaned up
21:00:15 <notmyname> do we need to get the client libs split off first?
21:00:23 <dfg> what's currently in there? i haven't been paying much attention?
21:00:27 <mtaylor> notmyname: ola
21:00:31 <mtaylor> chmouel: yay!
21:00:48 <notmyname> dfg: everything since before the summit
21:00:58 <notmyname> https://launchpad.net/swift/+milestone/1.5.0
21:01:32 <notmyname> I'd like to see the expanded recon support and proxy logging middleware be in 1.5.0, but those are lower priority to me
21:02:17 <notmyname> (less important == less important than solving the middleware issue, not that they aren't important)
21:02:53 <notmyname> anyone want to release 1.5.0 before those land? or should they be essential to the release?
21:03:31 <chmouel> the proxy logging middleware has problem with swift3 i think
21:03:32 <notmyname> ok, I'll take that to mean that they should all land :-)
21:03:41 <chmouel> but is it a problem anymore if it's pulled away?
21:04:11 <notmyname> yes, it's a problem overall, but it's not something that should block
21:04:33 <redbo> that might be fixed.  I don't have a good functional test for swift3.
21:04:51 <notmyname> ok, chmouel and redbo can work together to make sure that works
21:05:19 <notmyname> can we get these things merged by May 25th?
21:05:40 <notmyname> then we can test/QA the next week and release 1.5.0 on the 31st
21:05:43 <chmouel> cool ok, i think zaictev was interested as well to work on that
21:05:45 <notmyname> anyone opposed to that?
21:05:50 <notmyname> chmouel: cool
21:06:59 <dfg> fine with me
21:07:01 <notmyname> ok, I'll let ttx know that our tentative date for 1.5.0 is May 31st
21:07:24 <notmyname> now for the unexpected topic that came up yesterday: keystone
21:07:36 <notmyname> #topic swift+keystone sitting in a tree....
21:07:54 <redbo> s-p-i-t-t-i-n-g
21:08:08 <chmouel> I am personally all fine with the current situation
21:08:12 <notmyname> currently the swift+keystone middleware lives in the keystone project
21:08:58 <notmyname> I think the hard part is not who maintains the code but how the integration testing is done
21:08:59 <chmouel> as long we communicate the change that need to be done on the other auth middleware clearly
21:09:56 <notmyname> one argument is that we should manage the keystone integration so as to provide a "drop-in" usability of swift with the other projects
21:10:14 <notmyname> I was hoping that heckj would be able to be here for this, but he doesn't seem to be online
21:11:14 <notmyname> first question: where should the keystone middleware live? in swift or in keystone?
21:11:37 <chmouel> should we vote?
21:11:52 <notmyname> #startvote where should the keystone middleware live? in swift or in keystone?
21:11:53 <openstack> Begin voting on: where should the keystone middleware live? in swift or in keystone? Valid vote options are Yes, No.
21:11:54 <openstack> Vote using '#vote OPTION'. Only your last vote counts.
21:12:00 <notmyname> heh
21:12:05 <chmouel> nice
21:12:07 <redbo> #vote no
21:12:08 <openstack> redbo: no is not a valid option. Valid options are Yes, No.
21:12:13 <notmyname> ok, yes == keystone, no == swift
21:12:15 <dfg> putting it into swift would also mean that its controlled by our core devs who don't have any experience with it and don't really use it. doesn't that mean we shouldn't control it?
21:12:24 * notmyname slaps openstack
21:12:37 <chmouel> dfg: well the argument can be seen from the other side
21:12:48 <dfg> chmouel: does anyone run both?
21:12:54 <annegentle> who gets to vote?
21:13:03 <notmyname> annegentle: core devs please :-)
21:13:08 <annegentle> notmyname: you got it
21:13:13 <notmyname> annegentle: but I welcome your input
21:13:17 <redbo> #vote whatever causes the least friction
21:13:17 <chmouel> dfg: and to tell truth the auth_token middleware abstract most of the keystone interaction
21:13:17 <openstack> redbo: whatever causes the least friction is not a valid option. Valid options are Yes, No.
21:13:30 <annegentle> hee hee openstack
21:13:38 <notmyname> chmouel: where does the middleware for the other projects live?
21:13:47 <chmouel> in their own
21:13:54 <notmyname> so nova in nova, etc?
21:13:55 <chmouel> i think that's the plan
21:14:10 <chmouel> yeah not for essex but for folsom that't the plan AFAIK
21:14:49 <chmouel> and have auth_token middleware only in keystone
21:14:59 <notmyname> what does auth_token do?
21:15:18 <chmouel> it sits in the pipeline
21:15:28 <chmouel> before the swift middleware and takes the login and do the validation
21:15:34 <chmouel> the credential i mean
21:15:53 <notmyname> so the admin token (as opposed to the user's token)?
21:15:55 <chmouel> and pass headers to the next middleware if authenticated with the roles etc...
21:16:29 <chmouel> notmyname: it will use the admin token to the validation
21:16:51 <notmyname> ok, so the responsibility is split? keystone does part of it and nova does another part of it?
21:17:01 <notmyname> and that's the plan overall for all openstack projects?
21:17:30 <chmouel> i need to double check but that was my understanding
21:18:04 <notmyname> torgomatic: thoughts from your perspective?
21:18:16 <notmyname> pandemicsyn: gholt: you've been quiet too
21:18:52 <gholt> I don't have enough information or concern to make a decision here. Abstain.
21:18:55 <notmyname> dfg: I think most swift-only deployments (most swift deployments) don't use keystone. but all openstack deployments use keystone
21:19:19 <anotherjesse> chmouel: there is the generic auth_token middleware that can validate a token and set some context variables in wsgi
21:19:22 <notmyname> but that's a guess based only on what I've heard
21:19:23 <torgomatic> I haven't used Keystone enough (at all, really) to have any useful input
21:19:31 <anotherjesse> https://github.com/openstack/keystone/blob/master/keystone/middleware/auth_token.py
21:19:40 <dfg> so- if we added keystone. it would be good for openstack deployments? since they'd have a single auth system?
21:19:41 <anotherjesse> there is actually a header with docs about what it does
21:20:09 <anotherjesse> the thing that needs to be in each project is the conversion of the auth_token variables to project specific shims
21:20:10 <torgomatic> my only concern would be that, if I do spin up a Swift cluster using Keystone, that I don't have to install all of Keystone on my Swift nodes just to get some auth middleware
21:20:11 <notmyname> dfg: well, if it's a full openstack deploy, then they already have keysone so they have the middleware either way
21:20:33 <anotherjesse> theoretically new services could consume auth_token directly and not need a shim between auth_token and the service
21:20:36 <notmyname> torgomatic: I think it would still be optional in that you could use tempauth
21:20:40 <dfg> does it have unit / func tests?
21:20:52 <anotherjesse> torgomatic: there is talk of moving auth_token.py to openstack-common
21:21:10 <chmouel> notmyname: yeah right to answer the question as anotherjesse is saying all the glance/nova middleware are out of keystone only swift_auth is there
21:21:11 <anotherjesse> since it is a standalone "module" that doesn't require anything else
21:21:51 <torgomatic> notmyname: right; I'm just talking about the quantity of unused (on my Swift nodes) code that comes along with a full Keystone install
21:21:52 <chmouel> yeah definitively auth_token stays in keystone
21:21:56 <anotherjesse> chmouel: correct - we used to have the nova-specific shim in keystone (due to the delays in keystone existing and nova being released while the middleware was still being tweaked)
21:21:59 <notmyname> torgomatic: ya, ok. I misread
21:22:03 <anotherjesse> but it is now in nova
21:22:41 <anotherjesse> torgomatic: we (openstack) should allow packagers to deploy keystone's auth_token middleware without the rest of keystone - nothing stops it currently
21:22:56 <notmyname> so moving the keystone piece into swift means that we are responsible for testing it with each release (commit, rather)
21:23:23 <mtaylor> chmouel: should the unittests in python-swiftclient be expected to work right now?
21:23:48 <anotherjesse> notmyname: https://github.com/openstack/keystone/blob/master/keystone/middleware/swift_auth.py is the file we are talking about right?
21:23:53 <notmyname> anotherjesse: ya
21:24:10 <chmouel> mtaylor: it should I think but it doesn't i'll take a look again at it
21:24:15 <anotherjesse> notmyname: that is a file that converts the settings from authtoken (in the example pipeline) to swift specific variables
21:24:22 <mtaylor> chmouel: ImportError: No module named unit.proxy.test_server
21:24:45 <anotherjesse> it is swift specific code - not keystone specific - although it does rely on the environment coming from authtoken
21:25:02 <chmouel> mtaylor: hum i'll follow up with you in #openstack-dev later
21:25:11 <mtaylor> chmouel: cool
21:25:14 <anotherjesse> the contract from authtoken *SHOULD* not change without considerable effort by all projects
21:25:19 <notmyname> anotherjesse: doesnt' that tie release schedules together (or at least tie them to freezing that env every 6 months)?
21:25:21 <anotherjesse> since it requires updating all the other projects
21:25:34 <notmyname> a
21:25:35 <notmyname> ya
21:25:48 <anotherjesse> notmyname: we haven't changed the interface since diablo
21:25:52 <anotherjesse> and don't expect to for folsom
21:26:43 <notmyname> that's good. I'm not sure either way yet. I'm still learning what taking responsibility for that truly entails
21:26:47 <anotherjesse> notmyname: the expectation is that you might want to change what the mapping is
21:26:54 <anotherjesse> for instance the reseller stuff
21:27:41 <dfg> its not much code. if it causes a problem it can be removed. i guess my only concern is who'll maintain / peer review it / will it cause bad dependencies between projects on different schedules
21:28:22 <notmyname> #endvote
21:28:23 <openstack> Voted on "where should the keystone middleware live? in swift or in keystone?" Results are
21:28:29 <notmyname> whatever
21:28:33 <chmouel> dfg: I can def maintain it in there and I know that the HP guys and mnewby from internet has been involved
21:28:49 <chmouel> i mean internap :)
21:29:01 <dfg> ok- then i'm fine with it being in.
21:29:07 <pandemicsyn> +1
21:29:14 <chmouel> there is more swift specifics than keystone specifics tbh
21:29:32 <notmyname> #startvote move swift_auth.py middleware from keystone to swift
21:29:39 <notmyname> stupid openstack bot
21:29:46 <notmyname> #startvote move swift_auth.py middleware from keystone to swift? yes no
21:29:47 <openstack> Begin voting on: move swift_auth.py middleware from keystone to swift? Valid vote options are yes, no.
21:29:48 <openstack> Vote using '#vote OPTION'. Only your last vote counts.
21:29:57 <notmyname> wow it has to have a ?
21:29:59 <mnewby> ?
21:30:05 <notmyname> stupid openstack bot
21:30:07 <notmyname> ;-)
21:30:08 <dfg> #vote yes
21:30:12 <chmouel> #vote yes
21:30:16 <mnewby> #vote yes
21:30:18 <pandemicsyn> #vote yes
21:30:39 <notmyname> #vote yes
21:30:55 <gholt> abstain
21:31:02 <notmyname> redbo abstains too
21:31:03 <notmyname> torgomatic: ?
21:31:07 <torgomatic> abstain
21:31:11 <notmyname> #endvote
21:31:12 <openstack> Voted on "move swift_auth.py middleware from keystone to swift?" Results are
21:31:13 <openstack> yes (5): mnewby, dfg, pandemicsyn, chmouel, notmyname
21:31:30 <notmyname> ok, I'll work with heckj and see what needs to be done
21:31:48 <notmyname> I'll add this as a requirement to 1.5.0 since it shouldn't take much
21:32:03 <mnewby> sweet, finally.
21:32:16 <notmyname> ok, sorry this went longer that I expected. I wasn't planning on talking about keystone until yesterday
21:32:20 <notmyname> thanks all
21:32:22 <notmyname> #endmeeting