18:02:45 <zns> #startmeeting Keystone Team Meeting
18:02:46 <openstack> 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 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic.
18:02:57 <zns> Hi - anyone here for the Keystone meeting?
18:03:02 <mtaylor> o/
18:03:02 <gyee> \0
18:03:07 <gyee> \o
18:03:13 <mtaylor> gyee: is a cyclops
18:03:27 <zns> Cool! Hi.
18:03:30 <ayoung> \o/
18:03:32 <zns> #topic status update
18:03:57 <zns> Has everyone seen & read the ksl announcement?
18:04:10 <gyee> zns: I am pretty deep into the keystone domains blueprint
18:04:12 <zns> The branch is now available in the repo. It's called "redux"
18:04:38 <zns> gyee: cool. Have you had a chance to post any part of it? Or the contracts?
18:05:07 <gyee> I sent out the wadl and xsd, not sure if you guys have a chance to review it yet
18:05:24 <ayoung> zns, what is the timeline for changing over to Keystone?
18:05:26 <ayoung> Light
18:05:26 <zns> gyee: by email or in a review?
18:05:35 <gyee> zns, by email
18:05:50 <zns> ayoung: E4 if we can get the gaps filled.
18:05:59 <zns> gyee: I'll go back and review...
18:06:05 <gyee> what does KSL mean for blueprints that are currently in-flight?
18:06:58 <gyee> 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 <zns> 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 <gyee> :)
18:08:01 <gyee> what about the F branch?
18:08:15 <gyee> so F is the master or a separate one?
18:08:26 <mtaylor> F will be the master once E is cut
18:08:40 <mtaylor> scuse me
18:08:44 <mtaylor> master will be F once E is cut
18:08:57 <ayoung> I'm guessing that we will want a branch off of redux for Fremont/Folsom/Francisco
18:08:58 <gyee> so I can't checkin new features till E5's done"
18:08:59 <gyee> ?
18:09:29 <zns> 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 <gyee> we decided on Folsom already right?
18:09:41 <mtaylor> yes. we did decide on folsom
18:09:43 <zns> gyee: correct.
18:09:45 <anotherjesse> apologies for being late - in a meeting :(
18:10:14 <mtaylor> 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 <zns> mtaylor: do we have a folsom branch already in the repo? If not, we probably should base that on redux.
18:11:07 <gyee> so Folsom = redux?
18:11:10 <zns> mtaylor: yes. It's a gap. I think that's what's confusing for gyee. He's coding against master.
18:11:10 <mtaylor> 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 <mtaylor> zns: indeed. I think it's a gap we need to solve :)
18:11:33 <gyee> I am really confused now
18:11:41 <zns> termie, anotherjessie: any thoughts on hwta Gyee should do? Code against master and port to KSL or code to KSL
18:11:52 <gyee> what's the emoticon for confused? (_?_)
18:11:55 <ayoung> We are going to have to decide :push path to redux and then merge to Folsom or the reverse.
18:12:01 <ayoung> patch
18:12:58 <zns> 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 <zns> ayoung, gyee: any preferences for which? My preference is to continue on master until KSL is ready.
18:13:43 <gyee> then do the porting?
18:14:01 <ayoung> zns, I think I am going to focus on getting KSL feature compatible with curent master regardless.
18:14:02 <gyee> I want to have some idea what the scope is
18:14:32 <ayoung> I'd say that we push changes to redux,  and then  merge them over to Folsom
18:14:35 <gyee> I can continue on master, but there will be porting effort right?
18:14:42 <gyee> master to KSL
18:15:16 <zns> 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 <anotherjesse> zns: my view is that we want to replace master with KSL asap
18:15:46 <zns> 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 <ayoung> zns, I suspect that gyee will have a lot of work to do to make his changes work weith KSL,
18:16:08 <ayoung> with
18:16:14 <gyee> is the KSL code available now? I can go read the code and figure out the porting effort
18:16:17 <anotherjesse> our team is 100% focused on KSL in essex
18:16:32 <anotherjesse> gyee: https://github.com/termie/keystonelight
18:16:42 <zns> anotherjessie: you're saying cut over before compatibility is reached? What about existing deployments?
18:16:43 <gyee> anotherjesse, thanks
18:16:46 <mtaylor> gyee: https://github.com/openstack/keystone/tree/redux
18:16:48 <ayoung> anotherjesse, it is in the redux branch, too
18:17:22 <anotherjesse> zns:  compatibility is within days of being finished - the missing list is: XML, pagination, token delete
18:17:44 <ayoung> anotherjesse, do we care about parity for keystone-manage?
18:18:04 <gyee> so token delete will be officially supported?
18:18:13 <anotherjesse> gyee: it is an extension I think
18:18:13 <gyee> that's the other issue I want to bring up
18:18:26 <anotherjesse> ayoung: the goal of other projects is to minimize the *-manage commands
18:18:31 <ayoung> also,  does that include the LDAP backend?
18:18:33 <gyee> DELETE /v2.0/RAX/token/tokenId?
18:18:52 <zns> anotherjessie: what about LDAP, errors returned, URL normalization?
18:19:02 <anotherjesse> zns: url normalization?
18:19:16 <zns> anotherjessie: should we put all the gaps in blueprints/bugs? Maybe prefix the name with redux: ?
18:19:29 <anotherjesse> zns: yep - that is in progerss
18:19:32 <zns> .xml returns XML. .json reutnrs JSON.
18:20:58 <zns> 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 <anotherjesse> for LDAP the reason we haven't ported the existing LDAP code (that we originally wrote for nova)
18:21:29 <anotherjesse> is that KSL has the approach that tokens, users, tenants, members, roles each have their own backing system
18:21:40 <anotherjesse> since you might want to use users from company's LDAP for SSO
18:21:48 <mtaylor> 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 <anotherjesse> but you don't have write access for role/membership management
18:22:04 <heckj> o/ (sorry for being late)
18:22:24 <gyee> just to clarify, new features WILL go into redux correct?
18:22:35 <mtaylor> so hopefully that should help with some of the validation
18:22:59 <ayoung> anotherjesse, then what is the right approach for LDAP in the new arch?
18:23:01 <anotherjesse> heckj: your team is focused on KSL right?
18:23:09 <heckj> yep
18:23:31 <zns> gyee: new features will go into redux in the folsom timeframe.
18:23:49 <heckj> anotherjesse: lately updating the docs in ksl and cleaning work on python-keystoneclient
18:23:53 <anotherjesse> zns: and that is because we are at feature freeze - regardless of ksl vs keystone?
18:24:04 <zns> anotherjesse: correct.
18:24:34 <gyee> zns: when can I start checking in domains code?
18:25:00 <zns> 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 <gyee> domains feature is an extension, though we are extending users, tenants, roles, and services
18:26:49 <zns> 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 <zns> gyee: does it come with schema changes?
18:27:23 <anotherjesse> gyee: you are referring to https://blueprints.launchpad.net/keystone/+spec/keystone-domains - correct?
18:27:32 <gyee> yes
18:27:44 <gyee> new domains APIs
18:28:03 <gyee> under /v2.0/HP-IDM/v1.0/domains
18:29:10 <zns> 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 <anotherjesse> zns: reading it now
18:29:35 <anotherjesse> gyee: are you around after the meeting to chat about it
18:29:47 <gyee> sure
18:29:53 <gyee> I can starting using KSL if you want
18:30:08 <gyee> ya know, clear the land mines for your guys :)
18:30:15 <anotherjesse> gyee: the major blocker would be XML support
18:30:18 <ayoung> gyee, how much code do you have in the domains effort thus far?
18:30:19 <anotherjesse> which we plan to land this week
18:30:36 <gyee> ayoung, quite a bit
18:30:42 <gyee> ~20 files
18:30:43 <heckj> gyee, anotherjesse: I'm trying to grok what its providing, not geting it from the blueprint description
18:31:52 <anotherjesse> 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 <zns> 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 <gyee> essentially domains are new containers for users, tenants, roles, and services
18:33:10 <heckj> 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 <gyee> just one level, we don't support nested domains right now
18:33:41 <zns> heckj: one level, no nesting.
18:34:13 <heckj> that sure sounds like it needs schema changes in the basic (a SQL) setup
18:34:15 <gyee> just a way to segregate resources for easier management
18:34:33 <anotherjesse> gyee: do services like nova/glance get the domain from the token validation?
18:34:39 <heckj> 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 <gyee> domain ID will be returned if hpdom extension is enabled
18:35:13 <heckj> or is the domain even exposed to the services?
18:35:33 <gyee> you can lookup services for a given domain
18:36:10 <ayoung> gyee, Is there any reason to call it a Domain as opposed to Nested Tenants?
18:36:15 <gyee> if hpdom extension is disabled, you can only operate on resources that is in the Keystone default system domain
18:36:17 <anotherjesse> 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 <gyee> anotherjesse, that
18:36:39 <gyee> s correct
18:36:51 <gyee> domain admin can only manage resource in his own domain
18:37:10 <gyee> but he can assign roles in his own domain to users from another domain
18:37:15 <anotherjesse> gyee: I'm concerned about adding it in the essex timeframe primarily due to changes required in other projects
18:37:35 <anotherjesse> since nova doesn't have those concepts yet
18:37:45 <gyee> anotherjesse, it's extension
18:37:49 <anotherjesse> I like the idea a lot though - what are your thoughts
18:38:17 <anotherjesse> 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 <gyee> fully backward compatible
18:38:20 <heckj> 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 <heckj> er, yeah - what anotherjesse said...
18:39:10 <gyee> I am fine with Folsom
18:39:23 <gyee> just let me know when it is ready so I can push codes for review
18:39:26 <anotherjesse> gyee: it would be good for us to add to blueprint
18:39:28 <zns> so that would mean gyee should port it to a folsom branch of ksl? Are we opening that branch?
18:39:48 <heckj> zns: I think that would make a great deal of sense
18:40:11 <zns> WHen would the right time for that be? Now, in a week, or on E4?
18:41:02 <zns> zns: proposing we open up the branch next week when KSL has reached compatibility. Seconds?
18:41:18 <heckj> 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 <anotherjesse> heckj - it is https://github.com/openstack/keystone/tree/redux
18:41:57 <heckj> eh, teach me to be late to the meeting
18:42:04 <anotherjesse> zns: the general project stance is that you don't open folsom until it is read
18:42:14 <anotherjesse> so as to prioritize community working on current branches
18:42:14 <zns> We'd be creating a new one off of that; folsom branch (based on redux).
18:42:44 <anotherjesse> so if you want to work ahead you would create a local branch against KSL and merge prop once open
18:42:54 <anotherjesse> this happens in nova as well (when a team is working ahead due to internal deadlines)
18:43:56 <zns> OK. SO gyee should work on a local branch of redux and wait for folsom to open up?
18:43:56 <ayoung> 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 <ayoung> so rebase early and rebase often
18:44:34 <gyee> or pushing code often :)
18:44:41 <zns> #info New features should go in local branches and wait for folsom
18:45:03 <heckj> #info based on the redux branch in keystone now
18:45:13 <ayoung> gyee, well,  if you had somewhere to push to,  I'd agree....
18:45:20 <zns> #info redux branch should be ready for merge by next week
18:45:30 <gyee> wait, so redux is NOT open for writing right now?
18:45:35 <anotherjesse> it is open for writing
18:45:40 <anotherjesse> you use git-review against redux
18:45:48 <zns> I have one last quick question...
18:45:48 <anotherjesse> goal is to be ready to merge into master asap
18:46:02 <ayoung> gyee, are you going to be pushing Domains changes into redux?  I thought we just agreed it would wait until Folsom?
18:46:04 <zns> anotherjessie: should we prefix bugs and blueprints with "redux:" to separate them from master?
18:46:44 <zns> or any other thoughts on how to separate them?
18:46:58 <anotherjesse> zns: use tags?
18:47:08 <zns> tags works!
18:47:27 <zns> #info: tag bugs/blueprints with "redux" to identify the branch
18:47:36 <zns> Thanks everyone!
18:47:37 <zns> #endmeeting