18:02:18 <morganfainberg> #startmeeting Keystone
18:02:19 <openstack> Meeting started Tue Jan  6 18:02:18 2015 UTC and is due to finish in 60 minutes.  The chair is morganfainberg. Information about MeetBot at http://wiki.debian.org/MeetBot.
18:02:20 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
18:02:20 <stevemar> link https://wiki.openstack.org/wiki/Meetings/KeystoneMeeting
18:02:23 <openstack> The meeting name has been set to 'keystone'
18:02:26 <morganfainberg> #link https://wiki.openstack.org/wiki/Meetings/KeystoneMeeting
18:02:30 <topol> gyee, LOL. enjoy rubbing it in!
18:02:55 <morganfainberg> we'll come back to henrynash's stuff at the end (since henry is on vacation)
18:03:00 <morganfainberg> welcome to 2015.
18:03:17 <rharwood> o/
18:03:30 <morganfainberg> lets keep things moving in the right direction, and we'll be up on the milestone 2 in no-time
18:03:50 <morganfainberg> #topic Migration path for R/W LDAP spec
18:04:00 <morganfainberg> jorge_munoz, o/
18:04:08 <morganfainberg> #link https://review.openstack.org/#/c/140175/
18:04:08 <ayoung> Who needs R/W LDAP?  Can we kill it?
18:04:23 <morganfainberg> ayoung, not likely
18:04:24 <gyee> :)
18:04:24 <bknudson> just get rid of it
18:04:45 <morganfainberg> joesavak, is jorge_munoz here?
18:04:45 <nkinder> +1
18:05:01 <dolphm> lbragstad: ^
18:05:02 <joesavak> I think so - let me ping him
18:05:03 <lbragstad> yes
18:05:04 * topol Im worried ayoung has dimensia setting in
18:05:06 <lbragstad> he is
18:05:13 <lbragstad> he is typing
18:05:18 <lbragstad> furiously
18:05:21 <morganfainberg> hehe ok
18:05:23 <ayoung> topol, multiple dimensions
18:05:27 <jorge_munoz> Yes, I wanted to ask how much implementation detail needs to be in the spec for the new schema. Also, wanted to get some feed back on the downgrade path.
18:05:48 <ayoung> "new schema"  meaning what?  We should not be specifying a schema
18:05:49 <gyee> we generally suck at downgrade
18:06:02 <ayoung> LDAP is written to work with existing schemas.  I would say more like:
18:06:14 <ayoung> "base level assumptions of schema..."
18:06:51 <morganfainberg> the current r/w ldap is bad and probably should be removed. however there is a desire to keep r/w ldap from a few sources.
18:06:57 <dolphm> jorge_munoz: avoid implementation detail in the spec, in general, otherwise +1 for ayoung
18:07:09 * ayoung reads spec
18:08:05 <ayoung> jorge_munoz, jorge_munoz  So...why LDAP?  Is it the replication story that you need?
18:08:54 <dolphm> morganfainberg: are all those sources represented here right now?
18:09:05 <morganfainberg> dolphm, should be.
18:09:12 <morganfainberg> dolphm, i have been chasing down who else uses it.
18:09:17 <ayoung> Note that I am not categorically against LDAP as a backend, just that the number of Orgs  requesting support for it has dropped to 1.
18:09:39 <gyee> uno?
18:09:42 <jorge_munoz> @ayoung We have an identity system that uses an LDAP backend for both read and writes.
18:09:43 <ayoung> I kindof like LDAP for assignments, but can't personally justify the time it takes to support it.
18:09:44 <morganfainberg> dolphm, there were more at one point, but i can't get anyone to respond now. so
18:09:54 <morganfainberg> dolphm, it'd be what rackspace is asking for.
18:10:07 <bknudson> use your ldap tools to update your ldap directory
18:10:16 <bknudson> we shouldn't have to provide a new tool for doing ldap updates
18:10:23 <dolphm> morganfainberg: i'm not sure it's what rackspace needs at all, but i could be too far out of the loop
18:10:39 <morganfainberg> dolphm, at this point, that spec is what i have to go on.
18:10:41 <ayoung> bknudson, replace LDAP with SQL in that statement and see how much it makes you shudder
18:11:02 <morganfainberg> dolphm, so, i'm willing to let jorge_munoz and joesavak make the case
18:11:08 <joesavak> ayoung - LDAP due to service level agreement with vendor, replication rules that we have, and the current integrations we have with it.
18:11:09 <bknudson> it's common to have applications define their own sql schema.
18:11:13 <bknudson> it's also not very smart
18:11:15 <gyee> jorge_munoz, in light of the proposed project reform (http://governance.openstack.org/resolutions/20141202-project-structure-reform-spec.html), its a good time to test the new water with this thing :)
18:11:35 <morganfainberg> gyee, negative
18:11:52 <gyee> hey, if we are going to separate out IdP from Keystone, why now?
18:11:55 <morganfainberg> gyee, that would be the equivalent of writing their own keystone afaik
18:12:05 <morganfainberg> gyee, which is not what is being proposed here
18:12:05 <gyee> hell yeah
18:12:16 <ayoung> so Identity is for users, but I understood Rack to need Assignment support as well, right?
18:12:27 <joesavak> right
18:12:32 <jorge_munoz> correct
18:12:48 <morganfainberg> gyee, that is a different bit of work, first off we need the split - not "go write your own keystone to get a split"
18:12:56 <dolphm> joesavak: jorge_munoz: is there anyone else interested in using the same architecture as rackspace?
18:13:16 <dolphm> joesavak: jorge_munoz: i'm wondering if rackspace's solution should be open source, but perhaps not upstream / maintained by keystone core
18:13:20 <morganfainberg> gyee, slightly different. don't force a complete re-write of keystone to get the split, the split should happen independently
18:13:38 <gyee> but this is a lot of rewrite as is
18:14:06 <gyee> just saying
18:14:06 <morganfainberg> gyee, the split should occur *anyway*. please take that off the table as part of this dicussion
18:14:25 <gyee> anyway, I don't have a problem either way
18:14:27 <morganfainberg> keep this focused on r/w ldap, support of it going forward.
18:14:28 <morganfainberg> etc
18:14:53 <jorge_munoz> @dolphm It could be but having a cleaner implementation give better option of deployers
18:14:56 <joesavak> dolphm - heard from a few large customers that they are interested in it for their private cloud deploys. Sit on top of exisitng LDAP and not use federation as they don't have ADFS or consider it too c omplex.
18:15:02 <ayoung> jorge_munoz, and joesavak can you guys get some feedback from the operators and other users who else is interested in LDAP support for Assignments
18:15:03 <ayoung> ?
18:15:24 <bknudson> if they have existing ldap then that's not r/w ldap
18:15:53 <ayoung> bknudson, the Rack rational is replication, which is what CERN was using it for as well
18:16:10 <ayoung> LDAP has a better multi-site story than MySQL
18:16:32 <bknudson> then they should pick a database that supports it better
18:16:35 <morganfainberg> ayoung, to a very limited scale without insane topology that rivals sql in complexity and risk
18:17:06 <ayoung> morganfainberg, LDAP as a domain controller (jhosts, hierarchical) is very well trodden territory
18:17:10 <morganfainberg> ldap and sql have different scale concerns, but both are largely solved.
18:17:13 <ayoung> jhost-> just hosts
18:17:50 <jorge_munoz> @ayoung Sure, we can do some in inquiries on who would be a consumer of the LDAP drivers.
18:17:53 <morganfainberg> ayoung, it's bad when you get to 10-20 sites, your topoligy for replication is as complex/more risky per-addtion/change to the layout [not data] as SQL
18:18:22 <morganfainberg> it's all bad for unified replication.
18:18:29 <bknudson> so we're talking about replacing the current LDAP implementation with a new one? (that's going to be awesome)
18:18:30 <ayoung> jorge_munoz, it sounds like the biggest thing you are looking for is upgrade/downgrade support, which is likely to be Directory Server specific.
18:18:40 <ayoung> what are you guys using?
18:18:45 <ayoung> if you care to share...
18:18:54 <jorge_munoz> We want to target 389
18:18:58 <ayoung> :)
18:19:35 <ayoung> morganfainberg, I think perhaps out-of-tree makes sense for this effort
18:19:53 <ayoung> would a keystoneldap project make sense?
18:19:56 <bknudson> if this is out-of-tree do we keep the old ldap?
18:20:16 <ayoung> bknudson, I think maybe we pare it down to RO Identity
18:20:21 <morganfainberg> bknudson, i'm willing to do ML/survey etc work to find out if we can deprecate r/w ldap
18:20:37 <morganfainberg> well, deprecate ldap assignment, and separately r/w ldap identity
18:20:38 <jorge_munoz> There might still be users who want to user their own schmea
18:20:39 <bknudson> that sounds great
18:20:42 <morganfainberg> two different concerns
18:20:45 <ayoung> jorge_munoz, joesavak you guys need multiple domains with R/W LDAP Assignement?
18:21:42 <lbragstad> so it sounds like the best option here would be to build this out of the keystone tree
18:21:46 <lbragstad> so possibly stackforge?
18:21:47 <joesavak> agree with Jorge - the backend schema for LDAP should be implementor choice.
18:21:59 <morganfainberg> ayoung, bknudson, if we ask this to go out of tree, short of saying "go write your own keystone" we would need to agree to solidifying the manager-api for assignment and/or identity
18:22:20 <bknudson> if the backend schema is up to the implementor you'll have all sorts of options... so what's different with the existing ldap implementation?
18:22:39 <gyee> ok, we'll all on the same page then :)
18:22:44 <morganfainberg> ayoung, bknudson, i would like to avoid saying "go write your own keystone" [that feels like the wrong stance to take right now to keep the community close]
18:22:44 <lbragstad> morganfainberg: ++
18:22:49 <ayoung> joesavak, jorge_munoz if you are already targetting 389, lets get a discussion going between your team and the FreeIPA team.  Perhaps we can handle this as stackforge effort
18:23:24 <bknudson> morganfainberg: and resources!
18:23:29 <morganfainberg> bknudson, yes.
18:23:45 <bknudson> (noting that we can't solidify the api since we change it all the time)
18:23:55 <morganfainberg> but we should work to make that interface very stable/non-changing anyway
18:24:09 <morganfainberg> but that is something we've not committed to yet.
18:24:20 <morganfainberg> this comes to that whole "better pluggable architecture" conversation
18:24:28 <joesavak> so are we saying any schema different than the one in place right now that needs driver development - that driver dev needs to be in stackforge? (lost)
18:24:41 <morganfainberg> where things plugin shouldn't change massively - just like the REST api shouldn't.
18:25:23 <morganfainberg> joesavak, that would sum up the general view - unless i'm miss reading things ( ayoung ?)
18:25:27 <bknudson> is that the problem that the LDAP rewrite is trying to solve? the schema is wrong?
18:25:33 <ayoung> joesavak, right now LDAP is very light on schema requirments, which works for Identity, but does not really work for Assignments.  I think that targetting something more rigid like a FreeIPA Hostgroup/project design would work better
18:25:52 <ayoung> bknudson, plus no way to do migrations
18:26:29 <morganfainberg> bknudson, it's trying to solve the "we've tried to wedge keystone into current ldap schemas when keystone controls everything" - it's a poor representation of what we support because the LDAP schema (default) isn't designed to handle the assignment backend
18:26:41 <morganfainberg> the identity backend is much closer to what a normal LDAP schema would support.
18:26:50 <joesavak> i like the other approach of surveying user of ldap schema in place, or perhaps versioning them to get to a schema that handles assignments too
18:26:52 <morganfainberg> if assignment is meant ot be r/w it probably should have it's own schema
18:27:17 <ayoung> An IPA backend for Keystone would probably be easier, as it would let you do things like creating users  and hosts at the Python level as opposed to direct LDAP calls
18:27:17 <morganfainberg> whether that is in-tree or out.
18:27:40 <morganfainberg> ayoung, ok we need to isolate the conversation, identity OR assignment?
18:27:44 <morganfainberg> which are you talking about now.
18:28:00 <morganfainberg> because we're crossing them all over this conversation and they are different concerns
18:28:09 <ayoung> morganfainberg, I'm actually talking about the Write side of LDAP for both
18:28:13 <marekd> o/ sorry i am late
18:28:15 <ayoung> Identity LDAP is primariy R/O
18:28:26 <ayoung> the R/W discussions is for both Id and assignement
18:28:31 <morganfainberg> ayoung, and assignment in LDAP is a poor representation of what keystone supports
18:28:34 <ayoung> but is, I think, a niche case
18:28:37 <bknudson> I don't see that they're different concerns... we should either support LDAP or not support it... right now it's kind-of supported.
18:28:40 <morganfainberg> regardless of r/w or r/o
18:28:52 <joesavak> having 2 non-conflicting schemas for LDAP (assignment & ID) may work - needs more research
18:29:13 <gyee> great topic for the upcoming meetup
18:29:14 <ayoung> joesavak, and you need multi-domain, too, right?
18:29:14 <nonameentername> bknudson ++
18:29:23 <jorge_munoz> ayoung: yes
18:29:25 <morganfainberg> bknudson, we can't remove ldap identity in the near term (read/only) that is for sure. but that isn't a hard sell or missing anything really from what we support
18:29:39 <dolphm> morganfainberg: but we could deprecate it
18:29:45 <ayoung> jorge_munoz, jorge_munoz nkinder OK,  lets table the rest of the discussion,and the 4 of us should set up a meeting instead
18:29:47 <dolphm> i assume that's all we're discussing here
18:30:11 <morganfainberg> dolphm, this is the issue we are discussing 3 things: identity r/o, identity r/w, assignment ldap
18:30:19 <ayoung> er..the second jorge_munoz should have been joesavak
18:30:37 <ayoung> morganfainberg, I think I would suggest the following:
18:30:41 <morganfainberg> dolphm, some of that could be deprecated, some could be sooner vs later
18:31:01 <ayoung> 1.  Remove R/W from Keystone as is.  2.  Work with Rackspace to come up with a solution specuific to their needs
18:31:29 <morganfainberg> i think the answer is ML/survey on LDAP assignment (both) - ML/Survey on R/w identity (seprate), leave r/o identity for now as is
18:31:41 <jorge_munoz> ayoung: we don’t want to modify the current implemetation just yet
18:31:48 <joesavak> +1 morgan
18:31:52 <ayoung> jorge_munoz, I understand.  We can help on that
18:32:00 <morganfainberg> if we're clear (less people/no one using) on the r/w front we can deprecate them, slate for removal in M
18:32:15 <morganfainberg> i am near positive assignment will be able to go
18:32:17 <ayoung> jorge_munoz, the R/W code as it exists is crap.  I should know, I wrote it.
18:32:37 <ayoung> It makes a lot of assumptions, but FreeIPA was in my mind when I made those assumptions
18:32:47 <morganfainberg> r/w identity *may* go, may need to wait till we split the identity part out and fully support something better (e.g. FreeIPA interface/separate API to manage things, etc)
18:32:53 <ayoung> So if you need W/R LDAP, it should be do-able
18:33:22 <morganfainberg> and r/o ldap identity can be evaluated once the r/w stories are dealt with
18:33:35 <jorge_munoz> yes
18:33:37 <joesavak> ayoung - sounds like a good collab opportunity. We'll discuss offline
18:33:52 <lbragstad> morganfainberg: jorge_munoz ++
18:34:00 <morganfainberg> #action joesavak and jorge_munoz to poll deployers on LDAP use-cases
18:34:24 <morganfainberg> #action morganfainberg to sent ML topics and surveys to determine use of ldap assignment (possible deprecation)
18:34:47 <morganfainberg> #action morganfainberg to send ML topics and surveys to determine use of read/write identity with LDAP (possible deprecation)
18:35:32 <morganfainberg> #action ayoung nkinder jorge_munoz joesavak to work offline to look at out-of-tree implementation to cover specific use-cases.
18:35:41 <morganfainberg> does that cover everything?
18:36:04 <joesavak> yup
18:36:21 <morganfainberg> anything anynoe else wants to add before we move on?
18:36:49 <morganfainberg> #topic AEToken Specification
18:36:53 <morganfainberg> #link https://review.openstack.org/#/c/130050/
18:36:55 <morganfainberg> lbragstad o/
18:36:57 <lbragstad> there has been some discussion on the spec https://review.openstack.org/#/c/130050/23/specs/kilo/ae-tokens.rst
18:37:08 <lbragstad> specifically between nonameentername and gyee
18:37:18 <lbragstad> around the token_version
18:37:21 <lbragstad> vs. token_format
18:37:36 <bknudson> bikeshedding
18:37:41 <lbragstad> and what all needs to be known in order to determine how to unpack the token
18:38:07 <gyee> lbragstad, what's the problem? I don't have any issue with the spec
18:38:17 <gyee> lgtm
18:38:21 <ayoung> OK, so I'm lukewarm about AE
18:38:24 <lbragstad> nonameentername: could you elaborate on the point you were making?
18:38:52 <morganfainberg> ayoung, as long as we have a non-persistent provider in kilo and an easy way to get new providers in, i'm happy
18:39:05 <morganfainberg> the non-persistent provider could be AE, it could be PKI based, etc
18:39:09 <morganfainberg> ayoung, having 1 is important.
18:39:12 <ayoung> morganfainberg, AE as writtend doesn't meet that requirement
18:39:20 <nonameentername> during deployments of keystone there is a period of time when there are two releases.  There should be a way to tell what version the token is.
18:39:20 <morganfainberg> ayoung, it does.
18:39:22 <ayoung> AE does not record role assignements
18:39:26 <ayoung> they are recreated
18:39:29 <jamielennox> lbragstad: this seems like something that can be easily added later if we need it
18:39:48 <gyee> ayoung, it doesn't need to be, just the scope is enough
18:39:56 <lbragstad> nonameentername: and that assumes there is something different, data-wise, between the two tokens
18:39:57 <morganfainberg> ayoung, that doesn't mean it doesn't meet the non-persistent qualifier
18:40:14 <ayoung> morganfainberg, it means we've redefined what is meant by a token
18:40:15 <nonameentername> lbragstad: yes
18:40:15 <morganfainberg> ayoung, like i said, as long as we have a non-persistent provider this cycle i'm happy.
18:40:26 <ayoung> we have that now with PKIZ
18:40:29 <lbragstad> nonameentername: so, with that
18:40:44 <morganfainberg> ayoung, no we don't PKIZ is not-non-persistent as is there is work that is needed to get there on either front
18:40:46 <lbragstad> nonameentername: we can add two extra bits and leave those for the driver to determine what they need it for
18:40:48 <ayoung> we just need to make PKIZ small enough
18:41:04 <ayoung> OK...so
18:41:15 <morganfainberg> ayoung, PKIZ could be the basis, i'm not concerned with which one we end up with or if we have multiples - as long as we hit a non-persistent provider.
18:41:17 <ayoung> 1.  We need a registry of token formats.  Please review that spec
18:41:28 <ayoung> 2.  We need revocation events regardless
18:41:34 <nonameentername> lbragstad: that would work.
18:41:36 <morganfainberg> ayoung, invert those two in priority.
18:41:37 <ayoung> 3.  Revocation events was written in March
18:41:46 <morganfainberg> but yes
18:41:46 <lbragstad> nonameentername: so, something like AE0001?
18:41:49 <ayoung> morganfainberg, they are orthogonal
18:41:51 <ayoung> we need both
18:42:46 <ayoung> AE spec needs special work for Trusts and OAuth as I recall
18:42:48 <nonameentername> lbragstad: yes
18:42:51 <ayoung> has that been addressed?
18:42:52 <lbragstad> ayoung: I reviewed token registry
18:42:58 <ayoung> lbragstad, thank you
18:43:11 <morganfainberg> lbragstad, nonameentername, i think this is a topic that is into implem,entation details now
18:43:35 <morganfainberg> lbragstad, nonameentername, and it does sound a lot like bikeshedding
18:44:13 <ayoung> I think we can work through the rest of my reservactions on AE, but you need to be dilligent
18:44:14 <bknudson> let's just realize that specs aren't written in stone and it's not a justification in a review to say that this was agreed on in the spec.
18:44:14 <morganfainberg> can we continue this in -keystone channel, and work to resolve the issues before looking at AEToken as a viable in-tree provider?
18:44:27 <ayoung> there are a lot of assumptions we need to make explicit
18:44:27 <lbragstad> bknudson: ++
18:44:29 <morganfainberg> bknudson, ++ that works.
18:44:45 <nonameentername> morganfainberg: I agree, this can be done when impelmenting the code.
18:45:07 <bknudson> I'd like to see what the code looks like and also get the other required changes in... e.g., revocation events
18:45:12 <morganfainberg> ok lets move on.
18:45:35 <morganfainberg> #action *EVERYONE* review revocation events - help to get it in place as the default to replace the revocation list
18:46:09 <morganfainberg> moving on
18:46:18 <morganfainberg> #topic Assignment split
18:46:26 <morganfainberg> Henry isn't here, but he's split the review up
18:46:33 <stevemar> mr nash is not present :(
18:46:35 <morganfainberg> please start reviewing it
18:46:42 <morganfainberg> starts here:
18:46:45 <morganfainberg> #link https://review.openstack.org/#/c/144239/
18:46:45 <topol> rumor is he is in Hawaii?
18:47:03 <bknudson> let's spread that rumor
18:47:04 <gyee> business or pleasure
18:47:10 <lbragstad> #link https://review.openstack.org/#/q/status:open+project:openstack/keystone+branch:master+topic:bp/pluggable-assignments,n,z
18:47:35 <morganfainberg> moving on
18:47:39 <morganfainberg> #topic Spec Review
18:47:41 <stevemar> gyee, why not both
18:47:56 <morganfainberg> Please review specs. Lets get the easy ones in prior to the meetup.
18:48:17 <morganfainberg> #topic BPs / reviews that do not need specs
18:48:21 <stevemar> marekd's got a nice spec for redefining the way we get a scoped token for federation
18:48:22 <morganfainberg> bknudson, o/
18:48:25 <stevemar> it's probably the smallest spec that's up there
18:48:54 <bknudson> refactor keystone-all and http/keystone
18:48:54 <morganfainberg> bknudson, you have these please lead us on it. but in short if we agree - we'll note it and those can be merged w/o a spec
18:49:15 <morganfainberg> looking at these i think they can safely be done w/o a spec. (personally)
18:49:16 <marekd> https://review.openstack.org/#/c/145204/
18:49:27 <marekd> and the spec is indeed tiny
18:49:33 <bknudson> so this is about moving code out of keystone-all / http/keystone into keystone.* and then reuse code
18:49:38 <morganfainberg> bknudson, ++
18:49:47 <bknudson> I don't know if we need a vote or what?
18:49:48 <marekd> required for  https://review.openstack.org/#/c/130593
18:50:15 <marekd> stevemar: thanks for bringing it here :-)
18:50:37 <morganfainberg> bknudson, can do a vote
18:51:33 <bknudson> or, if someone doesn't like the explanation on the meeting, can complain about a specific one and then I'll write a spec
18:51:35 <morganfainberg> #startvote Does the refactor of keystone-all and http/keystone need a spec? Yes, No, Abstain
18:51:36 <openstack> Begin voting on: Does the refactor of keystone-all and http/keystone need a spec? Valid vote options are Yes, No, Abstain.
18:51:37 <openstack> Vote using '#vote OPTION'. Only your last vote counts.
18:51:49 <bknudson> #vote No
18:51:55 <morganfainberg> #vote no
18:52:16 <breton> #vote No
18:52:51 <topol> #vote No
18:53:00 <jamielennox> #vote NO
18:53:13 <joesavak> #vote Abstain
18:53:29 * joesavak feels like a true politician now
18:53:31 <breton> I'm not sure why refactors would even need a spec
18:53:42 <morganfainberg> joesavak, I cannot confirm nor deny
18:53:57 <morganfainberg> joesavak or "I am not a crook"?
18:54:00 * topol joesavak show some backbone spineless jello
18:54:12 <joesavak> one of my aides typed that in. I was on the golf course.
18:54:14 <morganfainberg> breton, some refactors are large - and have a lot of moving parts
18:54:17 <dolphm> #vote No
18:54:42 <morganfainberg> breton, this is the whole reason we added the "some bps don't need specs" concept.
18:54:49 <dolphm> i don't think refactors ever need a spec, unless somehow that refactor impacts end users
18:54:54 <dolphm> in which case, it's not a refactor
18:54:54 <morganfainberg> dolphm, want to proxy for dstanek ? ;)
18:54:59 <topol> I did not have relations with that code module keystone-all
18:55:11 <morganfainberg> topol, LOL
18:55:17 <morganfainberg> #showvote
18:55:18 <openstack> Abstain (1): joesavak
18:55:20 <openstack> No (6): morganfainberg, bknudson, dolphm, jamielennox, breton, topol
18:55:31 <bknudson> topol: just wait for the stained dress.
18:55:44 <joesavak> my vote was bought.
18:55:48 <morganfainberg> anyone else? lbragstad, ayoung, stevemar nkinder
18:55:57 <breton> morganfainberg: why a bug isn't enought? How do we differentiate no-spec-refactoring and bug-is-enough refactoring?
18:55:57 <morganfainberg> marekd
18:56:09 <gyee> #vote nO
18:56:23 <rodrigods> gyee, tester heh
18:56:23 <breton> *enough
18:56:27 <jamielennox> morganfainberg: safe to say it's No i think
18:56:31 <morganfainberg> #endvote
18:56:32 <openstack> Voted on "Does the refactor of keystone-all and http/keystone need a spec?" Results are
18:56:33 <openstack> Abstain (1): joesavak
18:56:34 <openstack> No (7): gyee, morganfainberg, bknudson, dolphm, jamielennox, breton, topol
18:56:40 <morganfainberg> yeah bknudson , i'd say it's all good
18:56:48 <bknudson> ok, I'll put a blueprint on it.
18:56:50 <stevemar> #vote no
18:56:50 <morganfainberg> breton, it's because some refactors have a lot of moving parts.
18:56:52 <stevemar> nooo i missed it
18:56:57 <morganfainberg> stevemar, late to the game!
18:57:04 <bknudson> next is "refactoring keystonemiddleware to extract classes"
18:57:07 <ayoung> #vote no
18:57:09 <stevemar> does it even need a blueprint?
18:57:09 <lbragstad> #note no
18:57:14 <lbragstad> #vote no
18:57:15 <jamielennox> stevemar: if it all goes to hell you can at least say it wasnt your fault
18:57:16 <ayoung> #note vo
18:57:16 <stevemar> #note vo
18:57:22 <morganfainberg> breton, and *could* impact deployers and/or users
18:57:27 <lbragstad> stevemar: my dyslexia has set in
18:57:34 <ayoung> #tone loc
18:57:35 <dolphm> if we're using voting, you need to end the previous vote first
18:57:40 <morganfainberg> i did!
18:57:44 <morganfainberg> dolphm, ^^
18:57:44 <topol> #vote no
18:57:57 <morganfainberg> i just haven't started the next vote
18:57:59 <morganfainberg> :P
18:58:10 <ayoung> #phone home
18:58:25 <morganfainberg> #startvote refactor keystonemiddleware to extract classes need a spec? yes, no, idontlikepolls
18:58:26 <openstack> Begin voting on: refactor keystonemiddleware to extract classes need a spec? Valid vote options are yes, no, idontlikepolls.
18:58:27 <openstack> Vote using '#vote OPTION'. Only your last vote counts.
18:58:32 <bknudson> #vote no
18:58:36 <morganfainberg> #vote no
18:58:42 <dolphm> #vote no
18:58:45 <jamielennox> #vote no
18:58:45 <stevemar> can we start up an etherpad for the hackathon?
18:58:47 <breton> well, ok. IMO it wasn't even worth voting.
18:58:53 <stevemar> get some goals outlined there
18:58:53 <marekd> #vote no
18:58:58 <morganfainberg> bknudson, and please do still use a BP (tag it to k2 and set a priority)
18:59:18 <marekd> (this time i didnt miss)
18:59:20 <bknudson> morganfainberg: I'll file bps for all these that we agree on.
18:59:21 <jamielennox> have we ever done a full spec for middleware?
18:59:21 <topol> #vote no
18:59:22 <gyee> #vote no
18:59:25 <gyee> just do it
18:59:29 <stevemar> #vote no
18:59:37 <morganfainberg> breton, the point of voting is to make sure we're clear on not needing a spec.
18:59:48 <morganfainberg> #showvote
18:59:49 <openstack> no (8): gyee, morganfainberg, bknudson, marekd, dolphm, jamielennox, stevemar, topol
18:59:59 <morganfainberg> going in 5
19:00:05 <breton> #vote no
19:00:16 <morganfainberg> annnnnnnnddddd
19:00:19 <morganfainberg> #endvote
19:00:22 <openstack> Voted on "refactor keystonemiddleware to extract classes need a spec?" Results are
19:00:23 <openstack> no (9): gyee, morganfainberg, bknudson, marekd, dolphm, jamielennox, stevemar, breton, topol
19:00:23 <dolphm> #vote bandwagon
19:00:39 <bknudson> out of time... can work on the rest next week
19:00:44 <morganfainberg> bknudson, ++
19:00:46 <dolphm> \o/
19:00:48 <morganfainberg> #endmeeting