17:59:08 #startmeeting Keystone Team Meeting 17:59:09 Meeting started Tue Oct 25 17:59:08 2011 UTC. The chair is joesavak. Information about MeetBot at http://wiki.debian.org/MeetBot. 17:59:10 Useful Commands: #action #agreed #help #info #idea #link #topic. 17:59:25 #topic Roadmap for Essex - status on blueprints 17:59:41 Agenda is located at http://wiki.openstack.org/Meetings/KeystoneMeeting 17:59:48 welcome y'all. Who is here? 18:00:01 me :-) 18:00:20 hi joseph! 18:00:29 ola! 18:00:36 i'll give it a couple more mins 18:00:43 np 18:00:43 here 18:01:01 hi jesse 18:01:35 ok - blueprints. Joseph - i saw you contributed a lot of doc for https://blueprints.launchpad.net/keystone/+spec/keystone-documentation 18:01:46 And another pull request to finish that out: https://review.openstack.org/#change,1089 18:02:19 I was hoping for feedback from the keystone team, never got anything other than "merge it", so I'm assuming I'm not lying anywhere. Wasn't 100% sure though :-) 18:02:28 ok - i'll review that but will need a 2nd. Jesse, can you review too? 18:02:49 Joseph - i'll take a look. The keystone team (dolph & yogi) have been pretty busy recently. 18:03:07 the original was what needed reviewing - and I have some questions I wanted to ask when appropriate - things that didn't make much sense while I was trying to document the work 18:03:48 ok. Feel free to send those questions to the mailing list 18:04:05 Ok - will do 18:04:08 joesavak: not to beat a dead horse but I am really confused about how to review doc changes 18:04:30 if this is going to run against diablo components (eg, e0 is for diablo+) or is this for essex? 18:04:44 what is it documenting, what is the protocol, ... 18:05:08 joseph, you were doing this for diablo, right? 18:05:09 I was writing those to catch it up - I'm presuming we're documenting whatever is in trunk, since the (developer) docs get branched with the code. 18:05:23 ya - the merges are against master 18:05:30 master is currently 45 commits different than stable/diablo 18:05:43 I honestly don't know if it's entirely accurate for trunk - hence the desire for someone who intimately knows Keystone to give a looksee. 18:05:50 is master supposed to become e0 and e0 becomes what we recommend instead of stable/diablo? 18:06:18 zns: maybe you know: is master supposed to become e0 and e0 becomes what we recommend instead of stable/diablo? 18:06:28 e0 will probably not exist due to timeframes. In talking with Yogi, I think we're shooting for e1 18:07:03 for people wanting to run diablo do will we recommend stable/diablo even once e1 exists then? 18:07:38 If master has only bug fixes and is stable by e0 then we should propose it as a backport for Diablo. My understanding is that it does not contain new functionality. Same API. Same schema. Thoughts? 18:07:41 https://github.com/openstack/keystone/compare/stable%2Fdiablo...master <- we are at +2743 -1372 lines already -- many docs :) but ... 18:07:49 probably. It depends if the customer was affected by a bug that'll be fixed in e-1 18:07:55 we have already changed schema 18:08:01 in master 18:09:47 is the removing of the default tenant id the only schema change? (https://review.openstack.org/#change,1068) 18:10:33 there is a table rename as well 18:10:41 if so, then maybe this is more suited for essex and not a diablo back-port 18:10:53 zns: so your goal is that all of 18:11:05 https://github.com/openstack/keystone/compare/stable%2Fdiablo...master + whatever else happens up to e0 or e1 becomes the new stable/diablo? 18:12:16 #topic Essex e-0 release possibility 18:12:26 I just need to know what the plans / goals are for diablo - as our team hasn't been able to switch to helping with essex due to working on keystone integration still 18:13:13 there are 2 paths that I see: 1 - leave stable diablo as it is and focus on e1 release that will not backport to diablo 18:13:39 perhaps it is more: 18:13:42 2 - rush to get e-0 done quickly which is the bugs & doc for diablo then back-port it to stable-diablo, then focus on e1 18:14:02 1) have a stable/diablo that has cherrypicked backports to fix specific issues - rather than just taking master 18:14:52 Jesse - what is your preference and why? 18:15:34 unfortunately we are kinda damned either way - since cherrypicking backports from master to stable/diablo is hard due to commits not being atomic - we 18:15:58 've spent time trying to identify them but end up having to rewrite since the commits aren't logically separated 18:16:11 and we don't have tags on bugs / commits to say it should be backported 18:16:17 yup 18:16:29 ignoring implementation - thinking only of the api (contracts) in stable/diablo 18:16:48 do we know what the issues that would need to be addressed for your team to feel happy doing a release? 18:16:58 stable/diablo release that is 18:17:29 ignoring impl, i think it's good. The doc updates just need to be verified and merged 18:17:52 but then people will try to get it to work and see that the impl is missing for calls or broken on others 18:18:08 zns: or why do you feel that we should switch to e0 / e1? 18:19:03 I know jaypipes et al are still working on integration with keystone as it exists now - but he can speak more to that 18:19:26 I just think we need to have a target that lets us finish diablo - and I can't find a document / bug list / blueprint / … that says what that is 18:19:43 ok. I'll get jay's opinion too. I'm leaning to just e-1 with no backporting though 18:20:13 something like https://bugs.launchpad.net/nova/+bugs?field.tag=diablo-backport 18:20:53 ok - i'll create a bug so there's more visibility 18:20:59 good catch 18:21:39 somewhat related, I'd really like to see the keystone team at least doing peer reviews - I'm still seeing checkins from someone being self-approved 18:21:49 anything else on e-0? Right now: no e-0 and i'll talk to Jay Pipes 18:21:57 joseph - i agree. I'll bring that up 18:22:30 pushing through commits in a day by the author minimizes the chance of peer review 18:22:58 yup. I think these are symptomatic of the keystone growing pains. 18:23:16 back to blueprints - 18:23:19 #topic Roadmap for Essex - status on blueprints 18:23:37 there is an RBAC blueprint we are drafting and are planning to do an RBAC prototype for e-1 18:23:59 that blueprint is here: https://blueprints.launchpad.net/keystone/+spec/rbac-keystone 18:24:24 and the full specification has proposed API changes. RBAC will be developed as a Keystone Extension 18:25:06 Any feedback on this will be helpful. I'll schedule a time for a review as well probably for the next meeting. 18:25:54 I'll make sure to pass it around the folks working on dash here in Seattle 18:26:03 HP is working on 2-way SSL (https://blueprints.launchpad.net/keystone/+spec/2-way-ssl) and keystone domains right now (https://blueprints.launchpad.net/keystone/+spec/keystone-domains) 18:26:06 joseph - thanks! 18:26:12 joesavak: can we get an estimated on when the decision on what is the plan for keystone in diablo? after talking with jay/... 18:26:37 I need to set expectations for our team and people who are deploying diablo 18:27:10 seems like it is really a ptl question but zns doesn't appear to be here 18:27:18 anotherjesse: let me talk it over with zns. My thoughts is that e-1 with no backporting will be decided 18:27:29 so by COB tomorrow? 18:28:07 #topic Open bugs 18:28:17 k - i have questions about the rbac but don't really have time to think about it until diablo is done 18:28:29 Yogi has been working on bug fixes against trunk. He's focusing on the high and critical ones 18:28:44 Jesse - we will start work on the prototype next week - FYI 18:29:08 I'm working on the doc bug - and I think I've identified more, but wasn't sure - will be asking questions about the functionality on the mailing list 18:29:17 joesavak: does high and critical mean by the importance in launchpad? 18:29:19 joseph: thanks 18:29:23 jesse: yes 18:30:04 if there are any bugs you feel should be addressed soon, let me know. 18:30:25 joesavak: there are lots of bugs with "undecided" importance with "fix commited" - seems like a weird state for so many bugs to be in 18:30:45 yeah. Triage has been an issue and we're working on that too. 18:31:13 Many of them are old or may have been fixed already. Yogi is going through as he's fixing to update the bugs where appropriate 18:31:55 If you own any of these bugs and see that the importance is missing or not what you'd expect - let me know that too. 18:32:24 #topic Open Discussion 18:32:41 Ok - what questions do y'all have? 18:32:45 I really feel like we have lots of technical debt we need to fix - things like processes and bugs and docs 18:32:51 before spending too much time on new stuff 18:32:59 feels like adding on top of a shaky foundation 18:33:29 jesse: i agree. It's difficult for keystone since it is really part of essex core (not diablo), was forced to grow up quick, and has really only 2 contributing devs on it. 18:34:13 joesavak: any chance you can have your developers slow down, take a deep breath and approach things with a slow and steady wins the race attitude? 18:34:22 not trying to push e0 / e1 out with lots of additions 18:35:05 jesse: yes - and we're potentially looking at resources as well. The issue is that keystone needs to freeze early on in essex with RBAC for services to start coding against that functionality 18:36:16 if we coordinated the tasks and made them a bit more available for other developers to add in, we might be able to get some external resources contributing here too 18:36:34 We don't need to have the "only 2 devs, so push everything through as fast as possible" 18:36:51 joseph - i agree. Thanks for that. :) 18:36:58 But structure is needed to enable other developers to help 18:37:25 joseph: ok - i think we're already on the right path - more blueprints & bug management for essex than diablo 18:37:37 The conversations appear to be happening between some of the devs and HP, but I haven't seen anything on the lists, open conversations, or even announcements of meetings yet. We really need to get that straightened out. 18:38:03 I'm helping with docs now, and I've found it very difficult because of lack of access - and honestly I've been hesitant to just slap this into the mailing list. Maybe my bad 18:38:41 joesavak: I don't want to say "essex only" - just more structure is needed in coordinating community involvement. Right now it appears to be all inward facing 18:38:46 j - yea, we have been talking with Liem and Jason especially around domains 18:39:22 can we shift that conversation to the mailing list? Or set up a time to talk about design ideas and considerations on IRC? SOmething to make it more available/accessible 18:39:59 j - yes. I'll setup some time and we can do a sprint planning together. That may help 18:40:26 ok - any other questions or issues? 18:40:51 #topic action-items 18:41:23 Joe Savak to schedule a meeting with HP contributors and RS contributors for keystone to flush out design more, task, and estimate work 18:41:46 Joe Savak to check with Ziad on the E-0 possibility and communicate it out 18:41:52 How about changing that to scheduling a "public" meeting 18:42:08 heckj: ++ 18:42:11 j- ok, public. We might do it on our next ks status meeting 18:42:19 awesome 18:42:38 Joe Savak to request peer reviews of RS developers 18:42:48 did i miss anything? 18:43:10 Joe Savak to have a beer? 18:43:40 ok - thanks y'all. 18:43:46 thx 18:43:56 #endmeeting