18:02:54 <dolphm> #startmeeting keystone 18:02:54 <openstack> Meeting started Tue Oct 8 18:02:54 2013 UTC and is due to finish in 60 minutes. The chair is dolphm. Information about MeetBot at http://wiki.debian.org/MeetBot. 18:02:55 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 18:02:57 <openstack> The meeting name has been set to 'keystone' 18:03:01 <dolphm> #topic Havana 18:03:14 <dolphm> so, i wanted to quickly announce that i suspect we'll have an RC2 18:03:16 <gyee> bknudson, you ever figure out why the tests are failing? 18:03:26 <gyee> for you oslo.db patch I mean 18:03:29 <ayoung> dolphm, do we have a page for RC2 yet? 18:03:31 <gyee> s/you/your/ 18:03:43 <dolphm> we have a low-impact security vulnerability introduced in havana that we should be able to fix fairly easily 18:03:45 <dolphm> ayoung: no 18:03:52 <bknudson> gyee: yes, it's on the meeting agenda 18:03:57 <bknudson> deleting a user at the same time as deleting a role 18:04:05 <dolphm> i'd also like to get the mysql/db2 issues resolved in havana 18:04:24 <gyee> so we are running the tests in parallel? I had the same concern with jamielennox patch too 18:04:27 <dolphm> i'm not currently aware of anything else that *needs* to land in rc2 18:04:41 <dolphm> #topic Havana release notes 18:04:43 <jamielennox> me? which patch? 18:04:53 <stevemar> gyee: is there anyway we can run those tests in parallel to see if it fails? 18:05:02 <bknudson> the tests are run in parallel, but obviously customers can do the same thing. 18:05:06 <dolphm> most of the release notes are filled in, except for the multi-ldap backend issue 18:05:07 <dolphm> https://wiki.openstack.org/wiki/ReleaseNotes/Havana 18:05:09 <dolphm> #link https://wiki.openstack.org/wiki/ReleaseNotes/Havana 18:05:10 <stevemar> jamielennox: gyee is referring to assertRequestHeader 18:05:30 <gyee> stevemar, jamielennox, yes that 1 18:06:06 <jamielennox> that should be ok, the tests are parallel but they are still sequential per-process so last_request() should always work 18:06:07 <bknudson> we've got the best release notes. 18:06:15 <bknudson> our PTL is really doing his job. 18:06:16 <dolphm> bknudson: so far! 18:06:29 <dolphm> i tried to start a bit early 18:06:39 <gyee> yeah, nice notes! 18:06:39 <ayoung> dolphm, our goal is to keep you doing it so none of us have to 18:06:42 <dolphm> since, you know, we were the first project to hit RC1 and all, we had extra time to spare 18:06:49 <dolphm> ayoung: ++ 18:07:24 <gyee> extra time is such a foreign concept 18:07:28 <dolphm> :) 18:07:30 <dolphm> #topic keystoneclient 18:07:35 <dolphm> on the topic of no extra time 18:07:49 <dolphm> 0.3.3 is sort of hung up on a few code reviews that aren't moving very fast 18:08:05 <dolphm> any one of those would probably warrant an immediate release 18:08:06 <ayoung> so...we've put shardy on the spot making him do a tempest test for a client change 18:08:10 <stevemar> i'm faily certain it's just jamielennox doing reviews :P 18:08:19 <dolphm> so if one merges and the others are still stalled, i'll be cutting a release anyway 18:08:26 <ayoung> the short of it is: we have no way to test client changes against a live server unless we use tempest. 18:08:45 <ayoung> so: new rule...all changes to keystone client that should be tested against a live server should have a tempest test 18:08:57 <ayoung> and...I'll try to get an example one out there shortly 18:09:07 <dolphm> that's not really relevant for https://review.openstack.org/#/c/35403/ 18:09:23 <gyee> ayoung, would it be a chicken-egg issue? 18:09:36 <gyee> I presume its a conditional approval 18:09:38 <dolphm> which i think has nearly sufficient unit tests 18:09:45 <ayoung> gyee, that is exactly the term I use to describe it, but we have an approach 18:10:04 <ayoung> in the start of the test, check to see if the client supports the feature,. if not, rais a Skip exception 18:10:12 <dolphm> ooh, i should also point out that the next release of keystoneclient will likely be 0.4.0, not 0.3.3 18:10:25 <bknudson> new features? 18:10:32 <dolphm> due to our new dependency on oslo.config 1.2 18:10:36 <jamielennox> dolphm: so regarding the TZ patch should we be looking to make some changes ourselves or wait for original authors? 18:11:08 <dolphm> jamielennox: i'm down for either -- there was a comment by brant that i wasn't comfortable addressing without at least feedback from the original author 18:11:58 <dolphm> #topic oslo.db 18:12:06 <dolphm> bknudson: all yours 18:12:22 <dolphm> there's a bunch of notes on the meeting agenda to get everyone on the same page- https://wiki.openstack.org/wiki/Meetings/KeystoneMeeting#Agenda_for_next_meeting 18:12:23 <ayoung> https://review.openstack.org/#/q/status:open+project:openstack/python-keystoneclient,n,z looks pretty well supported. THere are 6 reviews up there with nothing in the R column for me, and two of them are WIP. 18:12:25 <bknudson> ok, so I'm working on using oslo.db rather than our own 18:12:31 <bknudson> yes, read the notes. 18:12:37 <ayoung> dolphm, before we do that, client issues all resovled? 18:13:25 <bknudson> anyway, using oslo.db seems to be going pretty well, you can see the changes. 18:13:33 <dolphm> ayoung: i just want to make sure the patches in keystoneclient have traction 18:13:42 <bknudson> Base class only has 1 thing it it now which is just forwarding get_session. 18:14:08 <bknudson> dolphm: I think all my comments in https://review.openstack.org/#/c/35403/ should be easy to make. Not asking for a rewrite or anything. 18:14:12 <dolphm> oslo.db reviews: https://review.openstack.org/#/q/status:open+project:openstack/keystone+branch:master+topic:oslo.db,n,z 18:14:33 <bknudson> so, using oslo.db turned up some timing issues. 18:14:46 <bknudson> let me find the code... 18:15:00 <dolphm> ayoung: gyee: https://review.openstack.org/#/c/49655/ 18:15:14 <jamielennox> dolphm: re client - if I can figure out what cody is on about i wouldn't mind: https://review.openstack.org/#/c/49106/ being in 0.4 18:15:26 <bknudson> https://github.com/openstack/oslo-incubator/blob/master/openstack/common/db/sqlalchemy/session.py#L672 18:15:33 <bknudson> checkin handler does _thread_yield 18:15:37 <jamielennox> dolphm: depends how quickly you wnat to cut it 18:15:37 <dolphm> jamielennox: ping me after the meeting, i can help there 18:15:52 <bknudson> so what can happen is, we're deleting a role 18:16:00 <bknudson> and while deleting a role some other request to delete a user with that role 18:16:05 <ayoung> is that a dupe? couldve sworn I already ACKed that 18:16:08 <bknudson> now delete role gets 404 Not Found 18:16:35 <bknudson> I think we did talk about this, and decided in general it was ok to not find a user 18:16:39 <bknudson> so that operation shouldn't fail 18:16:51 <ayoung> bknudson, that is correct 18:16:55 <bknudson> but I wanted to make sure with others before I go removing that stuff. 18:16:57 <dolphm> in the separation between identity and assignment, i'd say that's fair 18:17:02 <ayoung> in general, things in assignments should not depend on things in identity being there 18:17:06 <lbragstad> NotFound: Object not found 2013-10-07 21:31:18.422 | Details: {"error": {"message": "Could not find user, be547582b3c541dda71dc202f9acc153.", "code": 404, "title": "Not Found"}} 18:17:14 <ayoung> for Federated, they are *not* going to be there 18:17:21 <bknudson> dolphm: ok, how about the cases where both in assignment? 18:17:46 <bknudson> I posed the code in assignment delete_grant: https://github.com/openstack/keystone/blob/master/keystone/assignment/backends/sql.py#L169 18:17:49 <dolphm> bknudson: both what? 18:18:06 <gyee> both in the same backend store? 18:18:07 <bknudson> you could delete a project at the same time as delete a role 18:18:07 <ayoung> bknudson, deleting a role should cascade delete all assignments. 18:18:15 <ayoung> deleting a project the same 18:18:17 <bknudson> https://github.com/openstack/keystone/blob/master/keystone/assignment/backends/sql.py#L179 18:18:33 <ayoung> if that comes in while someone else is attempting to delete...404 is appropriate 18:18:39 <ayoung> its an ACID issue 18:18:54 <ayoung> you tried to delete something that is already gone. 18:19:19 <dolphm> where are we handling the consequences of the project delete, for example? (deleting the role assignments on that project) 18:19:23 <bknudson> for assignment sql backend, could handle by doing the deletes in the same translaction. 18:19:25 <dolphm> in the manager or driver? 18:20:44 <ayoung> bknudson, that would be a good approach 18:21:02 <ayoung> LDAP can't do it all in one transaction, but that is likely to be fairly rare 18:21:23 <bknudson> right, we were going to deprecate LDAP assignments. 18:21:30 <ayoung> bknudson, not any more 18:21:36 <ayoung> CERN specifically asked for them to stay around 18:21:40 <dolphm> bknudson: *were* CERN said please no 18:21:45 <ayoung> said that LDAP was the only thing that would scale like they needed it 18:21:56 <morganfainberg> really? 18:22:01 <dolphm> joe-savak: i suspect rax would object as well? ^ 18:22:01 <ayoung> morganfainberg, yep 18:22:08 <bknudson> maybe they need no-sql mongodb 18:22:19 <morganfainberg> (sorry, just got back to my desk, been a hectic week, here now) 18:22:23 <joe-savak> dolphm - yes - we use LDAP only for our backend 18:22:43 <dolphm> joe-savak: i mean long term 18:22:45 <bknudson> joe-savak: is keystone configured with read-write? 18:22:51 <ayoung> joe-savak, but you also need multidomain, right? 18:23:10 <joe-savak> it is configured with read-write - and we have multi-domain implmeneted as a rax 2.0 extension (moving to v3 next year) 18:23:31 <joe-savak> and yes, it will be there long-term as we have 190k+ users and LDAP meets our needs well 18:23:33 <ayoung> joe-savak, is each domain in its own subtree a viable apporach for you guys? 18:23:43 <ayoung> approach 18:23:53 <joe-savak> ayoung - let me take that back to our ldap guy. Not sure 18:24:21 <gyee> ayoung, that's a typical LDAP deployment, domain map to a subtree 18:25:02 <morganfainberg> gyee, that seems like an accurate assessment 18:25:30 <ayoung> gyee, you know that and I know that, but I'm not sure that RAX knows that 18:25:49 <ayoung> the previous impl had a domain attribute.... 18:25:58 <dolphm> bknudson: so, the oslo.db stuff started because of the db2 handling fix -- is that still separate somewhere? 18:26:04 <dolphm> bknudson: or will that be on top of this patch? 18:26:23 <bknudson> dolphm: the db2 handling fix will not be needed when we switch to oslo.db 18:26:28 <dolphm> bknudson: oh cool 18:26:29 <ayoung> dolphm, as part of the oslo.db code, do we get the start of alembic migrations merged in? 18:26:35 <dolphm> bknudson: what about havana then? 18:26:36 <bknudson> dolphm: so the db2 changes are still there, hoping to be backported to havana. 18:27:02 <bknudson> dolphm: It's just this one https://review.openstack.org/#/c/49272/ 18:27:24 <dolphm> bknudson: we can propose things to milestone-proposed after they land in master 18:27:31 <dolphm> for havana rc2/final 18:27:38 <bknudson> dolphm: I'll do that! 18:27:48 <dolphm> bknudson: /salute 18:28:08 <bknudson> so I'd like https://review.openstack.org/#/c/49272/ to get in before the oslo.db change 18:28:32 <dolphm> which depends on https://review.openstack.org/#/c/49270/ 18:28:39 <bknudson> also, the disconnect fix is in oslo-incubator, so I'd like that to merge first, too. 18:28:50 <dolphm> which also needs to be in milestone-proposed, i think 18:28:51 <bknudson> yes, it turns out that our mysql disconnect handler didn't work at all either. 18:29:03 <morganfainberg> bknudson, ouch. 18:29:38 <dolphm> i'd love to get that bit merged to both master and milestone-proposed today 18:29:50 <dolphm> morganfainberg: gyee: ayoung: https://review.openstack.org/#/c/49270/ 18:30:00 <bknudson> I'll cherry-pick the changes to milestone-proposed 18:30:42 <ayoung> what is dbapi? 18:30:56 <ayoung> dbapi_conn? 18:30:58 <gyee> 1 line change, 58 lines of test, love these patches! 18:31:25 <bknudson> gyee: the 1 line change was required because there was no test 18:31:50 <ayoung> gyee, yeag...but are the tests now mysql specific? 18:31:59 <ayoung> or is the mysql in the comment just spurious? 18:32:27 <joe-savak> ayoung - fyi - all domains are in one subtree today - we are looking to split it out though 18:32:31 <morganfainberg> errro 2006 is mysql specific iirc 18:32:31 <gyee> ayoung, can't tell by looking at it 18:32:38 <ayoung> joe-savak, sounds good. I can work wityh you on that 18:32:43 <gyee> I mean can't tell if they are mysql specific 18:32:51 <ayoung> bknudson, is this test my_sql specific? 18:33:06 <morganfainberg> this test appears to be mysql specific as it calls sql.mysql_on_checkout 18:33:10 <bknudson> ayoung: dbapi_conn is a database connection, see https://review.openstack.org/#/c/49270/3/keystone/common/sql/core.py 18:33:23 <bknudson> itdoes dbapi_conn.cursor().execute('select 1') and dbapi_conn.OperationalError 18:33:26 <morganfainberg> ah. 18:33:45 <ayoung> bknudson, "Simulates the dbapi_conn passed to mysql_on_checkout." 18:34:13 <bknudson> ayoung: the test isn't really mysql-specific, but it tests the mysql-specific checkout handler. 18:34:34 <dolphm> morganfainberg: in bknudson's revised implementation that could just be renamed to ping_on_checkout or something 18:34:42 <morganfainberg> bknudson, does pgsql (or anything else) have the same mechanics? 18:34:50 <morganfainberg> dolphm, nod. i see that now. 18:34:53 <ayoung> bknudson, what happens if you run a live PostGresql test? 18:34:57 <bknudson> dolphm: morganfainberg: that change is in oslo.db! 18:35:07 * ayoung and morganfainberg on same wavelength 18:35:25 <bknudson> ayoung: the listener isn't registered with postgresql 18:35:53 <bknudson> it's looking for mysql-specific exception 18:35:56 <dolphm> i've never run into 'mysql server has gone away' with postgresql (nor db2 for that matter ;P) 18:36:59 <morganfainberg> dolphm, heh 18:37:18 <ayoung> dolphm, well...it looks like the live tests are broken anyway 18:37:28 <morganfainberg> ayoung, i am guessing other DBs would need special handling for the different error cases/codes 18:37:39 <ayoung> NoSuchOptError: no such option: policy_file 18:37:56 <ayoung> that happens because the policy backend registers its own config option, and that is not pulled in by the tests 18:37:58 <bknudson> ayoung: that problem was fixed in other places by importing somthing... 18:38:04 <ayoung> policy 18:38:04 <dolphm> morganfainberg: IF their client libraries expose you to the same issue 18:38:10 <morganfainberg> dolphm, yeah. 18:38:27 <bknudson> Here's the change in oslo.db: https://review.openstack.org/#/c/48733/ 18:38:46 <bknudson> it's failing Jenkins because of a requirements change that hasn't merged. 18:38:54 <dolphm> bknudson: it seems as though all of IBM is rushing to fix this issue 18:39:23 <bknudson> dolphm: it was found & reported internally so we're trying to fix it. 18:40:35 <dolphm> #topic open discussion 18:41:12 <gyee> jaimelennox, see my comment on the access key auth patch? 18:41:22 <gyee> jamielennox 18:41:34 <jamielennox> gyee: not as yet 18:42:02 <fabiog> #link https://review.openstack.org/#/c/46771/ 18:42:08 <gyee> both HP and RAX have access key auth support prior to KSL 18:42:15 <gyee> so this is not something new 18:42:38 <ayoung> gyee, should that be tied in with the credentials backend? 18:42:39 <gyee> we are just trying to bring back that capability 18:42:49 <gyee> ayoung, it is using cred backend 18:42:58 <jamielennox> gyee: i've been doing too much crypto - i saw secret keys and started trying to figure out what they were doing 18:43:14 <gyee> this patch does not use crypto 18:43:23 <gyee> just straight secret comparison 18:43:28 <ayoung> gyee, are these symetrric keysr or aym? 18:43:29 <ayoung> asym 18:43:35 <gyee> they are not keys 18:43:49 <gyee> just really long randomly-generate share secrets 18:43:54 <ayoung> gyee, symetric shared secredts 18:44:02 <ayoung> bleh 18:44:06 * ayoung cannot type 18:44:06 <gyee> right, not recommended for crypto 18:44:28 <ayoung> gyee, and the driving force behind this is to allow a user to have multiple "passwords" at once 18:44:38 <gyee> they are designed for non-interactive applications 18:44:48 <stevemar> gyee, fabio, is that the entire spec? or will there be CRUD operations surrounding the access keys? 18:44:56 <gyee> ayoung, correct, so to make a seamless secret rotation 18:45:01 <ayoung> stevemar, crud should be in the credential backend 18:45:11 <morganfainberg> ayoung, ++ 18:45:11 <ayoung> gyee, I think I can get behind that 18:45:12 <gyee> today, you can't rotate password without service disruption 18:45:13 <fabiog> ayoung: correct 18:45:43 <jamielennox> gyee: ok, that makes sense 18:45:45 <gyee> but you can rotate access keys with rolling upgrade 18:45:56 <ayoung> gyee, youi have a comment in there. Once he's updated, and you've reviewed and feel happy with it, ping us and we'll rip it to shreds 18:46:06 <gyee> ayoung, cool, thanks 18:46:06 <ayoung> but in general I am OK with this 18:46:42 <jamielennox> i think definetly remove the decypher remark and i think that there should be a more explicit the 'unscoped token' is related to the example and not that all tokens are unscoped 18:46:48 <jamielennox> but otherwise it looks good 18:47:13 <ayoung> probably change key to "shared secret" in the wording 18:47:17 <dolphm> gyee: so the secret is not a secret at all? 18:47:26 <joe-savak> as secret as a password. 18:47:27 <gyee> its a shared secret 18:47:32 <gyee> "shared" :) 18:47:38 <morganfainberg> but not in the crypto sense 18:47:50 <morganfainberg> overloaded terms… *runs and hides* 18:47:52 <gyee> joe-savak, ++ 18:48:00 <ayoung> yeah, nothing "key" about this, I think 18:48:10 <dolphm> joe-savak: i don't consider passwords to be "secret" 18:48:16 <joe-savak> what is yours? 18:48:16 <dolphm> ayoung: +++ 18:48:19 <dolphm> " 18:48:25 <stevemar> joe-savak ++ 18:48:29 <dolphm> "access key" is a bit misleading 18:48:32 <ayoung> speaking of keys, though, the KDS blueprint needs some work. I punted to jamielennox to shepherd it, but we are all kindof involved on this one 18:48:38 <morganfainberg> joe-savak, ******* 18:48:41 <gyee> yeah, lets call it shared-secret auth 18:48:47 <gyee> I am perfectly fine with it 18:48:48 <ayoung> gyee, +1 18:48:50 <jamielennox> fabiog: added another comment but it's not that big 18:48:58 <dolphm> joe-savak: if i trusted you i'd be happy to give it to you, which is what makes it a *shared* secret 18:49:05 <joe-savak> oauth then 18:49:20 <dolphm> joe-savak: if it was a secret, i wouldn't give it to you even if i trusted you 18:49:21 <ayoung> KDS really needs to be ready to go for I1 in order to have the other teams make use of it in Icehouse. We punted on it in Havana 18:49:32 <morganfainberg> ayoung, agreed 18:49:53 <jamielennox> ayoung: so i was looking through KDS yesterday - other than dolphm's -1 is anyone aware of something 'missing' from KDS? 18:50:03 <dolphm> gyee: doesn't HP call it "api keys" in v2? 18:50:08 <ayoung> I asked dolphm to put together a "style guide to the API docs" link is 18:50:09 <dolphm> (is that HP-IDM?) 18:50:09 <morganfainberg> jamielennox, the API speC? 18:50:11 <gyee> dolphm, yes 18:50:19 <jamielennox> morganfainberg: either 18:50:23 <joe-savak> RAX calls it API keys as well 18:50:23 <gyee> HP need to pick a better name 18:50:38 <jamielennox> morganfainberg: there is a review as well 'Initial KDS' or something 18:50:43 <dolphm> gyee: is HP-IDM broken down into access token + secret key? 18:50:50 <morganfainberg> jamielennox, hrm. let me look. i think we've pulled it apart and put it back together a bunch in comments so far. 18:51:01 <morganfainberg> and it's been a couple weeks since i've looked at it 18:51:02 <gyee> dolphm, it was called access-key prior to KSL I think 18:51:06 <ayoung> dolphm, can you post the link to your review request fopr the style guide? 18:51:10 <dolphm> joe-savak: i think rax's implementation is a standard api key though -- there's no second piece of information 18:51:20 <joe-savak> RAX-KSKEY - username & api-key 18:51:26 <dolphm> ayoung: https://review.openstack.org/#/c/49791/ 18:51:40 <ayoung> dolphm, thanks 18:51:55 <jamielennox> right - it appears AWS has this id & secret thing - but i can't see what the advantage is over having user_id + shared secret 18:52:14 <ayoung> what I would like to have happen is that we have a very clear set of guideline on API docs, so we don't spend a lot of churn figuring out what goes where 18:52:29 <annegentle_> ayoung: is audience not enough? 18:52:30 <ayoung> this is a great start. lets give it a review and make sure it is something we can all understand and support 18:52:40 <annegentle_> ayoung: or is it related to "is this a spec or not?" 18:52:48 * annegentle_ catches up 18:52:59 <ayoung> annegentle_, see https://review.openstack.org/#/c/49791/ 18:53:18 <ayoung> we are talking about the identity API, but I would guess that the standard should be OS wide 18:53:51 <annegentle_> ayoung: orignally we wanted specs across openstack 18:53:55 <bknudson> we've got both the identity API spec and the Identity API docs... do we need both? 18:53:57 <annegentle_> ayoung: that's not really happening tho 18:54:10 <ayoung> annegentle_, we've gotten kudos for our Identiyt API specs...but there has a been a huge amoung of effort to get there 18:54:24 <annegentle_> bknudson: as doc coordinator, I have historically ignored spec work because we just don't have time, and we serve users as a higher priority than devs making APIs 18:54:33 <annegentle_> ayoung: yes on both 18:54:46 <dolphm> jamielennox: it's totally different in aws 18:54:49 <annegentle_> ayoung: but yes, as I indicated, the doc team has to somewhat ignore specs 18:54:57 <bknudson> this has the spec info, too? http://api.openstack.org/api-ref-identity.html 18:54:57 <dolphm> jamielennox: in aws, i think it's oauth2 or a variation thereof 18:54:58 <annegentle_> ayoung: you guys were fortunate to have Diane clean up the v2 18:55:10 <ayoung> annegentle_, I'd like to take what dolph wrote for the identity API and make it a stand alone document eventually, but right now I think we most can benefit from the Keystone devs using it as a living doc for what we are doing in identity 18:55:13 <annegentle_> bknudson: that documents reality with real response/requests 18:55:32 <annegentle_> ayoung: sure, you should make your own priorities as well 18:55:55 <annegentle_> bknudson: if it doesn't document reality it's a doc bug 18:56:00 <dolphm> jamielennox: the same two terms are used though, which is why this proposal is confusing 18:56:17 <ayoung> annegentle_, considering how often we have pointed people at the curl examples, I'd like this document to at least reflect the guts of "how do aI talk to Keystone via the web API" 18:56:37 <gyee> annegentle_, its called "undocumented feature" 18:56:39 <gyee> not a bug 18:56:52 <annegentle_> ayoung: sounds great, Diane Fleming has a blueprint for Icehouse to try to give more real API examples, let me find the link 18:56:58 <ayoung> annegentle_, I used it heavily when writing the few examples I have so far 18:57:05 <jamielennox> dolphm: so i assume that it is meant to model some other auth system though, it seems to similar to others to have been made from scratch 18:57:16 <ayoung> annegentle_, http://adam.younglogic.com/2013/09/keystone-v3-api-examples/ 18:57:19 <annegentle_> https://wiki.openstack.org/wiki/Blueprint-os-api-docs 18:57:42 <annegentle_> ayoung: great, I'll point diane to it for her work 18:58:03 <ayoung> annegentle_, I want to do a follow up with some of the more esoteric ones, like creating trusts 18:59:01 <dolphm> jamielennox: are you referring to gyee's proposal modeling other auth systems? 18:59:21 <dolphm> time is about up -- switching to #openstack-dev! 18:59:32 <dolphm> #endmeeting keystone