18:01:49 #startmeeting 18:01:49 Meeting started Tue May 1 18:01:49 2012 UTC. The chair is heckj. Information about MeetBot at http://wiki.debian.org/MeetBot. 18:01:50 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 18:02:11 moving slow today - gimme a sec to get the topics together 18:03:25 #topic Status and Progress 18:03:38 I've been going through blueprints, trying to identify who's working on what 18:04:07 I'll be starting the domains BP shortly 18:04:13 ayoung: haven't caught up with you yet. What's your general plans re: multiprocess-keystone-service 18:04:13 You can mark me down for tempurl one 18:04:17 #link https://blueprints.launchpad.net/keystone 18:04:24 /me on IPv6 and PKI via HTTPD 18:05:07 gyee: what milestone are you aiming at for implementation? From our chat yesterday, I'm thinking F2 or F3. 18:05:23 https://blueprints.launchpad.net/keystone/+spec/multiprocess-keystone-service 18:05:33 yes F2 if I work weekends 18:05:35 liemn: same question for you - what milestone are you aiming at for having an implementation 18:05:36 heckj, I have a working prototype of Keystone running in HTTPD 18:05:38 F3 is more realistic 18:05:42 Wrote up my notes here: 18:05:50 http://adam.younglogic.com/2012/04/keystone-httpd/ 18:06:13 the two things I'd like to get eyeballs on are the locations for the wsgi enabling files and the HTTPD config 18:06:23 gyee: milestone F3 set 18:06:38 thank you sir 18:07:10 ayoung: will look 18:07:17 #link http://adam.younglogic.com/2012/04/keystone-httpd/ 18:07:26 #action - please give feedback to ayoung re: http://adam.younglogic.com/2012/04/keystone-httpd/ 18:07:46 heckj, realted to that is the discussion of deconflicting the URLS for Openstack in general 18:07:50 related 18:07:58 ayoung: what's your thought around implementation time for the PKI work - and are you leading that up? 18:08:00 heckj: i think i'm down for rbac, unless termie sleepsonthefloor is already on it (bp is unassigned) 18:08:14 IE: do we want https://hostname/keystone or https://hostname/identity 18:08:16 dolphm: thanks - will assign. Thoughts on milestone? 18:08:25 heckj: f2 18:08:31 heckj, again, once I have HTTPD, PKI becomes a lot easier 18:08:38 (do we have a release schedule out yet? ..) 18:09:15 ooh we do! http://wiki.openstack.org/FolsomReleaseSchedule 18:10:35 ayoung: makes sense 18:10:50 ayoung: I'm going to mark PKI for F3 at this point 18:10:54 heckj, OK 18:11:01 ayoung: can move as needed 18:11:18 heckj, I think Liem's tempURL work depended on access key CRUD 18:11:18 I'll try to have it done before then, but that is a safe bet 18:11:30 do I get the green light for access key BP? 18:12:08 gyee: I thought we agreed to a yes at the summit, and that the idea was to rework the EC2 API CRUD pieces to be more generic and use that. 18:12:17 liemn: are you doing that work? gyee 18:12:18 ? 18:12:20 gotcha 18:12:33 there's no blueprint to that at this point... 18:12:38 heckj, yeah, I will do the tempurl 18:12:41 I'll pay Liem to do that work :) 18:13:22 heckj, so the access key stuff still remains an extenstion? 18:13:27 liemn: is https://blueprints.launchpad.net/keystone/+spec/access-key-authentication what you're doing then? 18:13:55 yes 18:14:28 liemmn: I'm drafting an v3 API now to drag these things into core - I'm expecting to have it up for comments by 18:14:35 F1 18:14:56 I don't think F1, probably F2 18:15:04 gyee: would you create a blueprint to cover working EC2 to be generic to support general key access? 18:15:23 liemmn: I put you in F3 for now, can totally move in up if you'd prefer 18:15:39 heckj, will do 18:15:41 heckj: i assume you're covering all the BP's that will depend on a revised api? 18:16:00 #action: gyee to create BP to cover making access key storage EC2 more generic 18:16:35 liemmn, how does that interact with PKI Blueprint? 18:16:35 dolphm: trying, but I'm sure I'll miss something in the first cut - or several. AIming to get that up ASAP so we can move on the impl work form there 18:17:11 heckj: no worries 18:18:00 gyee, heckj I think we should ensure that PKI and Key access solutions are complementation 18:18:04 complementary 18:18:12 ayoung, access is different from PKI 18:18:26 gyee, yes and no. 18:18:29 access key auth is just like password auth, while PKI requires handshake 18:18:45 Understood 18:19:28 gyee, you and I understand the distinctions, but most people will not 18:19:50 additionally, there are overlapping concerns regarding key management etc 18:19:58 key generation... 18:19:59 good luck with that :) 18:20:22 gyee, well, I do have a little bit of experience in dealing with it... 18:20:45 heckj, I think we need an action Item something along the lines of "map out the whole PKI approach" 18:20:51 I am putting in the requirement for OCSP, just for you 18:20:52 something that connects the dots 18:21:08 gyee, stapling or server call? 18:21:08 ayoung: definitely 18:21:46 real time 18:21:53 ayoung: would you create a blueprint to lay out the PKI approach? Document, etc 18:22:13 ayoung: we can do that like the V3 api - document & feedback in F1, impl in F2/F3 18:22:27 #action: ayoung to create blueprint to document PKI approach for feedback 18:22:27 heckj, will do, if gyee promises to help 18:22:36 sure 18:22:38 #action: gyee to help ayound with it 18:22:40 :-) 18:23:27 ayoung, I can help review too... I did the 2-way auth a while back for keystone diablo... 18:23:58 liemmn, thanks. I was planning on asking for your help, too. 18:25:48 Okay - any other work for Keystone that we don't have tracked as yet? 18:26:15 liemmn: are you set up as an openstack contributor? signed CLA and all that rot? 18:26:22 heckj, yes 18:26:43 FYI... separate topic... I filed a validation bug: https://bugs.launchpad.net/keystone/+bug/992214 18:26:45 Launchpad bug 992214 in keystone "GET /tenants XSD schema validation fails" [Undecided,New] 18:27:16 we need to decide what the source of truth is... XSD or code :) 18:28:14 liemmn: at the moment, it's code. Although we need to have integrated tests that verify the code against the API description (WADL, XSD, etc) 18:28:36 the only way we can guarantee interop is with tests 18:29:17 Tempest is still getting traction, so for now I'm in favor of getting integration tests like these into Keystone's testing framework - once they're in, we'll automatically gate on them with code updates. 18:29:26 liemmn: is that something you're interested in doing? 18:29:36 It seems to me that the XSD should be generated from the code 18:29:46 +1 18:30:02 liemmn: xsd:id should definitely be a string 18:30:11 ayoung: ideally - but in practice it turns out ot be a PITA. If you guys want to take that on as a prototype to try it out, I'm all game. 18:30:36 ayoung: additionally, some parts of the xsd are optional and keystone does not (and probably will never) implement them 18:30:50 dolphm, then why carry them? 18:30:58 ayoung: we're not the only implementation on the block 18:31:09 just the only public one 18:31:30 s/public/public and free/g 18:31:34 :) 18:31:37 you RAX folks holding out on us? 18:32:00 gyee: fair 'nough 18:32:00 IMO... it should be the other way around... start out with XSD and then generate code... That way, you don't let language specifics "leak" into the XSD... 18:32:09 liemmn, +1 18:32:20 if, in fact, the XSD is the public contract 18:32:26 and it sounds like it is. 18:32:34 liemmn: I disagree - the resulting code is horrific to maintain, and what we just crawled out from underneath 18:32:55 I totally agree that need to match, and I think the way to verify that is with tests. 18:33:19 An API without a concrete implementation that you can verify against is worse than useless 18:33:36 yeah, in reality, code generation tools vary from language bindings to language bindings... 18:33:52 Personally, I don't care about the XSD outside of providing a means to document the api.openstack.org site. To me, that's the primary value. 18:34:01 heckj, I think both are important... tests and XSD serving as contracts for other implementers. 18:34:04 heckj: +1 18:34:39 liemmn: I agree that it's an important contract, but that wasn't the earlier assertion. Hence my suggestion of tests to verify. 18:34:53 * gyee memo to self: write a lot of tests 18:34:54 heckj: +1 18:34:59 i know rax adopted keystone's old integration tests at some point, worked well for them -- not sure what they're doing post-redux 18:35:16 o\ 18:35:25 joesavak! 18:35:29 we are using python keystone client in some of the integration tests against rax impl. 18:35:36 joesavak: awesome 18:35:39 we aren't using the keystone tests though against rax impl 18:36:06 joesavak: totally your choice in maintaining a separate implementation. 18:36:13 yuppers 18:36:40 also - while i'm not in a meeting - 18:36:45 joesavak: unrelated to XSD contracts and such, there's a pile of BPs on the list with your name. What's the plan with implementing those? Who's working on those elements, and when are they aiming to have it implemented? 18:37:08 Most likely, it'll be dolph working on those 18:37:17 2 highest priorities for RAX is RBAC and MFA 18:37:19 joesavak: not all of em! 18:37:32 joesavak: I've got dolphm on RBAC 18:37:49 joesavak: nothing on multifactor - who's doing that work? 18:38:22 we'll add the extension contract for MFA - but probably not do the keystone impl.. need help on that 18:38:26 heckj: does multifactor need to land beyond supporting spec changes? 18:38:41 joesavak: * 18:39:14 from my perpsecitve, i'm ok with mfa being an OS-KS* extension that I can implement within RAX. 18:39:23 dolphm: I don't want to claim support in the API for anything that isn't in code. How complex it is, I don't care - but we need something to verify interop. 18:39:45 joesavak, what two factors do you consider most important? 18:39:59 sms & email 18:40:14 outside of password/api-key auth support (first level auth) 18:40:40 hi ayoung, dolphm, heckj, liemn, and gyee, by the way. ; ) 18:40:45 joesavak, dolph: if you want it to just be a private RS extension, there's no trouble with that - it just won't be part of the official KS release. I thought the intention from the summit was to have a simple multifactor implementation in the public Keystone though. 18:41:13 I was going to refactor the keystone auth as part of access key impl 18:41:26 make it a plugin style 18:41:34 cool 18:41:39 but if RAX wants to do it, you can have it :) 18:41:53 gyee, be our guest. ;0 18:41:56 ;) 18:42:01 gyee: it already is "plugin style" - could you be more specific with your plans? 18:42:17 not really, I mean PAM style 18:42:21 like JAAS 18:42:21 gyee: plugin to the identity plugin? 18:42:50 that way, you can add you own auth module based on auth type 18:42:58 gyee: you want to add another plugin layer for identity instead of simply writing an alternate backend driver for it? 18:43:41 well, I want to be able to load different plugins based on auth type 18:43:52 i.e. passwordCredential -> password auth module 18:43:55 gyee: if you want to make a configurable backend, have at, but be aware the canonical API is at the keystone.identity.core.Driver class 18:44:29 gyee: okay by me 18:44:38 I haven't dive into that part of the code that much, was just a brain fart 18:44:49 I think we should keep it simple, and configurable whenever needed... I can discuss it with gyee... 18:44:58 gyee: no worries - dig in and holler w/ questions onto IRC or the list 18:45:06 will do 18:45:38 I think that the issue is we currently equate authentication with issuing a token. We could easily split that 18:45:39 in legacy, we talked about supporting a configurable list of auth methods, sorted by priority in the configuration -- the idea being each plugin would be passed the incoming auth blindly, and they could either return False or a successful auth (stopping on the first success) 18:45:50 joesavak: what's your plan re: multifactor at this point? Or is that getting assigned to gyee? 18:45:55 then authenticate is authenticate. requesting a token requires authentication 18:46:29 gyee - will your plans support a half-token (indicating further auth to get a full token)? 18:47:06 I can add a generic table to store the state information 18:47:14 just a string, you can call it a half token 18:47:26 I mean the plugins can make use of it 18:47:34 ok - we may be a rax extension on top of that to get us to what we need 18:47:56 so mfa --> gyee. Additional bp will be created if that impl needs rax extension to get rax to work 18:48:10 gyee: do you agree? 18:48:30 I am not doing mfa, just the refactoring of the auth part 18:48:45 not the full monty, just half :) 18:48:55 joesavak: you're the one with it assigned. I'll leave it off the milestones for now - get back to me later? 18:48:58 ok - target mfa to me for now. gyee - are you targetting folsom 2/3? 18:49:14 yup - i'll try to build off of what gyee does around folsom4 18:49:25 joesavak, f2 perhaps 18:49:31 cool, thanks 18:50:04 updated 18:50:12 Also - we've cleaned some of the contract out in https://github.com/carlosmarin/identity-api and are discussing here if it looks good to push back into gerrit. Take a look - if you see anything odd let me know. I know that even cleaning a contract could cause uproar. 18:50:35 #action - feedback needed on https://github.com/carlosmarin/identity-api 18:51:18 We have something like 8-9 minutes left 18:51:21 joesavak: tell him to push it -- feedback happens in gerrit :) 18:51:23 #topic open questions/issues 18:52:23 do people prefer https://hostname/keystone or https://hostname/identity for the unified URL scheme? Informal poll. 18:52:26 dolphm - i will by end of day 18:52:33 https://review.openstack.org/#/c/6425/ still needs approval 18:52:44 https://hostname/identity 18:52:48 ayoung: slight pref to 'identity', but I don't honestly care that mch 18:53:00 /identity 18:53:12 I'm aslo thinking about starting a draft for https://bugs.launchpad.net/keystone/+bug/963098 18:53:13 Launchpad bug 963098 in keystone "Keystone isn't acting on consecutive failed logins" [High,Triaged] 18:53:18 any suggestion would be appreciated 18:53:28 ayoung, my magic 8 ball says identity 18:53:29 rafaduran: a bp you mean? 18:53:41 that's a pretty strong informal consensus lol 18:53:55 dolphm, I think that is the way that things are going to fo 18:53:56 go 18:54:30 dolphm: I mean gerrit review 18:54:48 dolphm: review draft 18:57:01 rafaduran: https://review.openstack.org/#/c/6425/ approved 18:57:21 Wrappin' this up for today - back next week, same bat channel, same bat time 18:57:29 heckj: ok, thanks 18:57:34 #endmeeting 18:57:56 #endmeeting 18:58:03 hrm 18:58:04 where's the damn logs? 18:58:05 clarkb: ^^ 18:58:07 grrrr 18:58:18 heckj: we'll find em for ya 18:58:34 *sob* *sob* OK *sob* 18:58:41 (thank you) 18:58:44 * mtaylor pats heckj on the back 18:58:51 hmm, I don't think I touched the endmeeting code ... /me looks 18:59:02 it worked earlier today 18:59:15 bot being difficult, ah yeah. 18:59:44 darned robots 19:00:08 mtaylor: did meetingLocalConfig.py change? that is managed by puppet 19:00:12 not seeing anything in http://eavesdrop.openstack.org/meetings/openstack-meeting/2012/ beyond Apr 27th... 19:01:24 CI meeting, no? 19:01:34 mtaylor: Error: Can't start another meeting, one is in progress. 19:01:47 Predictable :) 19:01:50 oooh - now we're screwed 19:01:53 clarkb: I didn't 19:02:06 so, #endmeeting has just stopped working altogether. neat 19:02:17 what happens if you try and set status? Does it start a new meeting? 19:02:22 kill -HUP `pidof meetbot` 19:02:45 #end-meeting \ 19:02:48 #end-meeting 19:02:52 sudo #endmeeting 19:02:55 hehe 19:03:00 Oh. 19:03:03 sudo \#endmeeting 19:03:08 Hm. 19:03:11 I give up. 19:03:14 That's all I had. 19:03:27 when sudo commands fail soren, I believe the world is ending 19:03:38 soren is not in the sudoers file. This incident will be reported. 19:03:41 mtaylor: I've made arrangements. It's ok. 19:04:01 mtaylor: want me to restart the bot? 19:04:06 I just saw a rocket leaving earth... 19:04:25 LinuxJedi: made a change ~5 hours ago to update the mimetype 19:04:29 heckj: I've seen that movie. It turns out to be seafaring ships instead. 19:04:39 19:04:41 clarkb: that was to nginx 19:04:41 could that have borked it? 19:04:44 ah 19:05:03 #ENDMEETING 19:05:20 endmeeting, please. 19:05:21 * LinuxJedi sshing into it now 19:05:35 here come the big guns... 19:05:39 see, this is better than a ci meeting ... 19:06:00 crap, it can't write the log file 19:06:10 perms? 19:06:16 yep 19:06:25 don't know why this is hitting us now though 19:06:39 can you grant dir perms for now and have heckj try #endmeeting again? 19:06:57 willing 19:07:11 didn't we add control of that dir recently to puppet? 19:07:25 If only there was a way to find out. 19:07:40 * mtaylor stabs soren with a salmon 19:07:46 Like, some kind of system to track changes to code. 19:08:00 don't waste good fish! 19:08:01 * LinuxJedi wonders why it is all owned by mordred all of a sudden 19:08:24 hrm. 19:08:28 * mtaylor also wonders that 19:08:44 #endmeeting