18:00:53 <dolphm> #startmeeting keystone
18:00:54 <openstack> Meeting started Tue Apr 23 18:00:53 2013 UTC.  The chair is dolphm. Information about MeetBot at http://wiki.debian.org/MeetBot.
18:00:55 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
18:00:56 <dolphm> didn't realize it was already time
18:00:57 <openstack> The meeting name has been set to 'keystone'
18:01:03 <ayoung> #link https://wiki.openstack.org/wiki/Meetings/KeystoneMeeting#Agenda_for_next_meeting
18:01:16 <dolphm> #topic High priority bugs or immediate issues?
18:01:39 <ayoung> DB access can't be atomic for LDAP
18:01:44 <dolphm> bug 1130676 is on the agenda
18:01:46 <uvirtbot> Launchpad bug 1130676 in keystone "DB accesses during user creation should be atomic" [Medium,In progress] https://launchpad.net/bugs/1130676
18:01:52 <bknudson> would make it easier to review if that was split up into smaller changes.
18:02:11 <ayoung> I think we should NACK it.
18:02:17 <ayoung> It sets expectations wrong
18:02:30 <rohitk> so we would think Dolph's way to have a TransactableDriverMixin is one way
18:02:56 <ayoung> rohitk, nope
18:03:03 <rohitk> but the approach which is in the review could be changed
18:03:05 <ayoung> rethink the approach
18:03:05 <rohitk> ?
18:03:16 <ayoung> rohitk, take it this way
18:03:24 <ayoung> assume you do not have a transactional back end
18:03:31 <dolphm> i agree with ayoung's review, but i think we ultimately need to figure out an approach to make potentially transactable operations transactable... so i'd rather it be a -1 on the current pass rather than a -2 for the whole concept
18:03:33 <ayoung> how do you write it to minimize risk?
18:03:52 <ayoung> Band-aid on a sucking chest wound.
18:04:10 <ayoung> We will never have transactions from the token backend, which is actually the more serious issue
18:04:10 <rkanade> We dont touch the other backends at all, and just make those changes for the SQL backend
18:04:31 <bknudson> I prefer only on sql backend, since that's the only one that's got acid.
18:04:43 <dolphm> rkanade: you ARE touching the other drivers
18:04:46 <dolphm> https://review.openstack.org/#/c/25517/4/keystone/identity/backends/ldap/core.py
18:04:47 <ayoung> rkanade, and we don't treat the SQL backend as a "higher class citizen" than the other backends
18:05:09 <topol> that gets us into trouble (see next bug)
18:05:21 <rohitk> Adding another layer between identity api and controller as suggested by Tushar Patil in the review, lots of rework there though
18:05:28 <bknudson> LDAP does have transactions... http://tools.ietf.org/html/rfc5805
18:05:41 <bknudson> some servers might support it
18:05:43 <dolphm> rohitk: that's probably the right approach though, and we can do it one small refactor as a time
18:06:02 <Ryan_Lane> don't assume servers have transactions
18:06:05 <rkanade> Yes, currently we are, for the next patch we dont touch any other backend other than SQL, and we add the TransactableSQLDriverMixin to the SQL Base class?
18:06:30 <Ryan_Lane> or you'll make the implementation unusable for lots of people
18:07:19 <rohitk> dolphm: agreed it seems like a design enhancement than a quick fix
18:07:26 <dolphm> rkanade: can you post that and we'll discuss then? no point in reviewing the current patch if it's already WIP
18:08:06 <dolphm> rohitk: this could be moved from a bug to a blueprint as well
18:08:18 <rkanade> dolphm: Yes, i can do that
18:08:20 <ayoung> bknudson, yeah...*might*
18:09:02 <rohitk> dolphm: sure, I think if we get the blueprint right we can get the code into havana early
18:09:04 <dolphm> cool, we also have bug 1168724 on the agenda
18:09:05 <uvirtbot> Launchpad bug 1168724 in devstack "Horizon log-in failure in grizzly with LDAP backend" [Undecided,New] https://launchpad.net/bugs/1168724
18:09:11 <dolphm> and bug 1168726
18:09:12 <uvirtbot> Launchpad bug 1168726 in keystone "default_domain_id breaks the ability to map keystone  to ldap" [Undecided,In progress] https://launchpad.net/bugs/1168726
18:09:29 <dolphm> i've marked both as grizzly-backport-potential, but that's up to how complicated the fix is
18:09:36 <ayoung> so what is happening?
18:09:43 <spzala> dolphm: both the bugs opened for the same issue for possible fix against devstack and keystone
18:09:56 <dolphm> i understand these were known issues going into the grizzly release
18:09:58 <ayoung> domains are an attribute on the LDAP objects, and if one is not specified, it should be filled in with the DEFAULT value
18:10:04 <topol> devstack one is easy. will submit patch today for review
18:10:06 <ayoung> is it that we need an actual Domain object?
18:10:10 <spzala> ayoung: no
18:10:18 <dolphm> #action dolphm to doc bug 1168724 and bug 1168726 on release notes
18:10:18 <spzala> I have made some code change
18:10:22 <uvirtbot> Launchpad bug 1168724 in devstack "Horizon log-in failure in grizzly with LDAP backend" [Undecided,New] https://launchpad.net/bugs/1168724
18:10:23 <uvirtbot> Launchpad bug 1168726 in keystone "default_domain_id breaks the ability to map keystone  to ldap" [Undecided,In progress] https://launchpad.net/bugs/1168726
18:10:25 <Ryan_Lane> domains are attributes on which objects?
18:10:29 <spzala> #link https://review.openstack.org/#/c/27364/1
18:10:51 <ayoung> Ryan_Lane, yeah...it seems the LDAP world is 50/50 split on that
18:11:00 <Ryan_Lane> ayoung: 50/50 split on what?
18:11:00 <spzala> ayoung: that's the patch i created as fix
18:11:03 <ayoung> half want it as an attribute, half want it as a subtree
18:11:11 <Ryan_Lane> which attribute would be used?
18:11:27 <ayoung> I want to yank domains out of LDAP altogether...make it optional
18:11:34 <henrynash> spzala: basically our controllers assume all backends are "domain aware"….and the LDAP one is only half there
18:11:34 <ayoung> Ryan_Lane, brace yourself
18:11:35 <Ryan_Lane> and would it be mutli-valued?
18:11:56 <Ryan_Lane> unless you have some other plan for global grouos, please don't yank domains from ldap
18:12:05 <ayoung> BBusinessCategory
18:12:05 <spzala> henrynash: thanks.. agree
18:12:08 <Ryan_Lane> hahahaha
18:12:11 <Ryan_Lane> you're kidding me, right?
18:12:19 <Ryan_Lane> is that even multi-valued?
18:12:30 <ayoung> Why would it need to be multi-valued?
18:12:41 <Ryan_Lane> a project can only exist in a single domain?
18:12:41 <ayoung> domain is a single value entity only
18:12:49 <ayoung> Ryan_Lane, correct
18:12:51 <Ryan_Lane> what if you want two projects with the same name?
18:12:52 <ayoung> however
18:12:52 <bknudson> I assume any attribute name chosen could be overridden with a config option
18:12:59 <Ryan_Lane> this is a bad idea
18:13:01 <henrynash> I suggest we divide this into two fixes
18:13:07 <ayoung> Ryan_Lane, project  name does not need to be unique across domains
18:13:26 <spzala> ayoung: agree.. that's what I believe.
18:13:31 <henrynash> a) Just fake up the default domain so v2 access works with LDAP
18:13:43 <ayoung> Ryan_Lane, you missed me ranting about this at the end of the last release and during the dev conf
18:13:46 <henrynash> b) Then get our correct domain implementation fired up and going
18:13:52 <Ryan_Lane> ayoung: how do you have the same project name in two domains if there is a single project ou?
18:14:08 <dolphm> henrynash: you can point v2 to *any* domain
18:14:30 <Ryan_Lane> there's really only a single sane way to do this IMO
18:14:32 <ayoung> Ryan_Lane, well, I am a propoentn of doing domains by subtree, but that is neither here nor there
18:14:49 <ayoung> We need to support both, I think
18:14:53 <Ryan_Lane> support both what?
18:14:54 <ayoung> and that didn't happen in Grizzly
18:15:01 <ayoung> both subtree and attribute
18:15:08 <gyee> if you want it to be distinguished, use distinguished names :)
18:15:10 <Ryan_Lane> attribute isn't going to work
18:15:23 <Ryan_Lane> unless you want the project names to be globally unique
18:15:23 <ayoung> Ryan_Lane, not for you, but for others, it is
18:15:26 <ayoung> hence we need both
18:15:38 <Ryan_Lane> and that can be a security concern
18:15:44 <spzala> henrynash: thanks.
18:15:49 <henrynash> dolphm: is that true? How do you do the "pointing"?
18:15:54 <ayoung> Ryan_Lane, agreed,
18:15:57 <Ryan_Lane> because then you can figure out the project names already in use in other domains
18:16:11 <ayoung> Ryan_Lane, yep
18:16:13 <dolphm> henrynash: keystone.conf default_domain_id
18:16:19 <dolphm> henrynash: it's 'default' by default
18:16:43 <dolphm> henrynash: db_sync will even use that value when creating the initial domain
18:16:44 <Ryan_Lane> supporting two ways of doing this and having one that's basically broken and insecure is probably a bad idea
18:17:02 <topol> Joe Savak wanted it if I recall
18:17:03 <henrynash> dolphm:: ahh, ok, see what you mean…that kind of pointing….
18:17:06 <dolphm> henrynash: there's absolutely nothing special about that domain other than keystone.conf points to it for use by v2
18:17:11 <ayoung> topol, who was it that said they wanted the Attribute way to do domains during the LDAP discussion?
18:17:26 <topol> I think it was Joe
18:17:33 <topol> Savak
18:17:38 <ayoung> #link https://etherpad.openstack.org/havana-ldap-integration
18:17:50 <bknudson> so they wanted some attribute on all projects/users in a domain? like businessCategory=domain1
18:17:52 <dolphm> unfortunately he's not on to defend himself
18:18:00 <topol> It mapped to how they were doing domains
18:18:27 <ayoung> topol, I suspect that they will trip up on what Ryan_Lane just said about unique names
18:18:27 <dolphm> bknudson: is that a domain id or name or domain id == domain name in ldap anyway?
18:18:28 <henrynash> dolphm: sure…I guess it's just the the initial problem is that no default domain get's created, so it would at least let us get off to there races
18:18:30 <gyee> dolphm, we do this traffic court style, if he's not here, we blame it on him :)
18:18:40 <ayoung> Heh
18:18:48 <dolphm> gyee: yay community
18:18:51 <ayoung> gyee, or in this case, we decide to break the approach he is depending on
18:19:43 <ayoung> So I want domains to be subtrees.  And I actually don't want domains at all.  I want this:
18:19:44 <Ryan_Lane> no matter how you guys go about this, someone's approach is getting broken
18:19:46 <ayoung> #link https://blueprints.launchpad.net/keystone/+spec/multiple-datastores
18:19:57 <ayoung> That is in support of the one backend per domain blueprint
18:19:59 <Ryan_Lane> ayoung: domains actually make sense to be stored in ldap
18:20:01 <topol> so what frustrating is domains don't seem to naturally fit in ldap yet folks want it there
18:20:02 <bknudson> dolphm: it could be a name or an id... if the id is a DN then you can set that as the base of the search and if the value is an ID or name you have to do a search to resolve it.
18:20:21 <Ryan_Lane> I don't see why domains don't fit
18:20:33 <Ryan_Lane> it fits perfectly well if you make it a hierarchy, which is naturally is
18:20:39 <dolphm> Ryan_Lane: that's why i'd like to see ldap support relegated to specialized authn/z plugins :)
18:20:59 <gyee> and lookups
18:21:01 <Ryan_Lane> it already is a plugin ;)
18:21:01 <bknudson> maybe separate plugins?
18:21:09 <dolphm> supporting ldap as a first-class identity driver seems like overkill for almost everyone
18:21:25 <Ryan_Lane> 40% of users use ldap
18:21:28 <topol> well we couldnt get consensus on that. and most read only ldaps have just users and groups of users. so adding domains is hacky
18:21:32 <Ryan_Lane> that responded to the survey
18:21:36 <ayoung> You can never have too much overkill.  There is no overkill, there is only open fire and reload
18:21:38 <bknudson> but who wants to use the SQL identity driver? it's not perfect either
18:21:44 <gyee> dolphm, yeah, supporting write LDAP is risk than reward
18:21:49 <dolphm> Ryan_Lane: what percent of that wants keystone to attempt full crud over ldap data?
18:21:50 <topol> read only ldap/ad integration is huge
18:22:03 <topol> I hate write ldap
18:22:07 <Ryan_Lane> dolphm: it depends on the level of CRUD
18:22:11 <ayoung> So...bringing this back on topic
18:22:23 <ayoung> do we have a quick fix rady for the actual bug?
18:22:24 * gyee is standing right behind topod on the hate write LDAP line
18:22:30 <ayoung> If not, please ping me when it is ready
18:22:30 <gyee> topol
18:22:30 <bknudson> we had complaints here about the SQL identity driver because it doesn't lock out users after x attempts, and doesn't have password requirements (length, etc)
18:22:32 <Ryan_Lane> LDAP should only be used for things that can be reused
18:22:47 <dolphm> ayoung: i think this is on topic, supporting broadly different approaches to ldap would be best handled by smaller auth plugins
18:22:48 <spzala> ayoung: https://review.openstack.org/#/c/27364/1 is something I did for a quick fix
18:22:53 <topol> https://review.openstack.org/#/c/27369/
18:22:59 <topol> is for the devstack fix
18:23:02 <Ryan_Lane> yes, but we should have a reference driver
18:23:12 <ayoung> dolphm, true,. although talking through the summit items is at the end of the agenda
18:23:13 <Ryan_Lane> and it should be a sane one
18:24:08 <ayoung> spzala, we looked at doing something in the keystone manage code for LDAP in the past...
18:24:15 <ayoung> would be good it integrate it in there
18:24:33 <dolphm> ayoung: +1
18:24:38 <Ryan_Lane> also, btw, it's probably perfectly sane to just not implement any of the write functions
18:24:40 <henrynash> I think this is indeed related to authn/z….it's because we lump them together and just talk about "the backend" that we get ourselves into problems….we really should have different plugins (as we discused_ fro authz/n
18:24:42 <Ryan_Lane> I doubt people are using it
18:24:47 <topol> my dream is that we find a reference way to support domains in ldap, sahdev codes it up and we all move on with our lives to fun keystone work
18:24:53 <spzala> ayoung: so make changes via keystone-manage script?
18:25:06 <Ryan_Lane> there's a really simple way to do domains in ldap
18:25:07 <ayoung> spzala, we did that for the membership issue, IIRC
18:25:20 <topol> Ryan_Lane, you had me at hello
18:25:23 <ayoung> Ryan_Lane, one subtree per domain?
18:25:33 <Ryan_Lane> ou=domains
18:25:41 <Ryan_Lane> cn=domainA
18:25:48 <Ryan_Lane> cn=projectA,cn=domainA
18:26:00 <spzala> ayoung: if you can please provide me more info or pointer to the work.. that will be very helpful as I am not aware of the past work.
18:26:03 <Ryan_Lane> it's a natural tree hierarchy
18:26:06 <ayoung> spzala, will do
18:26:20 <spzala> ayoung: thanks!
18:26:21 <Ryan_Lane> it fits the design of domains and keeps the exact same design we have for projects
18:26:21 <bknudson> Ryan_Lane: are users under projects or under domains?
18:26:27 <Ryan_Lane> both
18:26:33 <Ryan_Lane> under domains for global members
18:26:38 <Ryan_Lane> under projects for project members
18:26:46 <Ryan_Lane> under roles for role members
18:27:44 <Ryan_Lane> hell, you can have global roles by sticking organizationalRole entries under the domain as well
18:27:48 <topol> Ryan_Lane,  can you work up a simple example for Sahdev to use as a design doc?
18:27:54 <bknudson> Does anybody have their corporate LDAP directory set up like that?
18:28:08 <Ryan_Lane> of course not
18:28:10 <topol> would love to have this documented in a blueprint, then coded, then *DONE*
18:28:19 <Ryan_Lane> but they don't have it set up like our previous designs either
18:28:24 <Ryan_Lane> people make new OUs and such for this
18:29:09 <ayoung> The number one feature for Havan is the automatic provisioning of Users from a centralized authentication store
18:29:22 <dolphm> via auth plugins
18:29:34 <topol> most LDAPs they wont let you change anything. so should I worry about Ryan_lanes proposed changes???
18:29:34 <Ryan_Lane> you mean adding/deleting users and such?
18:29:35 <spzala> Ryan_Lane: can you also please take a look at this ..would be great to have your feedback #link https://etherpad.openstack.org/keystone-ldap-domain-support
18:29:38 <dolphm> against a (most likely) non-ldap identity backend
18:29:47 <Ryan_Lane> topol: keystone wouldn't be changing anything
18:29:48 <dolphm> Ryan_Lane: just adding
18:30:08 <dolphm> Ryan_Lane: well, maybe i take that back
18:30:27 <dolphm> maybe phase 2
18:30:30 <Ryan_Lane> dolphm: so, this is doable… but keystone's way of handling this is… ugh
18:30:38 <dolphm> Ryan_Lane: how so?
18:30:38 <topol> well keystone will work with a read only ldap as is and then you can do whatever you want that makes most sense for read-write ldap (the 2% use case)
18:30:48 <Ryan_Lane> currently it writes entries with their UUID as the naming attribute
18:30:49 <spzala> Ryan_Lane: there is a design doc link, something we talked couple weeks back in IRC meeting.
18:31:05 <topol> yes, that sucks
18:31:18 <bknudson> do we need uuids to integrate with other backends?
18:31:24 <topol> so unreadable.
18:31:31 <dolphm> topol: if the number is really 2% then it shouldn't be supported by keystone out of the box..
18:31:32 <Ryan_Lane> the UUIDs are needed to allow easy renames
18:31:44 <Ryan_Lane> having the uuids isn't a problem
18:31:54 <topol> dolphm, Im having a hard time arguing with you on this
18:32:04 <dolphm> *shrug* i'm not trying very hard
18:32:15 <topol> i figure we are close enough to a ref implementation to be done and move on
18:32:20 <Ryan_Lane> the entry has two unique fields anyway, the uuid and the user/project/domain/etc field
18:32:36 <topol> dolphm, cause I agree with you
18:32:41 <Ryan_Lane> so, you use the name for the naming attribute and add the uuid as a second value of the multi-value attribute
18:33:06 <ayoung> OK. We've spent half the time allotted on this.  Lets get an #action work up the Blueprint for this.
18:33:16 <Ryan_Lane> I'll write up a DIT example for domains
18:33:27 <ayoung> spzala, you want to take point, and include Ryan_Lane 's document as a reference?
18:33:39 <Ryan_Lane> I can also write up an example of how to properly handle adding entries without using uuid as naming attribute
18:33:40 <henrynash> we really must focus on the common use cases…and R/W LDAP is unlikely to be it
18:33:46 <spzala> ayoung, yes
18:33:59 <Ryan_Lane> I'd say prioritize getting read working well, then worry about R/W after
18:34:00 <topol> Ryan_lane and Sahdev should collaborate and come to joint consensus
18:34:16 <henrynash> how about we solve the common case when we have an enterprise ldap with users for authn…and this generates temp user records in our SQL authz backend
18:34:31 <ayoung> henrynash, that is what I said above
18:34:34 <ayoung> autoprovisiniong
18:34:42 <henrynash> I'm with you
18:34:47 <ayoung> the Kent folks aren't here
18:34:47 <Ryan_Lane> so… that's a cache...
18:34:48 <topol> now henrynash is mentioning somehting we really need. and repeating ayoung
18:34:51 <ayoung> but they have an impl
18:35:02 <Ryan_Lane> and it's fine, assuming you're going to invalidate the cache properly
18:35:05 <ayoung> they are supposed to be fragmenting out from their  Federation code base
18:35:24 <topol> henrynash was gonna "review" their code and harvest
18:35:26 <Ryan_Lane> (in fact, it's a good idea, but cache invalidation is hard and this is prone to a security vulnerability)
18:35:38 <ayoung> Ryan_Lane, yep, and it will not solve 100% of the things for 100% of the people, but it is the single most requested feature
18:35:51 <topol> ayoung +1000
18:35:56 <ayoung> Ryan_Lane, you always authenticate against the central IDP
18:36:03 <henrynash> ayoung: we should create the structure and architecture that allows us to let them contribute components we need for this RO authn LDAP and RQ SQL authz
18:36:14 <henrynash> (RW SQL authz)
18:36:30 <ayoung> henrynash, agreed
18:36:47 <topol> hnerynash, agreed
18:36:50 <ayoung> henrynash, I think we need to look at how we are pipelining the auth methods in the V3 api, first
18:37:01 <henrynash> ayoung: +1
18:37:07 <ayoung> right now, only methods that are explicitly named in the token request get processed
18:37:14 <dwaite> +1
18:37:21 <dwaite> (felt the need to agree as well)
18:37:23 <ayoung> but autoprovision is something that always needs to be executed
18:37:26 <topol> I was thinking Sahdev could work with Ryan Lane  just to finish the read write case cause I think that is easier than pulling it out
18:37:30 <dolphm> ayoung: they can lead to a custom plugin though
18:37:49 <ayoung> dolphm, yep, just we don't have the appropriate integration point for that yet
18:38:02 <gyee> ayoung, not sure if I understand
18:38:03 <dolphm> ayoung: what are we lacking..?
18:38:16 <ayoung> dolphm, we need it to happen when we execute the auth plugins
18:38:21 <dolphm> ayoung: replace the Password plugin with your own implementation, have that impl talk to ldap
18:38:35 <gyee> ^^^ what he said
18:38:36 <uvirtbot> gyee: Error: "^^" is not a valid command.
18:38:40 <ayoung> dolphm, yes, but unless I put that in the token request, it will not get called
18:38:44 <dolphm> uvirtbot: stop it
18:38:45 <uvirtbot> dolphm: Error: "stop" is not a valid command.
18:38:48 <ayoung> 1 sec I'll link
18:39:12 <Ryan_Lane> dolphm: I heavily reuse the project structure
18:39:16 <Ryan_Lane> in ldap
18:39:22 <topol> cant we call the identity driver from the auth plugin to provision the user when authenticated
18:39:30 <Ryan_Lane> I'd really prefer not to have to implement that in LDAP and in the database
18:39:44 <Ryan_Lane> I don't use keystone for anything other than getting tokens
18:39:54 <Ryan_Lane> hell, i don't even want to send a password to keystone
18:39:54 <gyee> topol, yes we can
18:39:59 <dolphm> topol: yes
18:40:01 <ayoung> #link https://github.com/openstack/keystone/blob/master/keystone/auth/controllers.py#L349
18:40:13 <ayoung> So only auth methods that are explicitly listed get executed
18:40:27 <gyee> Ryan_Lane, you don't trust Keystone?
18:40:56 <ayoung> gyee, is there any reason that the list of methods *has* to come out of the token request?
18:41:02 <dolphm> Ryan_Lane: 'getting tokens' is sort of a complicated task though... and certainly keystone's first intended use
18:41:09 <ayoung> What if we just always executed each one in the pipeline?
18:41:24 <gyee> ayoung, yes, that's how we know what payload it is
18:41:26 <dolphm> ayoung: what's your goal, exactly?
18:41:45 <Ryan_Lane> dolphm: yes, but I expose multi-tenancy throughout my entire architecture, and LDAP is the only sane way of doing that
18:41:55 <ayoung> dolphm, in this case, we need to autoprovision after the authenticate call completes successfully, but before we do any identity backend work
18:42:15 <Ryan_Lane> I have to have that structure in LDAP. if it's not there, then I need to duplicate it there
18:42:23 <Ryan_Lane> which means I'd need to make keystone calls and ldap calls
18:42:30 <dolphm> we've got like 18 minutes left, so we should move on and carry this conversation to mailing list + blueprints where relevant
18:42:35 <Ryan_Lane> sure
18:42:41 <dolphm> #topic How to kick off v3.1 identity api spec
18:42:53 <ayoung> so ideally autoprovision would be executed right after authenticate when we determined the user was in the cetnral store but not in the local one
18:42:53 <dolphm> henrynash added this to the agenda, but i think the answer is fairly simple...
18:42:56 <topol> Ryan_Lane, you will still write something up for the read write case, correct?
18:43:06 <henrynash> dolphm: yep - you did what I was thinking
18:43:06 <dolphm> step 1) Add v3.1 change log, see....
18:43:12 <dolphm> #link https://review.openstack.org/#/c/26676/
18:43:14 <henrynash> dolphm: and I approved it already!
18:43:15 <Ryan_Lane> I'll write something up for domains and for writing entries properly
18:43:24 <dolphm> start documenting backwards compatible addition into that change log
18:43:40 <dolphm> and document v3.1 specific changes in discrete paragraphs / sections with a v3.1 notice (e.g., New in version 3.1)
18:43:44 <gyee> henrynash, you might approving this too? https://review.openstack.org/#/c/26665/
18:43:49 <dolphm> so, that's that
18:43:51 <henrynash> dolphm: just wanted to get an agreed approach before we got started
18:44:01 <dolphm> #topic Havana API-level feature freeze
18:44:09 <dolphm> (related to v3.1)
18:44:33 <ayoung> dolphm, I assume you want Feature freeze to be yesterday?
18:44:37 <dolphm> in every release, we've regretted not doing a feature freeze a milestone ahead of all the other projects
18:44:55 <dolphm> as a first swing at that, i'd like to have an API-level feature freeze at the end of Havana-m2
18:45:18 <bknudson> are we going to have a branch for Ixx after Havana-m2?
18:45:19 <topol> +1 on earlier feature freeze than the other folks
18:45:30 <dolphm> which means v3.1 freezes at the end of Havana-m2
18:45:31 <ayoung> dolphm, not sure I agree
18:45:39 <ayoung> I think that features other proejcts depend on, yes
18:45:52 <dolphm> whatever api features don't land wait until havana+1 and fall under the umbrella of v3.2
18:45:55 <ayoung> but there are other features that are not going to get consumed until they get into Keystone
18:46:09 <dolphm> ayoung: those features can wait while we focus on stability and client support
18:46:15 <ayoung> soe we write them for Havana, but people won't write to them until I time frame
18:46:16 <topol> ayoung, not sure I follow
18:46:20 <ayoung> topol, Trusts
18:46:26 <ayoung> no one is using trusts yet
18:46:33 <ayoung> but thay can't until we write them
18:46:45 <ayoung> so if we punted on them for Havana, not one would be able to even start writing to them
18:46:48 <dolphm> this will give us time to implement and consume trusts within a single release cycle, for example
18:46:52 <ayoung> same think with PKI tokens
18:46:57 <ayoung> we put them in, buthad them disabled
18:47:31 <ayoung> I think what you really mean dolph ios that we should focus on "do it in a plugin in an external project first" approach, which I fully support
18:47:41 <topol> if we dont get them avail early for peer review we are morte surprising them with stuff than providing them with stuff
18:47:52 <ayoung> I also think you mean  "featuer freeze is a hard freeze, not a soft freeze" and I support that too
18:48:04 <dolphm> the m2/m3 distinction is conditional on a three milestone cycle as we did in grizzly, i haven't looked at the draft release schedule to see if that's changing yet, but either way the goal is a milestone early
18:48:26 <dolphm> ayoung: i mean both
18:48:59 <topol> the early feature freeze gives us a chance to be agile and adjust when we slightly miss stakeholder needs
18:49:29 <ayoung> dolphm, OK, lets tkae it for a goal.  It is an internal constraint, and not a bad one.
18:49:32 <ayoung> take it
18:49:47 <dolphm> #topic Priorities following summit Summit etherpads
18:50:04 <dolphm> so, i'm working through our etherpads and working on some blueprints based on those discussions/conclusions
18:50:26 <ayoung> dolphm, I've been doing the same
18:50:30 <dolphm> if anyone wants to do that for something you want to work on, go for it, just link to the new bp in the etherpad so i don't create a dupe :)
18:50:34 <gyee> dolphm, I intend to get endpoint-filtering in by m2
18:51:02 <dolphm> gyee: cool
18:51:05 <gyee> not sure about domain quota though, that's above my pay grade
18:51:11 <topol> Im stating with Apache-Keystone in devstack. will write the bp today
18:51:20 <ayoung> topol, +5
18:51:41 <chmouel> topol: pretty cool
18:51:53 <dolphm> topol: thanks
18:51:56 <ayoung> dolphm, might I suggest that all blueprints must have, at a minimum, an implementor assigned in order to not be ignored or disapproved?
18:52:02 <henrynash> I'm working on inherited domain roles (or whatever solution we need for that problem) and some of the keystone performance issues
18:52:08 <ayoung> Someone has to commit to the task or it is just spinning
18:52:08 <dolphm> topol: i assume devstack has it's own bp's
18:52:18 <dolphm> topol: https://blueprints.launchpad.net/devstack/
18:52:24 <topol> it does but I will notify you
18:52:27 <ayoung> #link https://blueprints.launchpad.net/devstack
18:52:41 <topol> yes, thank you for thinking of me
18:52:43 <henrynash> …and sign me up to work with however on splitting out authz/n and domain backends with autoproviioings
18:52:55 <dolphm> henrynash: will do
18:53:08 <dolphm> henrynash: related https://blueprints.launchpad.net/keystone/+spec/pluggable-remote-user
18:53:18 <morganfainberg> henrynash: if you need any help with that let me know.  I'm more than happy to assist with that stuff.
18:53:22 <topol> I agree with ayoung, for each task who is the one person losing sleep on whether it gets done or not
18:53:26 <henrynash> dolphm: indeed
18:53:29 <ayoung> topol   hmmm,  I tagtged this as implemented, and it blamed me for it.  Can you tajke credit for it somehow ?  https://blueprints.launchpad.net/devstack/+spec/ldap
18:53:39 <dolphm> CERN basically wants REMOTE_USER pluggability for x509 grid certs + auto provisioning
18:53:59 <dwaite> topol: can we nominate people to be the ones to lose sleep for a particular task?
18:54:13 <ayoung> dwaite, only if they have expressed interest
18:54:27 <dwaite> ayoung: aww, guess thats fair
18:54:34 <ayoung> dwaite, it you write a blueprint, park on it until you have someone to implement it for you
18:54:34 <topol> dwaite, only if they consent
18:54:35 <Ryan_Lane> I'd also like REMOTE_USER + ldap for project/role/user info
18:54:47 <Ryan_Lane> I basically want LDAP for everything except authentication
18:54:48 <ayoung> Ryan_Lane, I think that works now
18:55:01 <ayoung> REMOTE_USER implies HTTPD from Apache
18:55:05 <ayoung> or comparable web server
18:55:06 * Ryan_Lane nods
18:55:20 <ayoung> I want S4U2Proxy and Kerberos, + LDAP
18:55:28 <henrynash> Ryan_Lane:….that seems weird, I think we want to optimise for the case of LDAP for authentication ONLY!
18:55:28 <dolphm> (5 minutes)
18:55:34 <topol> Ryan_Lane is hurting my head. Most folsk want ldap for only authentication
18:55:39 <dolphm> #topic open discussion
18:55:44 <Ryan_Lane> henrynash: ldap authentication sucks
18:55:45 <dwaite> REMOTE_USER is a CGI thing, see rfc3875
18:55:45 <dolphm> since we're back to ldap :)
18:55:54 <Ryan_Lane> it's password authentication
18:56:06 <Ryan_Lane> or kerberos via passthrough
18:56:08 <ayoung> Ryan_Lane, what do you want instead?  X509?
18:56:09 <topol> termies nosetest option is breaking sahdev as well as me. how do we fix that
18:56:16 <spzala> I ran into problem running run_tests.sh with the latest code http://fpaste.org/tLAR/
18:56:22 <Ryan_Lane> ayoung: I'd really like oauth
18:56:24 <dwaite> ayoung: what do you want S4U for?
18:56:26 <ayoung> Ryan_Lane, ah, yeah, Kerberos
18:56:30 <morganfainberg> Ryan_Lane: but LDAP authentication is how enterprises (effectively) use AD for authn but still want authz in keystone.
18:56:35 <henrynash> not another nose test break….damn, I approved that one too!
18:56:43 <Ryan_Lane> morganfainberg: you assume that's the case :)
18:56:47 <dolphm> Ryan_Lane: i added your name to that bp
18:56:48 <ayoung> dwaite, I want to auth via Kerberos and then have the operations against he LDAP backend performed via the users context
18:56:53 <ayoung> not an "admin"
18:56:56 <topol> sign stevemar up for OAuth, dolphm,  you have my expressed written consent to do that
18:56:57 <Ryan_Lane> people who actually know LDAP really well don't use it that way
18:57:17 <dolphm> topol: i put termie on the bp, stevemar can finish it
18:57:18 <ayoung> AD is kerberos for services that support it
18:57:20 <morganfainberg> Ryan_Lane: i wish i could say that from experience it is done differently.
18:57:21 <dwaite> ayoung: agh, yep, that would do it. But is AD still the only KDC supporting S4U? (haven't kept up, since I did a bunch of work with S4U back in 2004)
18:57:31 <topol> dolphm, exactly what will happen :-)
18:57:33 <ayoung> dwaite, we use it in FreeIPA
18:57:35 <dolphm> termie put oauth up for review
18:57:36 <ayoung> so it is in MIT
18:57:41 <dwaite> groovy.
18:57:42 <ayoung> SCHWEET!
18:57:46 <Ryan_Lane> if you guys make an account, you can see how I'm extending the multitenancy concept in LDAP: https://wikitech.wikimedia.org
18:57:55 <stevemar> #link for those interested in oauth: https://blueprints.launchpad.net/keystone/+spec/delegated-auth-via-oauth
18:58:00 <Ryan_Lane> I'll give you shell access, and you can search my DIT
18:58:16 <dwaite> I'm working on approval to work on an oauth 2 implementation
18:58:20 <ayoung> Ryan_Lane, so you want Kerberos?
18:58:30 <Ryan_Lane> ayoung: no, I definitely don't want kerberos :)
18:58:39 <ayoung> Then what?
18:58:42 <topol> dolphm, what about the nosetest option issue. its annoying
18:58:43 <Ryan_Lane> I want people to login through the web interface and be given a token that they can use through the cli
18:58:53 <Ryan_Lane> or for the web interface to act on their behalf
18:59:01 <dolphm> topol: what issue?
18:59:05 <Ryan_Lane> but I don't necessarily want them to login with a password
18:59:13 <dolphm> dwaite: cool
18:59:14 <spzala> dolph, #link http://fpaste.org/tLAR/
18:59:24 <dolphm> dwaite: i assume you don't mean from me lol
18:59:40 <dwaite> dolphm: if only it was from you :D
19:00:02 <ayoung> spzala, why no venv?
19:00:08 <topol> dolphm, I checked git blame and it was due to something termie added
19:00:13 <dolphm> ayoung: because it's faster to manage your own
19:00:23 <topol> ayoung, must we now use venv?
19:00:24 <dwaite> would I create a new blueprint for oauth2 or attach it to termie's?
19:00:25 <dolphm> spzala: update nose
19:00:30 <dolphm> topol: no
19:00:36 <spzala> ayoung, I usually do but to create error nicely I selected no.. though even with venv error is there
19:00:49 <topol> dolphm, should we pull termies options off?
19:00:50 <ayoung> dolphm, the --with-openstack  breaks if you run the tests outside of venv.
19:00:57 <dwaite> oh no, time's up :|
19:00:59 <spzala> dolph, ahhh ... OK. thanks!
19:01:02 <ayoung> spzala, no, it should not be
19:01:23 <dolphm> ayoung: is that an issue?
19:01:26 <spzala> ayoung, hmmm... i did it that way too to make sure
19:01:27 <ayoung> but the issues is where does --with-openstack come from
19:01:37 <topol> comes from termie
19:01:41 <ayoung> dolphm, if you run -N you see the error spzala is talking about
19:01:45 <dolphm> it's a nose plugin
19:01:49 <ayoung> I run in an venv and no problem
19:01:51 <dolphm> ayoung: lies
19:02:01 <spzala> ayoung, something with virtual machine that it ididn't update node with venv like it supposed to?
19:02:18 <dolphm> just pip install -r tools/test-requires
19:02:19 <dwaite> dolphm; process-wise would oauth 2 be a new blueprint?
19:02:22 <ayoung> dolphm, what is the nose plugin that provides --with-openstack
19:02:35 <spzala> ayoung, will verify it again.
19:02:37 <dolphm> dwaite: yes, and land as an extension similar to termie's oauth implementation
19:02:42 <dwaite> ok
19:03:03 <dolphm> ayoung: pip install openstack.nose_plugin
19:03:05 <gyee> dolphm, what's the timeline for Havana again?
19:03:08 <ayoung> dolphm, thanks
19:03:10 <dolphm> gyee: unreleased
19:03:15 <ayoung> dolphm, that should go in hacking, I think
19:03:16 <dolphm> gyee: watch mailing list this week
19:03:29 <gyee> m2 would be mid June'ish?
19:03:33 <dolphm> next summit is nov 4-9, so before then
19:03:38 <dolphm> gyee: dunno
19:04:07 <dolphm> ayoung: it's in tools/test-requires, so no, it has no need to be in hacking
19:04:10 <ayoung> dolphm, yep, that is the trick.  spzala I ran sudo easy_install openstack.nose_plugin to get it
19:04:11 <topol> dolphm, so I do a  pip install openstack.nose_plugin to fix this?
19:04:29 <ayoung> topol, or easy_install
19:04:38 <ayoung> OK, we are over time
19:04:49 <spzala> ayoung: Cool. Thanks!!
19:04:58 <topol> moving over to openstack-dev
19:05:02 <dolphm> topol: yes, or just run pip install -r tools/test-requires
19:05:13 <dolphm> topol: perhaps with an --update
19:05:31 <dolphm> #endmeeting