17:06:57 #startmeeting keystone-office-hours 17:06:57 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 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 17:07:00 The meeting name has been set to 'keystone_office_hours' 17:07:17 we do have a bluejeans session going 17:07:26 folks can join at any time 17:07:56 bluejeans is where? 17:08:02 #link https://bluejeans.com/8559013623 17:08:08 ty 17:08:17 cmurphy: did you already make it home? 17:09:37 gagehugo: wxy kmalloc knikolla ^^ 17:36:45 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 since deadlock is rare, so a re-run should succeed. 17:38:00 The code (in debugging mode) is posted here: http://paste.openstack.org/show/700152/ 17:39:01 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 cmurphy: kmalloc http://paste.openstack.org/show/700177/ 18:10:25 Erik Olof Gunnar Andersson proposed openstack/keystone master: Fixing multi-region support in templated v3 catalog https://review.openstack.org/482364 18:29:32 aning: if it doesn't consistently fail then i think retrying makes sense 18:29:47 aning: i'm confused that just re-running the contract phase doesn't just work though 18:30:10 aning: if you haven't already can you open a bug for it? 18:32:02 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 since the contract is not a atomic transaction. 18:34:42 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 cmurphy: yes, I'll open a bug for it. 18:52:23 aning: i see, so then yes adding some idempotency in that migration makes sense to me 18:54:07 ideally the whole contract, or at least each of the step (014 for example), should be in a atomic transaction. 18:55:05 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 ++ 18:58:38 stepping away to grab tea quick - brb 19:19:11 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 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 cmurphy 19:20:42 abhi89: we didn't remove auth_uri, we just deprecated it 19:21:27 we do still need to find all those places that reference it but in the meantime it should still work 19:22:54 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 yeah :( 19:36:45 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 cmurphy: i didnot try but I think it will not find 'auth_uri' 20:00:31 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 cmurphy, what was that abount unencrypted JWT? 20:05:06 ayoung: http://specs.openstack.org/openstack/keystone-specs/specs/keystone/backlog/json-web-tokens.html 20:05:30 ayoung: https://review.openstack.org/#/c/541903 20:05:43 current ideas in there are to encrypt the token same as we do with fernet 20:06:05 but that requires sharing the private keys between keystones 20:06:34 so we were thinking of just signing and not encrypting 20:06:39 cmurphy, Out of curiousity, has anyone sized a JWT token with asym key signing? 20:08:18 when I last looked in to it, a fernet sized block signed with asym crypto came out to about 1K 20:09:29 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 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 ayoung: it is slightly worse than if someone sniffs a token today 20:10:42 cmurphy, signing requires a key 20:10:59 signing requires encryption, it is just a smaller encrypted document; only the hash is encrypted. 20:11:11 doesn't avoid the need for a key 20:11:18 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 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 problem for PKI tokens was the service catalog 20:13:52 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 it has all the keys distribution problems of PKI if you do, though, so I didn't push on it. 20:15:55 #endmeeting