18:01:58 #startmeeting keystone 18:01:59 Meeting started Tue Apr 2 18:01:58 2013 UTC. The chair is dolphm. Information about MeetBot at http://wiki.debian.org/MeetBot. 18:02:00 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 18:02:02 The meeting name has been set to 'keystone' 18:02:17 #topic RC3 18:02:45 we cut RC3 this morning with the db engine/connectionpool issue fixed, along with termie's patch to v3 auth 18:03:11 we have two more days in grizzly but it looks like RC3 will ship as grizzly unaltered (no RC4) 18:03:37 basically anything else triggering a new RC has to be a critical issue 18:03:38 congrats!!! 18:03:41 Keysteon! 18:03:46 Keystone! 18:03:51 did you consider this one: https://bugs.launchpad.net/python-keystoneclient/+bug/1161633 18:03:54 Launchpad bug 1161633 in tempest "V3 token fails with KeyError 'expires'" [Undecided,In progress] 18:03:54 grats everyone :) 18:04:05 bknudson: clients are not held to the release cycle 18:04:10 ok 18:04:13 bknudson: we can push a new version anytime, and will be doing so soon 18:04:20 that's my next priority before the summit 18:04:26 #info Hello everyone, For clients changes, is it also needed bluepirnts? 18:04:44 EstevaoHessHP_: it's a looser process, but yes, we have blueprints for keystoneclient 18:04:52 https://blueprints.launchpad.net/python-keystoneclient/ 18:04:58 dolphm, did you "global engine everywhere" patch pave the way for doing in memory sqlite for all of the tests? 18:05:13 ayoung: yeah, that was the original goal 18:05:17 Thanks Dolphm 18:05:23 #topic State of LDAP in Grizzly 18:05:49 so, i don't have that much insight into ldap proceedings / what's lacking / etc 18:05:49 is anyone planning to use the LDAP backend? 18:05:56 so i was hoping our ldap crew could chime in? 18:06:06 bknudson, UI would expect so 18:06:12 bknudson: absolutely 18:06:20 aside from the amount of work CERN did early in the release on AD issues for LDAP 18:06:41 we have a significant effort from the IBMers on making LDAP a first class citizen Id Provider 18:06:49 I have code up for review for roles grant to ldap group #link https://review.openstack.org/#/c/25329/ 18:06:52 i'm primarily asking because any problems need to be reflected in https://wiki.openstack.org/wiki/ReleaseNotes/Grizzly#Known_Issues_5 18:06:59 topol, comment? 18:07:12 are we going to provide migrations for anyone using LDAP in G to H? 18:07:15 spzala, that is ready to go? 18:07:26 bknudson, I think we are going to have to 18:07:33 at a minimum, for p[eople using the default schemas 18:07:35 ayoung: Yes, I think so. 18:07:47 bknudson: yes 18:07:49 so doing double duty, slow to respond. but if necesary we should provide migrations 18:07:50 ayoung: I tested with ldap live test and that went well. 18:08:00 bknudson, the way we are doing domains for Grizzly is under review, and will most likely change in H 18:08:01 a document, if not an automated approach 18:08:29 spzala, looking at Roles patch now 18:08:41 ayoung: cool. Thanks! 18:08:43 with rc3, could a havana ldap deployment use v3? or would you need to remove ldap from the pipeline? 18:09:11 spzala, BTW, I am not going to recommend holding up the release for it, but we can certainly try to get it backported to Grizzly Stable. 18:09:12 or is it only new grizzly features that aren't implemented (grant role to user on domain?) 18:09:31 ayoung: I have also added in today's agenda about possible redesign approach for ldap domain in Havana. 18:09:42 ayoung: it's far too late for new features to land in grizzly 18:09:57 dolphm, oh, yeah 18:10:19 dolphm, so here's the short on the Havana Domains thing 18:10:23 ayoung: OK, that sounds great to me. 18:10:34 right now, domain is an attribute on just about everything 18:10:44 and the attribute we are using is...suspect... 18:10:53 it is a misappropriation 18:11:10 but domains indicate a higher level of separation anyway 18:11:19 and the LDAP way is for each domain to be in their own subtree. 18:11:25 ayoung: we have businessCategory for domain_id attribute. 18:11:33 so, for a single domain deploy, G and H will look roughly the same 18:11:51 fo a G deploy with two domains, we will have to port one of them to a separate subtree 18:11:59 spzala, yep. 18:12:03 ayoung: is that an issue with grizzly, or is that just a non-ideal compared to the plans for havana? 18:12:19 dolphm, this is the plan for Havana 18:12:30 in grizzly, we use the attribute 18:12:38 ayoung: for now, i need to know what won't work in grizzly w/ ldap :) 18:12:39 and we will need a migration plan for havana 18:12:39 ayoung: yes, about domain specific sub tree, that's what I have tried to have in design for which I have a etherpad link later in the agenda. 18:12:44 the rest is summit-speak :) 18:13:15 dolphm, yep, I've moved on. Unless there are fires to put out, I'm not Hunting Grizzlye's anymore 18:13:24 spzala: can you summarize what was implemented here and add it to known issues for grizzly? https://review.openstack.org/#/c/25329/ 18:13:50 spzala: assuming it poses a blocker for a grizzly deploy, and it's not a forward-looking feature add 18:14:10 dolphm: sure. So this one is mainly granting the role to the ldap groups 18:15:02 so what i want to confirm: v3 + ldap in grizzly has feature parity with v2 + ldap in folsom, correct? 18:15:05 dolphm: also I tried to have generic grant for groups and uses as it was designed in the tests 18:15:22 just want to make sure we haven't moved backwards 18:15:27 dolphm, it limits grizzly/ldap usability, but does not completely destroy it. It would be sad to be missing, and I would argue for putting it into Grizzly stable, but it should not block the release 18:15:41 ayoung: i'm not opposed to seeing that argument 18:16:00 dolphm: agree with ayoung. 18:16:02 dolphm, I don't think we are missing anything that was in V2 LDAP in Folsom/ 18:16:12 ayoung: spzala: bknudson: henrynash: topol: (and anyone else) if ya'll want to make enough noise to see that patch backported, do it on the mailing list, but you're facing very low adds at this point 18:16:25 ayoung: thanks 18:16:54 #topic Review, revise & amend Keystone's release notes 18:17:05 #link https://wiki.openstack.org/wiki/ReleaseNotes/Grizzly#OpenStack_Identity_.28Keystone.29 18:17:15 on this topic, sdague posted to openstack-dev ... 18:17:24 sdague: currious what the expected upgrade path is for keystone folsom users is, as the keystone folsom config doesn't seem to work at all with grizzly code 18:17:41 we already touched on this, but go revise release notes :) 18:17:48 i'm sure there are upgrade issues and new features i didn't capture 18:17:54 so add what you worked on! 18:18:02 make sure people know about all our goodness 18:18:07 and related.... 18:18:07 sdague didn't say what the problems were. 18:18:14 #topic Grizzly Documentation 18:18:53 openstack-manuals needs some love -- everyone should take a pass through everything keystone related and make sure everything is up to date and that we're not documenting deprecated options, etc 18:19:22 #topic Design summit sessions 18:19:33 #link http://summit.openstack.org/ 18:19:36 what's the schedule for the documentation? 18:19:44 does it have to be done at the same time as release? 18:19:58 bknudson: we have about a month window until docs open for havana 18:20:24 i'm happy to hear proponents & opponents of seeing any given session on the agenda 18:20:26 dolphm: thanks... I might have some time at the end of the month. 18:20:47 So..I have a scheduled session on FreeIPA integration that is in the security track 18:20:56 and I am unsure what the state of it is 18:21:07 As it shows up on the schedule 18:21:20 my primary goals in scheduling sessions is simply that there will be an engaging discussion with a useful conclusion impacting the future of keystone dev in havana 18:21:38 dolphm: so I updated http://summit.openstack.org/cfp/details/157 as requested 18:21:51 henrynash: i haven't reviewed yet, but thank you :) 18:21:57 Or at least it was... 18:22:05 ayoung: where are you looking? 18:22:12 i haven't pushed anything to the schedule yet 18:22:16 nor scheduled anything 18:22:21 dolphm, just got a link from our PR person that was tracking it...one sec 18:22:33 dolphm, it happend before you, but maybe it got nixed 18:22:51 ayoung: i think ttx reset some scheduling stuff when he opened it for final scheduling 18:23:03 ayoung: i'm not clear on the details of what happens after the review process 18:23:07 http://openstacksummitapril2013.sched.org/event/02841e3d64620e15b861db63628735bd#.UVsiBeOuI95 18:23:38 But maybe that session is now orphaned. 18:23:59 ayoung: the primary issue with your that session is that it's about how to integrate a tool with openstack, and doesn't concern the development of keystone in havana 18:24:19 Ah...it is scheduled at the same time as a Keystone session, but it is not in the Keystone track 18:24:30 dolphm, right...so here is my thinking 18:24:34 ayoung: final schedule will be settled on April 9th, i'm not sure what sched.org will reflect until then 18:24:58 dolphm, I'll try to get it bumped earlier, so people don't have to choose between Keystone and Security tracks 18:25:16 basically, it ties in with the technology overview 18:25:23 it is easier to say FreeIPA than to say 18:25:33 Kerberos, LDAP, X509 and DNS 18:25:56 ayoung: there's definitely a track for such sessions that would be a better fit than keystone, but i'm not sure what that would be (there's workshops at every summit, but i don't know what they fall under) 18:26:13 o/ sorry i'm late 18:26:17 joesavak: o/ 18:26:19 And if affects components beyond just what Keystone does. For example, looking at securing the Database connections for multiple Keystones talking to one DB 18:26:41 this was a late submission by nsavin -- http://summit.openstack.org/cfp/details/239 18:26:54 (nsavin -- i assume you're not here?) 18:27:23 dolphm, merge with HATEOAS? 18:28:06 i'm happy to see an architecture discussion, but there's no precedence for needing such a session -- this is out of the blue 18:28:26 ayoung: there's a HATEOS session? 18:28:31 dolphm, so the thing about the FreeIPA talk is it ties in with the other talks about security technologies. 18:28:41 dolphm, it is on today's agneda 18:28:56 #link https://wiki.openstack.org/wiki/Meetings/KeystoneMeeting 18:29:10 known issues for summit? 18:29:17 yes 18:29:31 no session was proposed on the topic 18:29:37 just that the SOA and HATEOAS subjects both address organization of the URLS and resources under Keystone. 18:29:54 ah 18:29:56 dolphm, yeah. We can do a session on it, but we seemed to be full up 18:30:11 ayoung: we're well over 18:30:23 I was OK with continuing the discussion in IRC/mail, as I think that it is sufficient to address 18:30:25 need to cut at least 3 session at this point 18:30:38 we can also have some casual talks between developers over it, but no need to steal an hour for it 18:30:59 I've posted my WIP to get things rolling, and that should suffice, I would think 18:31:05 ayoung: to do -- summit sessions are intended to hash stuff out that has proven to be difficult to discuss/design over email, irc, etc 18:31:40 i'd like to have a regular "keystone unconference" for the days leading up to our track 18:31:46 dolphm, +2 18:32:00 just open floor for a couple days 18:32:09 +1 18:32:25 dolphm, I think the single largest issue we should address is how to move beyond bearer tokens. The rest is implementation details 18:32:51 LDAP support def needs people to come together to voice their requirments 18:33:11 ayoung: agree, that's a bit of dwaite's session and (as i understand) henrynash's session on generic auth 18:33:54 i assume oauth2 will be the topic of conversation for both those sessions, unless there's a strong argument for another contender 18:34:01 dolphm, there are two sides. One is using a mechanism that is not yet part of Keystone, but the other is what to do about the current token architecture. 18:34:26 dolphm, oauth1, not 2, if termie has anything to say about it...and I think I agree with him on that 18:34:48 ah, i'm not familiar with the differences 18:34:51 but that is delegation, which doesn't address the fact that current tokens are bearer tokens 18:34:53 I am hoping that there is enough overlap that maintaining the current token architecture is not a headache 18:34:55 and i'm honestly not sure which i've used 18:35:00 why oaut1 instead of oauth2. I believe oauth2 is getting good traction 18:35:21 ayoung: +1, that is what i've been been reading about 18:35:31 topol, that needs to be an unconference brawl...er..discussion 18:35:49 "Many services such as Facebook, Github, and Google have already deployed OAuth 2 servers, and deployed implementations win." -dwaite's session http://aaronparecki.com/articles/2012/07/29/1/oauth2-simplified 18:35:50 or something 18:36:20 I'd be up for a gentleman's brawl! 18:36:26 the summit should be a brawl, i hope that's clear to everyone 18:36:31 or nerf guns at 20 paces 18:36:39 dolphm: what about OpenID Connect ? 18:36:40 warren zevon song??? send lawyers, guns and money.. 18:36:52 zykes-: what about OpenID Connect in particular? 18:36:53 dolphm, as I have learned, we ignore termie at our peril. He stated something to the effect that 2 is not a valid replacement for 1....lets just make sure we get on the same page as far as delegation goes 18:37:01 powerpoint slides and polite clapping shouldn't be expected 18:37:17 I personally want to do the foam-rubber larp type sword fighting thing myself 18:37:29 dwaite: nothing in particular 18:37:39 zykes-: dwaite: was openid included/excluded from your talk? if excluded, reason why? 18:37:41 There are a slew of standards to consider 18:37:59 openid 1/2, yes. Openid connect, no. 18:38:12 I think they fall into two camps: enterprise and web. 18:38:20 I would like to cover it, but I'm trying to reduce scope so there is discussion/brawling time 18:38:46 On the enterprise side is the technologies I'm addressing in the FreeIPA session. On the Web side we have dwaite 's session 18:38:55 ayoung: +1 on the "let's make sure" 18:39:11 oauth 1,2 SAML, openid, and so on 18:39:14 I am btw very disappointed the Free IPA site does not have a form where I can submit my details to receive beer at no cost 18:39:29 i'd have thought the key thing for us is to agree how we modify keystone to allow the various studs to be supported/plugged in by those who require the, 18:39:41 1: Saml, 2: OAuth, 3: OpenID, 4: SCIM is my order 18:39:46 studs? I mean standards !!!! 18:39:47 We should remember that AMQP is a fundamental portion of OpenStack and that we need to support non HTTPS technologies 18:40:00 joesavak: OIC then, isn't that OpenID + OAuth2 ? :) 18:40:10 dwaite, no, it is Free and in Free Quid, Guvnah. 18:40:13 as in 18:40:18 henrynash: at the api / project integration level or in implementation? 18:40:21 oauth authZ and openID authN 18:40:36 authZ more important for partner use cases. ; ) 18:40:45 henrynash: because implementation is for code review, although working implementations are welcome talking points at the summit 18:40:47 so api/project integration must be first 18:40:53 henrynash: cool 18:41:01 fyi for you guys, check out: https://github.com/rohe?tab=repositories 18:41:03 joesavak, so there is the perpetual session from Kent to remember as well. Closes the summit once again 18:41:07 OpenID Connect is a profile on top of OAuth 2.0, if we don't get to it in sessions I'll def. unconference it 18:41:19 love it. The only reason why I attend 18:41:23 ;) 18:41:27 http://openstacksummitfall2012.sched.org/event/23f0a08262c18dc00007fea69e97c1f2 18:41:33 I'll get an outline together for next week of the topics to better judge time 18:41:37 A dude at the Ume� university of Sweden that has done alot of work on it fyi! 18:42:04 dolphm: i requisitioned some custom tools for the summit 18:42:08 better described: "Federation Lab" is a collaboration between some entities about Federation 18:42:13 dolphm: we'll see whether they are fabricated in time 18:43:33 termie: i'm not sure i should anyone should feel comfortable with your definitions of "tools" lol 18:43:35 termie, the two technologies you've brought up recently are Cassiopea [sp/] and oauth 1. Anything else that you think needs to be on the agenda? 18:43:44 i or anyone should* 18:43:47 ayoung: uhhhhh 18:43:54 ayoung: cassandra 18:43:57 termie, if beer is made available Im in 18:44:08 right mythos, wrong damsel 18:45:02 lol 18:45:16 And we all know what happens to people that don't listen to Cassandra. The greeks get 'em 18:45:16 topol AND savak 18:45:23 it's all mispelled star trek in here 18:45:24 so i know this is going to take the next 15 minutes up pretty easily... 18:45:28 #topic Discussion/review request for LDAP domain design for Havana 18:45:34 #link https://etherpad.openstack.org/keystone-ldap-domain-support 18:45:41 (not sure who put this on the agenda?) 18:45:45 dolphm: I have added this in 18:45:55 dolphm, I thought we covered that already 18:46:03 Savak is correctly spelled star trek. 18:46:10 dolphm: this is about a blueprint I am working on for ldap domain support re-design 18:46:11 #link https://docs.google.com/file/d/0Bw37kS-ubhFMdzM5QlVCUGI5ZWc/edit?pli=1 18:46:15 did we discuss that ^ ? 18:46:29 dolphm, yep 18:46:30 er - n/m 18:46:33 lets make sure. want to get it right 18:47:06 thought to have it out mainly for ayoung, henry-nash and all interested parties in LDAP's feedback 18:47:09 topol, this is probably not the forum for it 18:47:36 I think that it is best discussed at the Summit, when we can pull in non-keystone devs with an interest in the LDAP back end 18:47:41 ayouhng, agreed, but at least people can start looking at it in their copious spare time 18:47:45 and get them to confirm/deny 18:47:52 agreed 18:48:06 definitely need stakeholder input from other teams 18:48:10 topol, those of us that know LDAP have already discussed it, and I summarized for the rest. PLease, all feel free to ask questions. 18:48:20 OK good 18:48:53 joesavak: saavik? 18:49:15 joesavak: there's probably a savak too though, vulcans and their names 18:49:23 this new design requires changes to the ldap schema? 18:49:39 i bet vipul is one too 18:49:55 ayoung: if can please take a look at the doc and tell me that I have put it in a right way, that would be very helpful. 18:50:02 ayoung: so that I stay in the right direction 18:50:19 bknudson, let me be specific 18:50:20 can i get someone to look at https://review.openstack.org/#/c/25298/ - RST doc changes for the old 2.0 stuff 18:50:31 in this case, it requires no changes to the schema 18:50:40 it does change the assumptions about the layout 18:50:57 there are ? for domain_id. 18:51:07 bknudson: 18:51:11 and it will stop using the businessCategory attribute 18:51:19 Is this meant to match any existing LDAP deployment? 18:51:52 bknudson: we have domain_id but with layout change I think it's not needed but I wanted to have it there for feedback 18:52:07 bknudson, I would say that it is meant to match best practices for LDAP, so it is more likely to match an existing LDAP setup 18:53:22 why not ou=default container for the default domain rather than default domain is right under root? 18:53:34 ayoung, other thing we should do (if not done already) is look at the LDAP support the apache ldap authorization module provides to perhaps steal some best practices from that 18:53:54 topol, good idea 18:53:56 general ldap question: how much of this is configurable in keystone for deployments? what's not configurable or has very little flexibility? 18:53:56 I don't think apache has projects. 18:54:14 bknudson, mod_auth_ldap 18:54:18 bknudson: thought good idea to keep it the same way we have in originally for the default in stead of adding a 'default' in the tree 18:54:42 spzala, agreed 18:54:45 there's just some unique things about openstack... it has projects, which other apps don't have. 18:55:07 (five minute warning) 18:55:37 it is unlikely that most people are going to use multiple domains, and for those deployments, we want to keep the tree sane. However, for multiple domains, we might want to be able to specify the segment for the default domain 18:55:51 I would not hard code it to 'default' 18:56:08 CONF.default_domain_id? 18:56:09 and, it might be that the entire DN chain is different 18:56:12 ayoung: that sounds good to me, the diagram has ou=Users right under root. 18:56:51 dolphm, perhaps, or perhaps we state that domains must be listed in the config file. We need a way to be able to enumerate them, 18:57:11 I opened this blueprint as a placeholder 18:57:28 https://blueprints.launchpad.net/keystone/+spec/json-for-ldap 18:57:43 we can axe that if it is unnecessary 18:57:58 I suspect that creating a domain will be an unusual activity 18:58:19 ayoung: one step further, it almost makes sense to make the ldap driver an external project... 18:58:22 and I am OK with inflicting a little extra pain upon domain creation for that reason 18:58:35 so whatever we do, we need to make sure that is a customer only has users and groups of users in their ldap we understand how we map them given they dont have domains or projects in ldap 18:58:36 ayoung - we're using domains for customers 18:58:45 so hopefully it's not too unusual 18:59:02 or ldap domain? 18:59:04 joesavak, how often do you create a new domain? Hourly, daily, monthly? 18:59:16 there was also discussion of having different backend per domain. 18:59:36 If it has to be quick, then the format is going to be pretty homogenized 18:59:37 so maybe need json for domains. 18:59:54 bknudson, yeah, that was brought up 19:00:03 I'm not sure I buy that, though 19:00:14 I think the Keystone Federation approach makes a lot more sense there. 19:00:39 We are at 15:00. 19:01:01 dolphm, we probably need to vacate the premises 19:01:06 ayoung: ah, thanks 19:01:08 Quick note; the company I work for (Ping Identity) is putting on their Cloud Identity Summit again this year, this time in Napa, CA. Details at http://www.cloudidentitysummit.com 19:01:11 switching to -dev! 19:01:18 #endmeeting