17:06:57 <lbragstad> #startmeeting keystone-office-hours
17:06:57 <openstack> Meeting started Tue Mar 13 17:06:57 2018 UTC and is due to finish in 60 minutes.  The chair is lbragstad. Information about MeetBot at http://wiki.debian.org/MeetBot.
17:06:58 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
17:07:00 <openstack> The meeting name has been set to 'keystone_office_hours'
17:07:17 <lbragstad> we do have a bluejeans session going
17:07:26 <lbragstad> folks can join at any time
17:07:56 <cmurphy> bluejeans is where?
17:08:02 <lbragstad> #link https://bluejeans.com/8559013623
17:08:08 <cmurphy> ty
17:08:17 <lbragstad> cmurphy: did you already make it home?
17:09:37 <hrybacki> gagehugo: wxy kmalloc knikolla ^^
17:36:45 <aning> lbragstad, cmurphy, knikolla: for the deadlock issue in 014 of upgrade, I'm experimenting a solution. Basiaclly in 014_contract_add_domain_id_to_user_table.py, I check if the uniqueconstraints and foreignkeyconstraints have created or not, and only create them if they don't exist yet. This way, the keystone-manage db_sync contract can be re-run and proceed  to the next transaction.
17:37:32 <aning> since deadlock is rare, so a re-run should succeed.
17:38:00 <aning> The code (in debugging mode) is posted here: http://paste.openstack.org/show/700152/
17:39:01 <aning> Could you please have a look and see if there is any problem in there, and your concerns about the solution overall ?
17:48:05 <lbragstad> cmurphy: kmalloc http://paste.openstack.org/show/700177/
18:10:25 <openstackgerrit> Erik Olof Gunnar Andersson proposed openstack/keystone master: Fixing multi-region support in templated v3 catalog  https://review.openstack.org/482364
18:29:32 <cmurphy> aning: if it doesn't consistently fail then i think retrying makes sense
18:29:47 <cmurphy> aning: i'm confused that just re-running the contract phase doesn't just work though
18:30:10 <cmurphy> aning: if you haven't already can you open a bug for it?
18:32:02 <aning> No. If I got a deadloack the first run, when re-run contract, it will fail and complain UniqueConstraint relation "ixu_user_id_domain_id" already exists
18:33:34 <aning> since the contract is not a atomic transaction.
18:34:42 <aning> it fails (deadlock in this case) at certain point, when re-run it will try to do some of the transactions already done in the previous run.
18:37:47 <aning> cmurphy: yes, I'll open a bug for it.
18:52:23 <cmurphy> aning: i see, so then yes adding some idempotency in that migration makes sense to me
18:54:07 <aning> ideally the whole contract, or at least each of the step (014 for example), should be in a atomic transaction.
18:55:05 <aning> or like I'm experimenting, just check before doing any transactions to ensure it doesn't repeat what have been done before.
18:56:57 <cmurphy> ++
18:58:38 <lbragstad> stepping away to grab tea quick - brb
19:19:11 <abhi89> Hi All.. I see that in queens release, we have changed 'auth_uri' to 'www_authenticate_uri' (https://review.openstack.org/#/c/508522/) to avoid the confusion with 'auth_url'.. why haven't we changed 'auth_uri' in places like https://github.com/openstack/cinder/blob/master/cinder/quota_utils.py#L28
19:20:18 <abhi89> if someone updates to queens, its likely that the cinder quota utils code will fail.. there are other references of 'auth_uri' too apart from this..
19:20:39 <abhi89> cmurphy
19:20:42 <cmurphy> abhi89: we didn't remove auth_uri, we just deprecated it
19:21:27 <cmurphy> we do still need to find all those places that reference it but in the meantime it should still work
19:22:54 <abhi89> cmurphy: yes.. that means if we don't change our [keystone_authtoken] section to have 'www_authenticate_uri', everything will work fine.. but if we do, then this quota_utils code will fail as there won't be any 'auth_uri' parameter..
19:25:44 <cmurphy> yeah :(
19:36:45 <cmurphy> abhi89: did you try it and run into an error? I'm reading through oslo.config and it seems like it might just do the right thing but that might just be wishful thinking
19:43:20 <abhi89> cmurphy: i didnot try but I think it will not find 'auth_uri'
20:00:31 <ayoung> https://adam.younglogic.com/2013/07/a-vision-for-keystone/  I think I still stand by this.  Coming up on 5 years.
20:03:56 <ayoung> cmurphy, what was that abount unencrypted JWT?
20:05:06 <cmurphy> ayoung: http://specs.openstack.org/openstack/keystone-specs/specs/keystone/backlog/json-web-tokens.html
20:05:30 <cmurphy> ayoung: https://review.openstack.org/#/c/541903
20:05:43 <cmurphy> current ideas in there are to encrypt the token same as we do with fernet
20:06:05 <cmurphy> but that requires sharing the private keys between keystones
20:06:34 <cmurphy> so we were thinking of just signing and not encrypting
20:06:39 <ayoung> cmurphy, Out of curiousity, has anyone sized a JWT token with asym key signing?
20:08:18 <ayoung> when I last looked in to it, a fernet sized block signed with asym crypto came out to about 1K
20:09:29 <ayoung> I think signed without encrypting the body of a JWT makes sense.  But it will leak a little bit of information.  Still, it is no worse than if someone sniffs a token today....I think....I'd have to ruminate on that
20:10:32 <cmurphy> ayoung: no I'm not aware of any of us actually doing a PoC on the tokens to size them, though the jwt reference says "smaller than saml"
20:10:40 <cmurphy> ayoung: it is slightly worse than if someone sniffs a token today
20:10:42 <ayoung> cmurphy, signing requires a key
20:10:59 <ayoung> signing requires encryption, it is just a smaller encrypted document;  only the hash is encrypted.
20:11:11 <ayoung> doesn't avoid the need for a key
20:11:18 <cmurphy> it's slightly worse because if i have an expired encrypted token i can't return that to keystone to get information about it
20:12:05 <ayoung> for the same data, JWT is going to be smaller than SAML only (I think) due to the more concise document format
20:12:24 <ayoung> problem for PKI tokens was the service catalog
20:13:52 <ayoung> I was of the opinion that we should stick with the data that is in the Fernet body, and the keystonemiddleware could fetch and cache any data it needed in order to expand the tokens:  project names from IDs, etc.
20:14:50 <ayoung> it has all the keys distribution problems of PKI if you do, though, so I didn't push on it.
20:15:55 <lbragstad> #endmeeting