18:02:45 #startmeeting Keystone Team Meeting 18:02:46 Meeting started Tue Jan 31 18:02:45 2012 UTC. The chair is zns. Information about MeetBot at http://wiki.debian.org/MeetBot. 18:02:47 Useful Commands: #action #agreed #help #info #idea #link #topic. 18:02:57 Hi - anyone here for the Keystone meeting? 18:03:02 o/ 18:03:02 \0 18:03:07 \o 18:03:13 gyee: is a cyclops 18:03:27 Cool! Hi. 18:03:30 \o/ 18:03:32 #topic status update 18:03:57 Has everyone seen & read the ksl announcement? 18:04:10 zns: I am pretty deep into the keystone domains blueprint 18:04:12 The branch is now available in the repo. It's called "redux" 18:04:38 gyee: cool. Have you had a chance to post any part of it? Or the contracts? 18:05:07 I sent out the wadl and xsd, not sure if you guys have a chance to review it yet 18:05:24 zns, what is the timeline for changing over to Keystone? 18:05:26 Light 18:05:26 gyee: by email or in a review? 18:05:35 zns, by email 18:05:50 ayoung: E4 if we can get the gaps filled. 18:05:59 gyee: I'll go back and review... 18:06:05 what does KSL mean for blueprints that are currently in-flight? 18:06:58 will the existing branch be deprecated at some point? when? 18:07:26 * mtaylor thinks that in-flight blueprints should probably be developed on top of the redux branch at this point, no? 18:07:40 gyee: E3 was the cut-off fir any new features. So, ostensibly, there are no new features in flight. Until KSL gets merged in, the current master branch is the supported branch. Blueprints and bugs against that should continue ahead. 18:07:52 * mtaylor takes back what he said 18:07:56 :) 18:08:01 what about the F branch? 18:08:15 so F is the master or a separate one? 18:08:26 F will be the master once E is cut 18:08:40 scuse me 18:08:44 master will be F once E is cut 18:08:57 I'm guessing that we will want a branch off of redux for Fremont/Folsom/Francisco 18:08:58 so I can't checkin new features till E5's done" 18:08:59 ? 18:09:29 mtaylor: I don't disagree with what you said, but KSL is not ready yet. So testing might be a challenge. BUt I do agree that new work shoud focus on KSL. 18:09:29 we decided on Folsom already right? 18:09:41 yes. we did decide on folsom 18:09:43 gyee: correct. 18:09:45 apologies for being late - in a meeting :( 18:10:14 the where-does-new-features work go with our "make things stable" model at the moment is a bit of an unanswered/unaddressed issue 18:10:31 mtaylor: do we have a folsom branch already in the repo? If not, we probably should base that on redux. 18:11:07 so Folsom = redux? 18:11:10 mtaylor: yes. It's a gap. I think that's what's confusing for gyee. He's coding against master. 18:11:10 no, we don't - we don't really have a model for opening a folsom before essex is released... I think I should circle up with ttx 18:11:22 zns: indeed. I think it's a gap we need to solve :) 18:11:33 I am really confused now 18:11:41 termie, anotherjessie: any thoughts on hwta Gyee should do? Code against master and port to KSL or code to KSL 18:11:52 what's the emoticon for confused? (_?_) 18:11:55 We are going to have to decide :push path to redux and then merge to Folsom or the reverse. 18:12:01 patch 18:12:58 There are two challenges for gyee. One, he's building a new feature; so that should go in Ffolsom since we're feature frozen. Two, which branch should he be coding against given KSL is not baked yet. 18:13:33 ayoung, gyee: any preferences for which? My preference is to continue on master until KSL is ready. 18:13:43 then do the porting? 18:14:01 zns, I think I am going to focus on getting KSL feature compatible with curent master regardless. 18:14:02 I want to have some idea what the scope is 18:14:32 I'd say that we push changes to redux, and then merge them over to Folsom 18:14:35 I can continue on master, but there will be porting effort right? 18:14:42 master to KSL 18:15:16 ayoung: for new efforts, maybe that;s a good path. But gyee has already started on master, so maybe finish that and then we work on the porting? 18:15:31 zns: my view is that we want to replace master with KSL asap 18:15:46 gyee: correct. There will be work to port. But that applies to many of the features in master now that don't exist in redux (ksl) 18:16:06 zns, I suspect that gyee will have a lot of work to do to make his changes work weith KSL, 18:16:08 with 18:16:14 is the KSL code available now? I can go read the code and figure out the porting effort 18:16:17 our team is 100% focused on KSL in essex 18:16:32 gyee: https://github.com/termie/keystonelight 18:16:42 anotherjessie: you're saying cut over before compatibility is reached? What about existing deployments? 18:16:43 anotherjesse, thanks 18:16:46 gyee: https://github.com/openstack/keystone/tree/redux 18:16:48 anotherjesse, it is in the redux branch, too 18:17:22 zns: compatibility is within days of being finished - the missing list is: XML, pagination, token delete 18:17:44 anotherjesse, do we care about parity for keystone-manage? 18:18:04 so token delete will be officially supported? 18:18:13 gyee: it is an extension I think 18:18:13 that's the other issue I want to bring up 18:18:26 ayoung: the goal of other projects is to minimize the *-manage commands 18:18:31 also, does that include the LDAP backend? 18:18:33 DELETE /v2.0/RAX/token/tokenId? 18:18:52 anotherjessie: what about LDAP, errors returned, URL normalization? 18:19:02 zns: url normalization? 18:19:16 anotherjessie: should we put all the gaps in blueprints/bugs? Maybe prefix the name with redux: ? 18:19:29 zns: yep - that is in progerss 18:19:32 .xml returns XML. .json reutnrs JSON. 18:20:58 OK. SOunds like we've got good momentum then for a switch to KSL soon? How do we validate that? What's the fallback for someone having problems? Use E3? 18:21:00 for LDAP the reason we haven't ported the existing LDAP code (that we originally wrote for nova) 18:21:29 is that KSL has the approach that tokens, users, tenants, members, roles each have their own backing system 18:21:40 since you might want to use users from company's LDAP for SSO 18:21:48 well- the redux branch is tied in to gerrit now, so it will run all of the same tests that run against current keystone (or else new patches won't land) ... 18:21:54 but you don't have write access for role/membership management 18:22:04 o/ (sorry for being late) 18:22:24 just to clarify, new features WILL go into redux correct? 18:22:35 so hopefully that should help with some of the validation 18:22:59 anotherjesse, then what is the right approach for LDAP in the new arch? 18:23:01 heckj: your team is focused on KSL right? 18:23:09 yep 18:23:31 gyee: new features will go into redux in the folsom timeframe. 18:23:49 anotherjesse: lately updating the docs in ksl and cleaning work on python-keystoneclient 18:23:53 zns: and that is because we are at feature freeze - regardless of ksl vs keystone? 18:24:04 anotherjesse: correct. 18:24:34 zns: when can I start checking in domains code? 18:25:00 gyee: the only way we should get new features in for Essex is if they are totally optional extensions (no schema changes, etc). 18:26:15 domains feature is an extension, though we are extending users, tenants, roles, and services 18:26:49 gyee: any time you are ready. As long as it is optional we can include it. But given we are in a feature freeze, we can't accept shcema or API changes. 18:27:11 gyee: does it come with schema changes? 18:27:23 gyee: you are referring to https://blueprints.launchpad.net/keystone/+spec/keystone-domains - correct? 18:27:32 yes 18:27:44 new domains APIs 18:28:03 under /v2.0/HP-IDM/v1.0/domains 18:29:10 anotherjessie, termie: would it be easier to implement domains in KSL in a way that would not alter the schema? That might be a path forward for gyee (and a way to leverage the architecture of KSL). 18:29:25 zns: reading it now 18:29:35 gyee: are you around after the meeting to chat about it 18:29:47 sure 18:29:53 I can starting using KSL if you want 18:30:08 ya know, clear the land mines for your guys :) 18:30:15 gyee: the major blocker would be XML support 18:30:18 gyee, how much code do you have in the domains effort thus far? 18:30:19 which we plan to land this week 18:30:36 ayoung, quite a bit 18:30:42 ~20 files 18:30:43 gyee, anotherjesse: I'm trying to grok what its providing, not geting it from the blueprint description 18:31:52 gyee: my precursory read of the domain blueprint makes me wonder if it is accomplished with RBAC - having roles that allow "admin" api commands 18:32:11 * heckj was wondering the same thing 18:32:13 heckj: think of it as allowing multiple Admins, each managing their own slice of the Keystone pie without having access to each other's data. 18:32:30 essentially domains are new containers for users, tenants, roles, and services 18:33:10 a grouping around tenants - adding another level up to which we can apply policies, or is it one of those infinitely nested things? 18:33:33 just one level, we don't support nested domains right now 18:33:41 heckj: one level, no nesting. 18:34:13 that sure sounds like it needs schema changes in the basic (a SQL) setup 18:34:15 just a way to segregate resources for easier management 18:34:33 gyee: do services like nova/glance get the domain from the token validation? 18:34:39 You'd be able to apply that nicely in KSL using the policy engine setup and base components that are already in there 18:35:11 domain ID will be returned if hpdom extension is enabled 18:35:13 or is the domain even exposed to the services? 18:35:33 you can lookup services for a given domain 18:36:10 gyee, Is there any reason to call it a Domain as opposed to Nested Tenants? 18:36:15 if hpdom extension is disabled, you can only operate on resources that is in the Keystone default system domain 18:36:17 gyee: I ask because if a user has an admin role in a domain - nova/glance would need to make it so admin-ness was scoped to only tenants within that domain 18:36:37 anotherjesse, that 18:36:39 s correct 18:36:51 domain admin can only manage resource in his own domain 18:37:10 but he can assign roles in his own domain to users from another domain 18:37:15 gyee: I'm concerned about adding it in the essex timeframe primarily due to changes required in other projects 18:37:35 since nova doesn't have those concepts yet 18:37:45 anotherjesse, it's extension 18:37:49 I like the idea a lot though - what are your thoughts 18:38:17 gyee: but an extension in keystone that doesn't work with other open projects, perhaps we should time it for F1 (april)? 18:38:18 fully backward compatible 18:38:20 Thats a pretty fundamental and far-reaching component - I think we might be better served by lining it up for a folsom-1 introduction rather than this late in the release cycle 18:38:34 er, yeah - what anotherjesse said... 18:39:10 I am fine with Folsom 18:39:23 just let me know when it is ready so I can push codes for review 18:39:26 gyee: it would be good for us to add to blueprint 18:39:28 so that would mean gyee should port it to a folsom branch of ksl? Are we opening that branch? 18:39:48 zns: I think that would make a great deal of sense 18:40:11 WHen would the right time for that be? Now, in a week, or on E4? 18:41:02 zns: proposing we open up the branch next week when KSL has reached compatibility. Seconds? 18:41:18 I think we could make the ksl branch available at any time - right now, but we wouldn't want it as default yet 18:41:34 heckj - it is https://github.com/openstack/keystone/tree/redux 18:41:57 eh, teach me to be late to the meeting 18:42:04 zns: the general project stance is that you don't open folsom until it is read 18:42:14 so as to prioritize community working on current branches 18:42:14 We'd be creating a new one off of that; folsom branch (based on redux). 18:42:44 so if you want to work ahead you would create a local branch against KSL and merge prop once open 18:42:54 this happens in nova as well (when a team is working ahead due to internal deadlines) 18:43:56 OK. SO gyee should work on a local branch of redux and wait for folsom to open up? 18:43:56 gyee, I'd just be aware that there are going to be many changes go in to redux between now and Folsom, so if you are going to work off a branch from redux, we will all want to make sure that it keeps up with all commits 18:44:20 so rebase early and rebase often 18:44:34 or pushing code often :) 18:44:41 #info New features should go in local branches and wait for folsom 18:45:03 #info based on the redux branch in keystone now 18:45:13 gyee, well, if you had somewhere to push to, I'd agree.... 18:45:20 #info redux branch should be ready for merge by next week 18:45:30 wait, so redux is NOT open for writing right now? 18:45:35 it is open for writing 18:45:40 you use git-review against redux 18:45:48 I have one last quick question... 18:45:48 goal is to be ready to merge into master asap 18:46:02 gyee, are you going to be pushing Domains changes into redux? I thought we just agreed it would wait until Folsom? 18:46:04 anotherjessie: should we prefix bugs and blueprints with "redux:" to separate them from master? 18:46:44 or any other thoughts on how to separate them? 18:46:58 zns: use tags? 18:47:08 tags works! 18:47:27 #info: tag bugs/blueprints with "redux" to identify the branch 18:47:36 Thanks everyone! 18:47:37 #endmeeting