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