*** emagana has quit IRC | 00:01 | |
openstackgerrit | Morgan Fainberg proposed openstack/keystoneauth: Remove oslo.utils dependency from keystoneauth https://review.openstack.org/185789 | 00:11 |
---|---|---|
openstackgerrit | Morgan Fainberg proposed openstack/keystoneauth: Remove lxml test-requirement https://review.openstack.org/185790 | 00:14 |
morganfainberg | mordred, ^ no more lxml in keystoneauth! | 00:15 |
mordred | woot! | 00:15 |
morganfainberg | down to i18n and config as oslo deps | 00:15 |
*** markvoelker has joined #openstack-keystone | 00:16 | |
morganfainberg | i18n i'm just going to toss to the curb | 00:16 |
morganfainberg | config will take a bit more thought | 00:16 |
*** sigmavirus24_awa is now known as sigmavirus24 | 00:17 | |
*** alanf-mc has joined #openstack-keystone | 00:19 | |
*** david-lyle has quit IRC | 00:20 | |
*** markvoelker has quit IRC | 00:23 | |
*** markvoelker has joined #openstack-keystone | 00:23 | |
morganfainberg | mordred: well crap my attempt at killing oslo_utils failed because osprofiler | 00:24 |
morganfainberg | mordred: :*( | 00:24 |
openstackgerrit | Merged openstack/keystoneauth: Remove oslo serialization dependency https://review.openstack.org/185497 | 00:27 |
dims | morganfainberg: oslo-free keystone? | 00:30 |
morganfainberg | dims: only keystoneauth lib | 00:30 |
dims | ah :) | 00:30 |
*** Ephur has joined #openstack-keystone | 00:35 | |
morganfainberg | dims: since keystoneauth needs to have effectively no dependencies | 00:37 |
dims | ++ morganfainberg | 00:38 |
openstackgerrit | Morgan Fainberg proposed openstack/keystoneauth: Remove oslo.utils dependency from keystoneauth https://review.openstack.org/185789 | 00:41 |
openstackgerrit | Morgan Fainberg proposed openstack/keystoneauth: Remove lxml test-requirement https://review.openstack.org/185790 | 00:41 |
openstackgerrit | Morgan Fainberg proposed openstack/keystoneauth: Remove oslo.utils dependency from keystoneauth https://review.openstack.org/185789 | 00:43 |
openstackgerrit | Morgan Fainberg proposed openstack/keystoneauth: Remove lxml test-requirement https://review.openstack.org/185790 | 00:43 |
*** _cjones_ has quit IRC | 00:50 | |
morganfainberg | hmm | 00:58 |
morganfainberg | dims: so i am worried about i18n | 00:58 |
morganfainberg | dims: we have a *lot* of strings to be translated | 00:58 |
morganfainberg | dims: in keystoneauth | 00:59 |
morganfainberg | dims: but i'm not sure how those are translated as is. | 00:59 |
morganfainberg | dims: i also worry about the dependency graph issues when including i18n from oslo. *really* want to eliminate all oslo libs from this library, - is that a concern to keep it at all? | 01:00 |
openstackgerrit | Morgan Fainberg proposed openstack/keystoneauth: Remove oslo.i18n dependency https://review.openstack.org/185799 | 01:04 |
dims | morganfainberg: if the library does not need to have end user visible strings, that's perfectly ok | 01:05 |
morganfainberg | dims: here is the thing... it currently does. | 01:05 |
morganfainberg | dims: however long term I think we can mitigate that | 01:05 |
dims | morganfainberg: here's the primer on how translation is done https://wiki.openstack.org/wiki/Translations | 01:05 |
morganfainberg | dims: but afaik keystoneclient isn't receiving translations as it is | 01:06 |
morganfainberg | so the net impact is: we already aren't translating these | 01:06 |
dims | morganfainberg: right, if you want then we have to set that up. instructions are on that page. i've done it once and we'll need andreas' help | 01:06 |
morganfainberg | dims: my concern *really* is that i18n brings in incompatible dependencies, keystoneauth breaks in bad ways. so i think we just need to eliminate end-user facing trings | 01:06 |
morganfainberg | strings* | 01:06 |
dims | i agree | 01:07 |
dims | several oslo projects don't use i18n either | 01:07 |
morganfainberg | ok so i'll go with tossing i18n lib to the floor for this pass. we can work on the strings bit | 01:07 |
dims | ack | 01:07 |
dims | i gotta wrap up. we can talk tomorrow. i'll do some reviews then as well. | 01:07 |
morganfainberg | if you wouldn't mind just saying you have no isseus with this on that review? ^https://review.openstack.org/185799 | 01:07 |
morganfainberg | dims: when you get a chance | 01:08 |
morganfainberg | just so no one flips that we're doing this w/o planning | 01:08 |
morganfainberg | dims: have a good one and thnx | 01:08 |
*** tobe has joined #openstack-keystone | 01:09 | |
dims | morganfainberg: one more way to slowly get rid of it is to do something like http://git.openstack.org/cgit/openstack/oslo-incubator/tree/openstack/common/_i18n.py#n45 | 01:10 |
dims | _ = _LI = _LW = _LE = _LC = lambda x: x | 01:10 |
morganfainberg | dims: i think i smacked them all down already :) | 01:10 |
dims | will look deeper tomorrow. thanks | 01:10 |
dims | cool :) | 01:11 |
*** dims has quit IRC | 01:12 | |
openstackgerrit | Morgan Fainberg proposed openstack/keystoneauth: Remove oslo.i18n dependency https://review.openstack.org/185799 | 01:12 |
morganfainberg | jamielennox|away: ^^ oslo_utils and oslo_i18n removed. down to oslo_config | 01:14 |
morganfainberg | jamielennox|away: not sure how we want to handle that one. | 01:14 |
mfisch | lbragstad: do I need to hup keystone when I rotate fernet keys? | 01:18 |
morganfainberg | mfisch: shouldn't need to | 01:19 |
mfisch | lbragstad: and can I do rotation on my own outside of fernet_rotate? | 01:19 |
morganfainberg | mfisch: it should read out of the repository directly | 01:19 |
mfisch | I think I'll manage keys in hiera and rotate them as a commit | 01:19 |
morganfainberg | mfisch: and you should be able to rotate outside of that too | 01:19 |
morganfainberg | tool | 01:19 |
mfisch | thanks | 01:19 |
morganfainberg | mfisch: just be sure it formats the repo as expected | 01:19 |
mfisch | highest is primary, 0 is on-deck | 01:20 |
morganfainberg | yep | 01:20 |
*** davechen has joined #openstack-keystone | 01:20 | |
mfisch | so my plan is to keep re-using 0,1,2 | 01:20 |
morganfainberg | keep as many as you need to ensure validation | 01:20 |
mfisch | but rotate them in my hiera | 01:20 |
morganfainberg | my expectation is most people will rotate ~1/wk or every 2wks | 01:20 |
morganfainberg | even though you could rotate much more often | 01:20 |
mfisch | with our deployment schedule thats about what we'll do | 01:21 |
*** jamielennox|away is now known as jamielennox | 01:23 | |
*** sigmavirus24 is now known as sigmavirus24_awa | 01:24 | |
*** davechen1 has joined #openstack-keystone | 01:25 | |
jamielennox | morganfainberg: yea, oslo_config is hard - but looking at it there really aren't any deps from oslo.config | 01:26 |
*** davechen has quit IRC | 01:26 | |
*** alanf-mc has quit IRC | 01:27 | |
jamielennox | morganfainberg: did i not upload the oslo.utils removal patch | 01:30 |
morganfainberg | jamielennox: only saw serialization. | 01:31 |
jamielennox | i must have forgotten to upload them | 01:31 |
morganfainberg | We still have the dep issues. We will need to remove Oslo.config. | 01:31 |
mordred | morganfainberg, jamielennox: I see zero reasons for keystoneauth to grok oslo.config | 01:32 |
mordred | what uses it? | 01:32 |
morganfainberg | mordred: agreed. But today the auth plugins do. | 01:32 |
mordred | why does an auth plugin grok oslo.config? | 01:32 |
* mordred doesn't want to know does he? | 01:32 | |
*** ayoung has joined #openstack-keystone | 01:33 | |
*** ChanServ sets mode: +v ayoung | 01:33 | |
morganfainberg | Because it sources that data directly instead of passed it. Was/is an artifact from ksc and session there. | 01:33 |
morganfainberg | Nothing terrible. | 01:33 |
morganfainberg | Just something to fix. | 01:34 |
mordred | kk | 01:34 |
jamielennox | mordred: initially because the plugins need to be able to register themselves against a config file | 01:34 |
jamielennox | and then we used the oslo.config Opt classes for the get_options | 01:35 |
openstackgerrit | Jamie Lennox proposed openstack/keystoneauth: Remove some cruft from the service catalog https://review.openstack.org/185805 | 01:35 |
openstackgerrit | Jamie Lennox proposed openstack/keystoneauth: Make utils file private https://review.openstack.org/185806 | 01:35 |
openstackgerrit | Jamie Lennox proposed openstack/keystoneauth: Remove oslo.utils dependency https://review.openstack.org/185807 | 01:35 |
*** setmason has quit IRC | 01:35 | |
*** david-lyle has joined #openstack-keystone | 01:35 | |
jamielennox | morganfainberg: so that's what i didn't upload, i think we should do the first two and i don't cares which of the remove oslo.utils we do | 01:35 |
morganfainberg | jamielennox: yeah I don't care. Just as long as it's done ;) | 01:35 |
jamielennox | rebasing that middle one will be a pain though | 01:36 |
morganfainberg | I almost did that to the utile module in mine too. Hah. | 01:37 |
jamielennox | i have a patch open with debtcollector for it to take the positional decorator, i don't know if we would want that dep or not though | 01:38 |
morganfainberg | I am not familiar with how debtcollector is moving. I'm inclined to be hesitant taking on another dep. | 01:39 |
morganfainberg | In an ideal world six and requests. | 01:39 |
jamielennox | stevedore or are you thinking that's a different lib | 01:39 |
morganfainberg | But I also see the need for stevedore. | 01:39 |
jamielennox | https://github.com/openstack/debtcollector/blob/master/requirements.txt | 01:39 |
mordred | babel is super heavyweight | 01:40 |
jamielennox | but i have a review open to remove oslo.utils from debtcollector | 01:40 |
morganfainberg | mordred: posted a change to drop babel and i18n already. | 01:40 |
jamielennox | there is a circular dependency oslo.utils -> debtcollector -> oslo.utils - and people say pip is bad | 01:40 |
mordred | :) | 01:41 |
morganfainberg | jamielennox: let's carry positional. When we hit py3 we can make it go away. | 01:41 |
morganfainberg | For ksa at least. | 01:41 |
morganfainberg | Py3 only* | 01:41 |
jamielennox | dhellmann: around? | 01:43 |
jamielennox | i keep missing him to ask about the ksc/ksa gate branch | 01:44 |
morganfainberg | jamielennox: hehe. Got to be earlier. He is east coast. | 01:45 |
jamielennox | can you ask him about it tomorrow? | 01:45 |
jamielennox | otherwise i've got the infra review ready to go and we can problably get it merged quick | 01:45 |
morganfainberg | I shall try and bug him tomorrow. | 01:46 |
*** lhcheng_ has quit IRC | 01:46 | |
*** kiran-r has joined #openstack-keystone | 01:55 | |
mfisch | morganfainberg: is there any middleware changes needed for the other services to handle fernet? I think the answer is no but would like a confirm | 02:09 |
mfisch | or a minimal version for other services to use fernet with... | 02:09 |
mfisch | I hope to blog about this when its working so that you dont have to answer the same questions | 02:10 |
*** kiran-r has quit IRC | 02:17 | |
*** kiran-r has joined #openstack-keystone | 02:31 | |
*** david-lyle has quit IRC | 02:33 | |
*** setmason has joined #openstack-keystone | 02:33 | |
*** gyee has quit IRC | 02:36 | |
*** spandhe has quit IRC | 02:38 | |
morganfainberg | mfisch: you need a new enough django_openstack_auth | 02:40 |
morganfainberg | mfisch: but no specific middleware changes should be needed. | 02:41 |
mfisch | morganfainberg: django for horizon right not for other stuff | 02:42 |
mfisch | we do have that iirc | 02:42 |
morganfainberg | Yes. | 02:42 |
morganfainberg | The new one doesn't try to hash fernet tokens. | 02:42 |
mfisch | yeah we're ahead of master on Horizon | 02:42 |
mfisch | lots of changes | 02:42 |
morganfainberg | Then you should be good. | 02:42 |
mfisch | thanks for defeating all the FUD | 02:43 |
mfisch | UUID supporters are everywhere and not to be trusted | 02:43 |
dolphm | mfisch: were you at the summit?! i never saw you | 02:44 |
mfisch | yeah I thought I'd do 4 talks | 02:44 |
mfisch | and then Tuesday I was in the puppet room | 02:44 |
mfisch | dolphm: were you at the +2 party? | 02:45 |
mfisch | I saw steve and brad there | 02:46 |
dolphm | mfisch: i was not :( | 02:46 |
*** gokrokve has joined #openstack-keystone | 02:52 | |
*** browne has quit IRC | 03:00 | |
*** gokrokve has quit IRC | 03:06 | |
*** gokrokve has joined #openstack-keystone | 03:07 | |
*** lhcheng has joined #openstack-keystone | 03:07 | |
*** ChanServ sets mode: +v lhcheng | 03:07 | |
*** tobe has quit IRC | 03:08 | |
*** gokrokve has quit IRC | 03:11 | |
*** david-lyle has joined #openstack-keystone | 03:11 | |
*** kiran-r has quit IRC | 03:18 | |
morganfainberg | mfisch: I am going to make devstack default to fernet this cycle. | 03:20 |
*** samueldmq has quit IRC | 03:21 | |
*** tobe has joined #openstack-keystone | 03:26 | |
*** pnavarro has quit IRC | 03:27 | |
*** browne has joined #openstack-keystone | 03:30 | |
*** stevemar has joined #openstack-keystone | 03:33 | |
*** ChanServ sets mode: +v stevemar | 03:33 | |
*** jaosorior has joined #openstack-keystone | 03:44 | |
*** emagana has joined #openstack-keystone | 03:51 | |
*** tobe has quit IRC | 03:58 | |
openstackgerrit | Jamie Lennox proposed openstack/keystoneauth: Remove old request method https://review.openstack.org/185492 | 04:04 |
*** links has joined #openstack-keystone | 04:15 | |
*** markvoelker has quit IRC | 04:31 | |
*** tobe has joined #openstack-keystone | 04:34 | |
*** spandhe has joined #openstack-keystone | 04:49 | |
*** gokrokve has joined #openstack-keystone | 04:56 | |
*** spandhe has quit IRC | 04:59 | |
*** kiran-r has joined #openstack-keystone | 05:00 | |
*** tobe has quit IRC | 05:04 | |
*** henrynash has joined #openstack-keystone | 05:10 | |
*** ChanServ sets mode: +v henrynash | 05:10 | |
*** csoukup has quit IRC | 05:12 | |
*** gokrokve has quit IRC | 05:14 | |
*** spandhe has joined #openstack-keystone | 05:20 | |
*** henrynash has quit IRC | 05:23 | |
*** belmoreira has joined #openstack-keystone | 05:23 | |
*** cloudm2 has quit IRC | 05:32 | |
*** setmason has quit IRC | 05:34 | |
*** setmason has joined #openstack-keystone | 05:35 | |
*** ncoghlan has joined #openstack-keystone | 05:38 | |
*** gabriel-bezerra has joined #openstack-keystone | 05:45 | |
*** tobe has joined #openstack-keystone | 05:50 | |
*** emagana has quit IRC | 06:00 | |
*** emagana has joined #openstack-keystone | 06:01 | |
*** e0ne has joined #openstack-keystone | 06:01 | |
*** gabriel-bezerra has left #openstack-keystone | 06:02 | |
*** gabriel-bezerra has quit IRC | 06:02 | |
*** emagana has quit IRC | 06:05 | |
*** gabriel-bezerra has joined #openstack-keystone | 06:07 | |
*** e0ne has quit IRC | 06:11 | |
*** lhcheng has quit IRC | 06:19 | |
*** tobe has quit IRC | 06:20 | |
*** lhcheng has joined #openstack-keystone | 06:21 | |
*** ChanServ sets mode: +v lhcheng | 06:21 | |
*** ayoung has quit IRC | 06:22 | |
*** lufix_ has joined #openstack-keystone | 06:29 | |
*** mflobo has quit IRC | 06:29 | |
*** mflobo1 has joined #openstack-keystone | 06:29 | |
*** mflobo1 has quit IRC | 06:31 | |
*** mflobo has joined #openstack-keystone | 06:33 | |
*** tobe has joined #openstack-keystone | 06:38 | |
*** ankita_wagh has joined #openstack-keystone | 06:45 | |
*** ankita_wagh has quit IRC | 06:45 | |
*** User17 has quit IRC | 06:52 | |
*** pece has joined #openstack-keystone | 06:53 | |
*** Ephur has quit IRC | 06:56 | |
*** urtz has joined #openstack-keystone | 06:57 | |
openstackgerrit | Dave Chen proposed openstack/keystone: Add testcases to test DefaultDomain https://review.openstack.org/185855 | 06:57 |
*** urtz has quit IRC | 06:58 | |
*** mabrams has joined #openstack-keystone | 06:58 | |
openstackgerrit | Dave Chen proposed openstack/keystone: Add testcases to test DefaultDomain https://review.openstack.org/185855 | 07:03 |
*** setmason has quit IRC | 07:06 | |
*** spandhe has quit IRC | 07:10 | |
*** setmason has joined #openstack-keystone | 07:12 | |
*** markvoelker has joined #openstack-keystone | 07:17 | |
*** stevemar has quit IRC | 07:20 | |
*** emagana has joined #openstack-keystone | 07:25 | |
*** ncoghlan has quit IRC | 07:26 | |
*** emagana has quit IRC | 07:30 | |
*** krykowski has joined #openstack-keystone | 07:30 | |
*** tobe has quit IRC | 07:37 | |
*** dims has joined #openstack-keystone | 07:38 | |
*** tobe has joined #openstack-keystone | 07:38 | |
*** dguerri`away is now known as dguerri | 07:40 | |
*** setmason has quit IRC | 07:41 | |
*** dims has quit IRC | 07:44 | |
*** chlong has quit IRC | 07:45 | |
*** lufix has quit IRC | 07:47 | |
*** jistr has joined #openstack-keystone | 07:52 | |
*** g2` has quit IRC | 07:58 | |
*** emagana has joined #openstack-keystone | 08:04 | |
*** g2` has joined #openstack-keystone | 08:05 | |
*** emagana has quit IRC | 08:09 | |
*** e0ne has joined #openstack-keystone | 08:15 | |
*** henrynash has joined #openstack-keystone | 08:15 | |
*** ChanServ sets mode: +v henrynash | 08:15 | |
*** e0ne has quit IRC | 08:19 | |
*** tobe has quit IRC | 08:42 | |
*** lhcheng has quit IRC | 08:43 | |
*** tobe has joined #openstack-keystone | 08:43 | |
*** lhcheng has joined #openstack-keystone | 08:43 | |
*** ChanServ sets mode: +v lhcheng | 08:43 | |
*** fhubik has joined #openstack-keystone | 08:53 | |
*** lhcheng has quit IRC | 08:54 | |
*** emagana has joined #openstack-keystone | 08:59 | |
*** lifeless has quit IRC | 09:00 | |
*** lifeless_ has joined #openstack-keystone | 09:00 | |
*** emagana has quit IRC | 09:03 | |
*** fhubik is now known as fhubik_afk | 09:12 | |
*** belmoreira has quit IRC | 09:15 | |
*** ekarlso has quit IRC | 09:16 | |
*** rushiagr_away is now known as rushiagr | 09:18 | |
*** ekarlso has joined #openstack-keystone | 09:22 | |
*** e0ne has joined #openstack-keystone | 09:23 | |
*** e0ne is now known as e0ne_ | 09:23 | |
*** lhcheng has joined #openstack-keystone | 09:30 | |
*** ChanServ sets mode: +v lhcheng | 09:30 | |
*** lhcheng has quit IRC | 09:30 | |
*** lhcheng has joined #openstack-keystone | 09:31 | |
*** ChanServ sets mode: +v lhcheng | 09:31 | |
*** e0ne_ is now known as e0ne | 09:31 | |
*** lhcheng has quit IRC | 09:32 | |
*** fhubik_afk is now known as fhubik | 09:33 | |
mabrams | hi. need a link to the openstack keystone upstream etherpad pls. | 09:33 |
*** mattfarina has joined #openstack-keystone | 09:41 | |
*** jaosorior has quit IRC | 09:42 | |
*** mattfarina has quit IRC | 09:42 | |
*** lhcheng has joined #openstack-keystone | 09:47 | |
*** ChanServ sets mode: +v lhcheng | 09:47 | |
*** davechen1 has left #openstack-keystone | 09:48 | |
*** henrynash has quit IRC | 09:48 | |
*** henrynash_ has joined #openstack-keystone | 09:48 | |
*** ChanServ sets mode: +v henrynash_ | 09:48 | |
*** emagana has joined #openstack-keystone | 09:53 | |
*** emagana has quit IRC | 09:57 | |
*** lhcheng has quit IRC | 09:59 | |
*** rushiagr has quit IRC | 10:08 | |
*** dims has joined #openstack-keystone | 10:09 | |
*** henrynash_ has quit IRC | 10:13 | |
*** fhubik has quit IRC | 10:14 | |
*** fhubik has joined #openstack-keystone | 10:14 | |
*** fhubik is now known as fhubik_afk | 10:42 | |
*** fmarco76 has joined #openstack-keystone | 10:46 | |
*** emagana has joined #openstack-keystone | 10:47 | |
*** fmarco76 has left #openstack-keystone | 10:47 | |
*** emagana has quit IRC | 10:48 | |
*** emagana has joined #openstack-keystone | 10:48 | |
*** emagana has quit IRC | 10:53 | |
*** lufix_ has quit IRC | 10:57 | |
*** samueldmq has joined #openstack-keystone | 11:00 | |
samueldmq | morning | 11:00 |
*** rushiagr_away has joined #openstack-keystone | 11:00 | |
*** e0ne is now known as e0ne_ | 11:26 | |
*** dsirrine has quit IRC | 11:26 | |
*** openstack has joined #openstack-keystone | 11:37 | |
*** emagana has joined #openstack-keystone | 11:43 | |
*** aix has joined #openstack-keystone | 11:47 | |
*** emagana has quit IRC | 11:48 | |
*** tobe has joined #openstack-keystone | 11:52 | |
*** tobe has quit IRC | 11:56 | |
*** tobe has joined #openstack-keystone | 11:57 | |
*** markvoelker has quit IRC | 12:04 | |
*** markvoelker has joined #openstack-keystone | 12:04 | |
*** e0ne is now known as e0ne_ | 12:09 | |
*** e0ne_ is now known as e0ne | 12:14 | |
*** jaosorior has joined #openstack-keystone | 12:19 | |
samueldmq | jamielennox, ping - you around ? | 12:26 |
samueldmq | jamielennox, just to confirm, ksclient does not implement the policy CRUD, does it ? | 12:26 |
*** raildo has joined #openstack-keystone | 12:27 | |
samueldmq | jamielennox, well .. it does https://github.com/openstack/python-keystoneclient/blob/master/keystoneclient/v3/policies.py | 12:27 |
samueldmq | :) | 12:27 |
*** dims has quit IRC | 12:31 | |
*** dims has joined #openstack-keystone | 12:32 | |
*** emagana has joined #openstack-keystone | 12:37 | |
*** emagana has quit IRC | 12:41 | |
*** josecastroleon has joined #openstack-keystone | 12:49 | |
*** ekarlso has quit IRC | 12:53 | |
*** ekarlso has joined #openstack-keystone | 12:53 | |
*** gordc has joined #openstack-keystone | 12:58 | |
*** henrynash has joined #openstack-keystone | 13:02 | |
*** ChanServ sets mode: +v henrynash | 13:02 | |
lbragstad | mfisch: just following up, you can rotate outside of that tool (you'll also need to find a way to distribute if your syncing your key repository across multiple keystone nodes -- which isn't supported by keystone-manage) | 13:02 |
*** ayoung has joined #openstack-keystone | 13:04 | |
*** ChanServ sets mode: +v ayoung | 13:04 | |
samueldmq | ayoung, henrynash hi ! | 13:06 |
*** bknudson has joined #openstack-keystone | 13:06 | |
*** ChanServ sets mode: +v bknudson | 13:06 | |
samueldmq | good morning :) | 13:06 |
henrynash | samuelsmq: hi | 13:06 |
samueldmq | henrynash, ayoung +1ed the domain-roles spec ... but he prefers to call it namespaced roles | 13:06 |
samueldmq | henrynash, ayoung I'd like to put it on the table and discuss a little bit if you are available | 13:07 |
*** Ephur has joined #openstack-keystone | 13:07 | |
ayoung | henrynash, yes, me too | 13:07 |
samueldmq | great | 13:07 |
henrynash | ayoung: so in princple that seems fine…is there an idea that a namespace might be more than a domain? | 13:07 |
henrynash | ayoung: i.e. some other namespace? | 13:08 |
samueldmq | henrynash, ++ that's the question .. should we consider per project roles ? | 13:08 |
ayoung | henrynash, I was wondering if I had maybe misunderstood what you wanted with domain scoped roles. And...I was thinking, how would we make sure, say, admin for openstack did not conflict with admin for something else, like | 13:08 |
ayoung | If we want to serve rolls...er roles, damn now I am all hungry | 13:08 |
ayoung | anyway, if we want to serve our roles for multiple applications, the namespace would keep them separate, but that was not what I thought you wanted with domain scoped roles. But, it might be? | 13:09 |
henrynash | ayoung: so I would say decision 1 is: do we add namespace to a role (i.e. they are no longer global)….and I think that’s separate from whether that namespace can only be a domain namespace, or other namepaces | 13:10 |
ayoung | henrynash, so...why domain scoped? | 13:10 |
samueldmq | henrynash, I guess ayoung wants some other namespaces, like: openstack, wordpress, etc | 13:10 |
samueldmq | ayoung, I think henry wants you to explain him any use case to have other than domain :) | 13:11 |
henrynash | ayoung: the need I see is for a company to be able to define the roles that are meaningful to them, and not just live with whatever teh cloud provider has created…..in installations where many customers are hosted on a cloud, and each customer is defined as a domain (which is teh usual case, I think ) | 13:11 |
ayoung | samueldmq, yeah, but I want to make sure our problem definitions are aligning...I think they might be | 13:11 |
samueldmq | maybe you guys want to solve different problems | 13:11 |
samueldmq | ayoung, ++ | 13:11 |
ayoung | henrynash, you once said that you don't want other people to see the roles, but then we decided we needed to be able to enforce policy on the role. Would a namespacing for the role (and who could define it) solve your problem set? I would see that we would want to lock down who could define what for a given organization... | 13:13 |
*** radez_g0n3 is now known as radez | 13:13 | |
ayoung | I'm not 100% namespacing is the entirety of the problem, but I think it is part of the way | 13:13 |
ayoung | so...each domain *could* be a namespace.... | 13:13 |
henrynash | ayoung, samueldmq: I think the other namespace taht could be relevant is a service namesapce…..i.e. a cloud wants to allow new services to onboarded that can then be “bought” by some of the customers…..and maybe the servcie provider (who is not the cloud provider) should be able to define the roles needed to execute the APIs offererd by that service | 13:13 |
ayoung | and we could also have global namespaces for standard things like wordpress | 13:14 |
ayoung | henrynash, I think that is it. We definitely want nested namespaces, with domain being a potential outer, one. | 13:14 |
*** Ephur has quit IRC | 13:14 | |
samueldmq | cool .. so we have domain-namespaces *and* global namespaces | 13:15 |
samueldmq | so let's just call it namespaced roles :) | 13:15 |
ayoung | actaully...yes, we'd always start with an outer namespace | 13:15 |
henrynash | ayoung: agreed, nested namespaces wil neeeded | 13:15 |
ayoung | the global would come from the admin domain, and would be assumed if no namespace was specified | 13:15 |
ayoung | henrynash, you are a freaking jenious | 13:15 |
henrynash | a service name spaces might be a child of the global name spaces | 13:15 |
ayoung | the global namespace would be the domains names | 13:16 |
samueldmq | yeah, and we could namespace global roles with "openstack:" if we wanted to ... | 13:16 |
samueldmq | so if we had "wordpress:", etc it would be clearer | 13:16 |
ayoung | samueldmq, yeah, something like that | 13:16 |
ayoung | samueldmq, and then, if the, say, ibm.com domain wanted to have their own namespace, they would define ibm.dom:wordpress:custom | 13:17 |
samueldmq | ayoung, yeah, as it fits better | 13:17 |
ayoung | dom dom dom dom | 13:17 |
samueldmq | ayoung, henrynash great! and namespaced roles can contains other namespaced roles ? as per user grouping ? (that's the original idea from domain-roles) | 13:17 |
samueldmq | ayoung, hehhe | 13:17 |
ayoung | so...need to figure out how that works with policy. | 13:18 |
ayoung | I think global poliocy files are not going to cut it. | 13:18 |
ayoung | they are going to be too big, and have too much data. | 13:18 |
henrynash | ayoung: yeah, that’s where I usually come unstuck and regress into “hey, expand out the namespaced roles into global roles in the token”…then I can stop worrying! | 13:18 |
henrynash | ayoung: but you have convinced me that that does not work in the long run | 13:19 |
henrynash | ayoung: token bloat | 13:19 |
samueldmq | henrynash, namespaced roles can be or not contained by global roles, but anyway that will be huge i nthe future | 13:19 |
samueldmq | henrynash, ++ | 13:19 |
samueldmq | are we going to introduce role-namespace (or something like that) as a keystone citizen ? | 13:20 |
ayoung | henrynash, really what we need is to be able to fetch policy for a service as the main way of working, with endpoint resolving to service. So... maybe we drop the idea of fetching a default opolicy file, and instead, always fetch buy endpoint....we can use the unified default as the file that gets returned for openstack services | 13:21 |
henrynash | if we include the namespace in the defintion or a role (where it is referred to by policy), then we can start doing thi sproperly | 13:21 |
ayoung | samueldmq, I think namespaced roles will be M, not Liberty, but yes | 13:21 |
ayoung | henrynash, ++ | 13:21 |
samueldmq | I think namespaced roles will be quite fun to implement with you :p | 13:22 |
samueldmq | btw, ayoung do you agree with the idea that namespaced roles can contain other namespaced roles (or gloabl roles) | 13:22 |
samueldmq | ? | 13:22 |
henrynash | ayoung: I’m pretty sure you are right, it will take a couple of releases….since wherever there is a role (assignment, token, policy rule) we need to be able to handle a namespace (or it by an ID such that it is unique anyway) | 13:22 |
ayoung | The siphonaptera lives! | 13:23 |
ayoung | "Big fleas have little fleas, | 13:26 |
ayoung | Upon their backs to bite 'em, | 13:26 |
ayoung | And little fleas have lesser fleas, | 13:26 |
ayoung | and so, ad infinitum." | 13:26 |
samueldmq | :) | 13:26 |
samueldmq | ayoung, btw in the policy stuff ... do you plan to add the capability to have a policy per domain, irght ? | 13:27 |
samueldmq | this is so very important for reseller imo | 13:27 |
*** henrynash has quit IRC | 13:27 | |
*** emagana has joined #openstack-keystone | 13:31 | |
ayoung | samueldmq, not per domain, yet, but people keep asking for scoped policy. I just need to figure out how to distribute it. | 13:33 |
samueldmq | ayoung, a service endpoint would need to be able to know what service/domain(s) it is serving when fetching the policy files | 13:34 |
*** krykowski has quit IRC | 13:35 | |
*** krykowski_ has joined #openstack-keystone | 13:35 | |
ayoung | samueldmq, something like that...but how do you keep each token from triggering a fetch for a different policy... | 13:35 |
*** emagana has quit IRC | 13:35 | |
samueldmq | ayoung, well ... token scope always contain a domain_id (directly or via project) | 13:36 |
*** jsavak has joined #openstack-keystone | 13:36 | |
samueldmq | ayoung, but yes, there are tricky questions to care about .. and this is future work :) | 13:37 |
ayoung | yep | 13:37 |
ayoung | baby steps | 13:37 |
ayoung | or at least, walkin steps...and looking before we leap | 13:37 |
samueldmq | :) | 13:37 |
samueldmq | ayoung, btw, pm'd you | 13:37 |
openstackgerrit | Rodrigo Duarte proposed openstack/keystone-specs: Fix assertion examples https://review.openstack.org/185985 | 13:38 |
*** links has quit IRC | 13:41 | |
*** cloudm2 has joined #openstack-keystone | 13:42 | |
*** mabrams has quit IRC | 13:44 | |
*** mabrams has joined #openstack-keystone | 13:50 | |
*** gsilvis has quit IRC | 13:53 | |
*** gsilvis has joined #openstack-keystone | 13:54 | |
openstackgerrit | Nikita Konovalov proposed openstack/python-keystoneclient: Fix logging of binary contentent in request https://review.openstack.org/183514 | 13:57 |
*** Ephur has joined #openstack-keystone | 14:01 | |
*** chlong has joined #openstack-keystone | 14:05 | |
*** sigmavirus24_awa is now known as sigmavirus24 | 14:06 | |
*** csoukup has joined #openstack-keystone | 14:13 | |
mabrams | ayoung: where'z the upstream etherpad? thx | 14:13 |
*** rlt_ has joined #openstack-keystone | 14:14 | |
ayoung | mabrams, um... https://etherpad.openstack.org/p/testing-keystone-ldap-nondefault-domain was one... | 14:14 |
ayoung | which topic? | 14:14 |
*** tobe has quit IRC | 14:15 | |
mabrams | ayoung: nevermind ID-10T error | 14:15 |
ayoung | mabrams, I'm trying to get something to work with Rabbit. I think there is a way to see all events on the broker, if you run in debug mode. I think it will help test the notifications | 14:18 |
mabrams | ayoung: makes sense; will do that | 14:19 |
ayoung | mabrams, let me see if I can get it to work. It supposedly needs a web browser, but I don't really have one on the system I have installed,except for Lynx | 14:19 |
ayoung | mabrams, I did a yum install of rabbitmqadmin | 14:20 |
ayoung | sudo rabbitmq-plugins enable rabbitmq_management | 14:21 |
mabrams | ayoung: then set DEBUG mode? | 14:21 |
ayoung | sudo systemctl restart rabbitmq-server.service | 14:21 |
ayoung | I'm still learning this... | 14:21 |
*** timcline has joined #openstack-keystone | 14:21 | |
ayoung | you can then get the cli by running | 14:22 |
ayoung | wget http://10.10.10.40:15672/cli but with your local ipaddress | 14:22 |
mabrams | gotcha | 14:22 |
ayoung | https://www.rabbitmq.com/management-cli.html | 14:22 |
ayoung | mabrams, but I have not yet been able to see the keystone messages. Looking at the topic: | 14:23 |
mabrams | ayoung: are there otherwise meaningful msgs tho? | 14:23 |
ayoung | mabrams, I ran packstack, so I was able to find the password in the answers.txt file | 14:23 |
ayoung | python rabbitmqadmin -H 10.10.10.40 -P 15672 -u guest -p guest list exchanges | 14:23 |
ayoung | but maybe I should be using a different account? | 14:24 |
mabrams | prolly | 14:24 |
mabrams | seems guest is a guest | 14:24 |
ayoung | mabrams, but...the keystone.conf file also has guiest/guest | 14:24 |
*** kiran-r has quit IRC | 14:25 | |
ayoung | rabbit_userid=guest | 14:25 |
*** kiran-r has joined #openstack-keystone | 14:25 | |
ayoung | mabrams, I was following the code example here http://chrigl.de/blogentries/oslo-messaging-example | 14:26 |
ayoung | Where is stevemar when I need him? | 14:26 |
ayoung | mabrams, so I modified the recv code to try and listen to the keystone topic, but no messages | 14:27 |
ayoung | I should probably ask in an oslo room... | 14:27 |
*** HT_sergio has joined #openstack-keystone | 14:28 | |
mabrams | ayoung: https://etherpad.openstack.org/p/HMT-hierachical_multitenancy but dare i say tcms :-o formats it better | 14:28 |
ayoung | mabrams, yeah, but then it is behind a firewall. | 14:29 |
mabrams | ayoung: yup | 14:29 |
ayoung | mabrams, lets see if we can scare up someone that knows this better'n I do | 14:29 |
mabrams | ayoung: appreciate your troubles | 14:30 |
ayoung | htruta, raildo care to take a look at mabrams ' etherpad? He's working on a test plan for HMT? | 14:30 |
raildo | ayoung, sure, I'll take a look now :) | 14:31 |
ayoung | TYVM raildo | 14:31 |
htruta | ayoung: sure! | 14:31 |
htruta | might interest rodrigods as well | 14:31 |
*** kiran-r has quit IRC | 14:32 | |
ayoung | mabrams, there will bhe a little churn, as your focus thus far has been RHOS, but we need publically available distros for a public test like this. We shouold probably put links to the RDO repos we are suggesting for testing | 14:32 |
ayoung | let me see.... | 14:32 |
*** mestery has quit IRC | 14:33 | |
*** krykowski_ has quit IRC | 14:33 | |
*** mestery has joined #openstack-keystone | 14:34 | |
*** dims has quit IRC | 14:35 | |
*** krykowski has joined #openstack-keystone | 14:37 | |
openstackgerrit | Rodrigo Duarte proposed openstack/keystone-specs: Fix assertion examples https://review.openstack.org/185985 | 14:38 |
*** emagana has joined #openstack-keystone | 14:40 | |
*** ksavich has joined #openstack-keystone | 14:41 | |
*** hemnafk is now known as hemna | 14:50 | |
*** dims_ has joined #openstack-keystone | 14:55 | |
*** gokrokve has joined #openstack-keystone | 14:59 | |
*** timcline has quit IRC | 15:01 | |
*** timcline has joined #openstack-keystone | 15:02 | |
*** krykowski has quit IRC | 15:08 | |
*** e0ne is now known as e0ne_ | 15:13 | |
*** tobe has joined #openstack-keystone | 15:15 | |
*** tobe has quit IRC | 15:20 | |
*** e0ne_ is now known as e0ne | 15:22 | |
*** mabrams has quit IRC | 15:26 | |
*** gokrokve has quit IRC | 15:27 | |
*** gokrokve has joined #openstack-keystone | 15:28 | |
lbragstad | nkinder: is this something we still want to backport? https://review.openstack.org/#/c/182603/1 | 15:30 |
nkinder | lbragstad: yes, I think so | 15:31 |
*** setmason has joined #openstack-keystone | 15:31 | |
*** gokrokve has quit IRC | 15:32 | |
*** csoukup has quit IRC | 15:33 | |
*** browne has quit IRC | 15:39 | |
*** gokrokve has joined #openstack-keystone | 15:42 | |
*** lifeless_ is now known as lifeless | 15:53 | |
*** fhubik is now known as fhubik_afk | 15:57 | |
*** alanf-mc has joined #openstack-keystone | 15:59 | |
*** emagana has quit IRC | 16:00 | |
*** emagana has joined #openstack-keystone | 16:02 | |
*** jistr has quit IRC | 16:07 | |
*** alanf-mc_ has joined #openstack-keystone | 16:09 | |
*** stevemar has joined #openstack-keystone | 16:11 | |
*** ChanServ sets mode: +v stevemar | 16:11 | |
*** alanf-mc_ has quit IRC | 16:11 | |
*** alanf-mc has quit IRC | 16:11 | |
*** alanf-mc has joined #openstack-keystone | 16:12 | |
*** browne has joined #openstack-keystone | 16:17 | |
*** fhubik_afk is now known as fhubik | 16:18 | |
*** gokrokve has quit IRC | 16:19 | |
*** gokrokve has joined #openstack-keystone | 16:19 | |
*** _cjones_ has joined #openstack-keystone | 16:20 | |
*** gokrokve has quit IRC | 16:21 | |
*** vilobhmm has joined #openstack-keystone | 16:22 | |
openstackgerrit | Michael Simo proposed openstack/python-keystoneclient: Fixed grammatical errors in the V2 Client API doc https://review.openstack.org/186074 | 16:24 |
openstackgerrit | Rodrigo Duarte proposed openstack/python-keystoneclient: Fixe example code in Using Sessions page https://review.openstack.org/175135 | 16:30 |
*** BrAsS_mOnKeY has joined #openstack-keystone | 16:37 | |
openstackgerrit | Ian Cordasco proposed openstack/keystoneauth: Replace datetime calculations with utility functions https://review.openstack.org/186076 | 16:42 |
openstackgerrit | Michael Simo proposed openstack/python-keystoneclient: Fixed grammatical errors in the V2 Client API doc https://review.openstack.org/186074 | 16:46 |
*** claps has joined #openstack-keystone | 16:47 | |
*** timsim has joined #openstack-keystone | 16:47 | |
*** radez is now known as radez_g0n3 | 16:48 | |
claps | Super basic question: Can you have many users with different roles under a single project? | 16:48 |
*** ksavich has quit IRC | 16:48 | |
*** timcline has quit IRC | 16:50 | |
rodrigods | claps, yep... you can assign how many roles you want to a user in a project | 16:51 |
*** alanf-mc has quit IRC | 16:52 | |
raildo | claps, and the same for groups :) | 16:53 |
*** alanf-mc has joined #openstack-keystone | 16:53 | |
*** emagana has quit IRC | 16:53 | |
claps | Cool :) | 16:55 |
*** hemna is now known as hemnafk | 17:03 | |
*** tobe has joined #openstack-keystone | 17:04 | |
morganfainberg | lbragstad: http://lists.openstack.org/pipermail/openstack/2015-May/012885.html | 17:06 |
morganfainberg | lbragstad: ldap identity + fernet. | 17:06 |
morganfainberg | Looks like we have some issues. | 17:06 |
morganfainberg | Cc dolphm ^ | 17:06 |
morganfainberg | I'll take a gander at it post food if you haven't already. | 17:07 |
ayoung | morganfainberg, how does the ID source adffect the token based on FOrmat? | 17:07 |
ayoung | ValueError: badly formed hexadecimal UUID string | 17:07 |
morganfainberg | ayoung: because ldap hairs partial DN and we I think did the silly and assumed UUID. | 17:08 |
*** fhubik is now known as fhubik_afk | 17:08 | |
ayoung | "/usr/lib/python2.7/dist-packages/keystone/token/providers/fernet/token_formatters.py", line 416, in assemble | 17:08 |
ayoung | cls.convert_uuid_hex_to_bytes | 17:08 |
morganfainberg | This would also possibly break on mapped users with the sha256 | 17:08 |
ayoung | morganfainberg, sure looks like it | 17:08 |
morganfainberg | Yep. | 17:08 |
morganfainberg | I need food then I'm going to poke at this with a stick. | 17:09 |
morganfainberg | Unless I can get lbragstad or dolphm to. | 17:09 |
*** tobe has quit IRC | 17:09 | |
*** rlt_ has quit IRC | 17:10 | |
*** fhubik_afk is now known as fhubik | 17:12 | |
*** vilobhmm has quit IRC | 17:12 | |
*** vilobhmm has joined #openstack-keystone | 17:13 | |
*** alanf-mc has quit IRC | 17:14 | |
*** vilobhmm has quit IRC | 17:16 | |
*** alanf-mc has joined #openstack-keystone | 17:16 | |
*** e0ne is now known as e0ne_ | 17:16 | |
*** gokrokve has joined #openstack-keystone | 17:17 | |
*** zzzeek has joined #openstack-keystone | 17:18 | |
*** alanf-mc has quit IRC | 17:18 | |
lbragstad | morganfainberg: it's because we try to convert the uuid string to bytes to make the token smaller | 17:19 |
morganfainberg | lbragstad: yep. We can't make that assumption. | 17:20 |
lbragstad | morganfainberg: that should be a pretty easy fix | 17:20 |
morganfainberg | lbragstad: we have ids that are sha256 and partial dn. | 17:20 |
lbragstad | morganfainberg: we do the same thing with domain ids | 17:20 |
morganfainberg | Yeah. Just raising it up. | 17:20 |
*** e0ne_ is now known as e0ne | 17:20 | |
morganfainberg | Domain I assume you have a special case for "default"? | 17:20 |
*** alanf-mc has joined #openstack-keystone | 17:20 | |
lbragstad | https://github.com/openstack/keystone/blob/master/keystone/token/providers/fernet/token_formatters.py#L363-L367 | 17:21 |
morganfainberg | lbragstad: we'll need to fix this for liberty and backport to kilo. I can file the big and tackle post food or you can. | 17:21 |
morganfainberg | S/big/bug | 17:21 |
morganfainberg | Either way. Will check with you before i start working on it. | 17:22 |
*** fhubik has quit IRC | 17:23 | |
lbragstad | morganfainberg: we already have a method that should handle that case | 17:23 |
stevemar | lbragstad, gerrit powered agenda is alive | 17:23 |
*** claps has quit IRC | 17:23 | |
morganfainberg | lbragstad: cool. | 17:23 |
lbragstad | this guy https://github.com/openstack/keystone/blob/master/keystone/token/providers/fernet/token_formatters.py#L415 | 17:23 |
lbragstad | just needs to use attempt_convert_uuid_hex_to_bytes | 17:24 |
lbragstad | like we do here https://github.com/openstack/keystone/blob/master/keystone/token/providers/fernet/token_formatters.py#L509 | 17:24 |
*** fhubik has joined #openstack-keystone | 17:24 | |
mfisch | lbragstad morganfainberg next time you guys add a new key provider which may be never again, I'd vote for supporting multiple token backends | 17:24 |
*** e0ne has quit IRC | 17:25 | |
lbragstad | morganfainberg: patch http://cdn.pasteraw.com/2d2vvm3nvm1yilx6b2wpfhi1dzx2rza | 17:25 |
lbragstad | morganfainberg: that should retain the original username | 17:25 |
openstackgerrit | Ioram Schechtman Sette proposed openstack/keystone-specs: API spec for searching on the Policy database https://review.openstack.org/186093 | 17:26 |
lbragstad | stevemar: ++ (finally?) | 17:26 |
lbragstad | s/username/userid/ | 17:26 |
*** mrutkows has joined #openstack-keystone | 17:26 | |
stevemar | damn fernet, this is why we need real functional tests :( | 17:26 |
lbragstad | mfisch: so, you mean you'd want something that's smart enough to know the difference between the token formats and do stuff based on the token? | 17:27 |
mfisch | so please humor me, but wouldnt that be simple? | 17:27 |
mfisch | if not please say so | 17:27 |
mfisch | a UUID token and a fernet looks different enough to me | 17:27 |
mfisch | this way I dont have to take any outage to switch | 17:28 |
mfisch | Morgan already said no to me on this but he's not a friendly upper midwesterner like you lbragstad | 17:28 |
lbragstad | mfisch: I guess that would all depend on the deployment and how they want to handle each token format... it feels like there is a lot of room for edge cases... | 17:29 |
*** emagana has joined #openstack-keystone | 17:31 | |
mfisch | lbragstad: thats probably true, just something to think about | 17:31 |
lbragstad | mfisch: like if you wanted to migrate from uuid tokens to fernet tokens, and every time a user authenticates, how do you determine what kind of token to give them? | 17:32 |
mfisch | I've not done much thinking about the design, but if you have a list of token providers, you'd grant using the 1st entry but accept both | 17:33 |
mfisch | perhaps | 17:33 |
mfisch | we're switching regardless | 17:33 |
mfisch | but it would be nicer of a process | 17:33 |
lbragstad | mfisch: yeah, I could see that | 17:33 |
openstackgerrit | Ioram Schechtman Sette proposed openstack/keystone-specs: API spec for searching on the Policy database https://review.openstack.org/186093 | 17:33 |
samueldmq | morganfainberg, I was looking at https://wiki.openstack.org/wiki/CrossProjectLiaisons | 17:33 |
lbragstad | mfisch: mind if I ask how you're handling the migration currently? | 17:33 |
samueldmq | morganfainberg, and I think lhcheng could be set as Horizon/Keystone, if he is willing to | 17:34 |
bknudson | didn't we used to have pki and uuid runs in tempest? | 17:34 |
samueldmq | morganfainberg, in the 'Inter-project Liaisons' section | 17:34 |
bknudson | I guess we can't have fernet runs in tempest until devstack supports it | 17:34 |
morganfainberg | bknudson: correct. | 17:34 |
mfisch | lbragstad: emailing customers telling them there will be a small outage and combining it with a keystone to liberty upgrade | 17:34 |
bknudson | seems like we need to call fernet tokens unsupported until we get tests | 17:34 |
bknudson | although we don't have an ldap functional test either | 17:35 |
morganfainberg | bknudson: we wouldn't have caught this with devstack tests. | 17:35 |
mfisch | glad to be using 2 untested features! | 17:35 |
*** vhoward has left #openstack-keystone | 17:35 | |
lbragstad | mfisch: ok, so then they will just have to reauthenticate and all tokens prior to the migration will be invalid (because they were UUID), right? | 17:35 |
*** aix has quit IRC | 17:35 | |
mfisch | you guys talking about a fernet issue that I should know about? | 17:35 |
mfisch | lbragstad: yeah, we'll do it when we have low API usage. We have predictable customers | 17:35 |
*** vilobhmm has joined #openstack-keystone | 17:35 | |
lbragstad | http://lists.openstack.org/pipermail/openstack/2015-May/012885.html mfisch | 17:35 |
lbragstad | mfisch: gotcha | 17:36 |
morganfainberg | bknudson: so I'll be spending time today to get fernet in gate or lined up for it. | 17:36 |
samueldmq | bknudson, so we need devstack to be able to deploy keystone with ldap and with fernet tokens as well (with different flags, of course) ? | 17:36 |
mfisch | thanks for that pointer lbragstad | 17:36 |
samueldmq | morganfainberg, ++ | 17:36 |
bknudson | morganfainberg: do they want a full tempest run for it? I thought they wanted functional tests in keystone | 17:36 |
morganfainberg | The LDAP issue will be functional testing based. | 17:36 |
lbragstad | mfisch: are your user ids stored as something other than uuid? | 17:36 |
mfisch | lbragstad: no, but we kinda use LDAP | 17:37 |
morganfainberg | bknudson: I am planning on supporting it. I want fernet to be the default in devstack. | 17:37 |
mfisch | we store user details in mysql though | 17:37 |
morganfainberg | bknudson: this cycle. | 17:37 |
bknudson | ok, so we'd have uuid as functional tests then | 17:37 |
morganfainberg | bknudson: yes. | 17:37 |
bknudson | seems like we should have a set of common functional tests and reconfigure for uuid, pki, or fernet | 17:37 |
morganfainberg | bknudson: but work is required on the fernet front before that. And it's he same work. | 17:37 |
morganfainberg | So I'll do what I can to get that done today. | 17:38 |
morganfainberg | Or at least in Gerrit. | 17:38 |
lbragstad | mfisch: the issue is that when you use LDAP identity with user IDs that aren't UUID, the Fernet token provider/formatter doesn't know how to convert them to bytes (because they aren't uuid). | 17:38 |
*** vilobhmm has quit IRC | 17:38 | |
lbragstad | bknudson: I was working on that kind of consolidation | 17:38 |
mfisch | ah | 17:38 |
mfisch | I think we wont have that issue but I will test more | 17:39 |
lbragstad | bknudson: instead of having a bunch of "different" tests for the token providers that test the same situations | 17:39 |
bknudson | we're going to have a lot of functional test jobs | 17:39 |
*** hemnafk is now known as hemna | 17:39 | |
stevemar | bknudson, don't have to fun them all at once | 17:40 |
mfisch | lbragstad: I'm writing my own python code to manage keys inside yaml, have jenkins propose the rotate as a review and merge it on my schedule | 17:41 |
lbragstad | mfisch: nice | 17:42 |
mfisch | I thought generating a key would be some difficult black magic, its just 1 line | 17:42 |
lbragstad | mfisch: yeah, it's not too bad | 17:42 |
mfisch | lbragstad: I'll tell you from experience and trying to explain it that a diagram on key rotation would go a long way | 17:43 |
lbragstad | mfisch: I think we did have one floating around | 17:43 |
lbragstad | mfisch: https://docs.google.com/presentation/d/1T1ULahHFhgEcRIT6OsG0b24yjDAlV3nYS7x9d2yCtpM/edit?usp=sharing starting at slide 14 | 17:44 |
mfisch | lbragstad: this? https://s-media-cache-ak0.pinimg.com/originals/a4/87/96/a4879637ca54b1a16712db680a00f229.jpg | 17:44 |
lbragstad | exactly, something like that! | 17:44 |
openstackgerrit | Merged openstack/keystoneauth: Remove some cruft from the service catalog https://review.openstack.org/185805 | 17:44 |
mfisch | lbragstad: I hope to do a nice blog post about this to explain it once we're live | 17:45 |
mfisch | should be in dev today or tomorrow | 17:45 |
mfisch | depending on my battle with eyaml | 17:45 |
lbragstad | mfisch: that would be great, let me know how it goes! | 17:45 |
* mfisch saves that link for the blog | 17:45 | |
*** vilobhmm has joined #openstack-keystone | 17:48 | |
*** vilobhmm has quit IRC | 17:48 | |
lbragstad | mfisch: also have these incase they help http://lbragstad.com/?p=133 http://lbragstad.com/?p=156 http://lbragstad.com/?p=167 | 17:49 |
*** vilobhmm has joined #openstack-keystone | 17:49 | |
mfisch | oh yeah I've read those | 17:49 |
*** emagana has quit IRC | 17:50 | |
*** chlong has quit IRC | 17:53 | |
*** vilobhmm has quit IRC | 17:53 | |
*** timcline has joined #openstack-keystone | 17:57 | |
*** rushiagr_away is now known as rushiagr | 18:00 | |
rodrigods | lbragstad, nice posts - nice to read "real world" deployments issues/solutions | 18:01 |
lbragstad | rodrigods: not sure how real world they are ;) I just hoped they would help explain the concepts a little bit | 18:01 |
*** dims_ has quit IRC | 18:02 | |
*** dims_ has joined #openstack-keystone | 18:03 | |
*** lhcheng_ has joined #openstack-keystone | 18:03 | |
rodrigods | lbragstad, hehe see how fernet helps to solve distributed stuff is really cool | 18:03 |
lbragstad | rodrigods: thanks! | 18:03 |
*** fhubik has quit IRC | 18:04 | |
*** e0ne has joined #openstack-keystone | 18:06 | |
*** e0ne is now known as e0ne_ | 18:06 | |
*** alanf-mc has quit IRC | 18:06 | |
*** e0ne_ is now known as e0ne | 18:07 | |
*** alanf-mc has joined #openstack-keystone | 18:07 | |
*** lufix has joined #openstack-keystone | 18:10 | |
*** lufix has quit IRC | 18:11 | |
*** setmason has quit IRC | 18:11 | |
*** lufix has joined #openstack-keystone | 18:12 | |
*** setmason has joined #openstack-keystone | 18:13 | |
lbragstad | morganfainberg: do you have a bug open for that Fernet issue? | 18:20 |
lbragstad | morganfainberg: if not I can open one, but I didn't want to duplicate it if you already had one | 18:21 |
*** setmason has quit IRC | 18:21 | |
*** vilobhmm has joined #openstack-keystone | 18:23 | |
openstackgerrit | Merged openstack/keystone: Update dev setup requirements for Python 3.4 https://review.openstack.org/175216 | 18:24 |
morganfainberg | lbragstad: no bug yet. Saw that as I was walking to food. | 18:25 |
lbragstad | morganfainberg: I got it, no worries | 18:25 |
*** vilobhmm1 has joined #openstack-keystone | 18:27 | |
*** lufix has quit IRC | 18:29 | |
openstackgerrit | Lance Bragstad proposed openstack/keystone: Don't fail on converting user ids to bytes https://review.openstack.org/186120 | 18:30 |
*** vilobhmm has quit IRC | 18:30 | |
lbragstad | morganfainberg: https://bugs.launchpad.net/keystone/+bug/1459382 | 18:31 |
openstack | Launchpad bug 1459382 in Keystone "Fernet tokens can fail with LDAP identity backends" [Medium,In progress] - Assigned to Lance Bragstad (lbragstad) | 18:31 |
morganfainberg | lbragstad: I might classify that as high. As it breaks fernet in a common scenario. | 18:31 |
morganfainberg | lbragstad: otherwise ++ | 18:31 |
lbragstad | morganfainberg: go for it | 18:31 |
morganfainberg | common deployment scenario. | 18:31 |
*** setmason has joined #openstack-keystone | 18:31 | |
morganfainberg | Will do once I'm done with food and off mobile. | 18:32 |
bknudson | fernet's not supported so it should be low | 18:34 |
ayoung | morganfainberg, can you remove -2 from Henry's spec https://review.openstack.org/#/c/133855/ ? I think we each have a better understanding of what the other wants, and this has the potential to be very valuable | 18:34 |
*** setmason has quit IRC | 18:34 | |
lbragstad | bknudson: morganfainberg you guys can triage however you see fit, but the patch is up | 18:34 |
*** setmason has joined #openstack-keystone | 18:34 | |
morganfainberg | ayoung: re propose to backlog or Liberty then I'll un -2 | 18:35 |
ayoung | morganfainberg, can you un -2 first, so I can submit with same change request ID? | 18:35 |
ayoung | I don't think I can as is...or can I? | 18:35 |
ayoung | Maybe I can...I was thinking abandoned. OK | 18:35 |
morganfainberg | Yah. | 18:35 |
morganfainberg | Abandon needs restored first. -2 is just sticky. | 18:36 |
morganfainberg | lbragstad: I don't really care as long as it is fixed *and* back ported to kilo. | 18:36 |
openstackgerrit | ayoung proposed openstack/keystone-specs: Add support for domain specific roles. https://review.openstack.org/133855 | 18:36 |
morganfainberg | lbragstad: priority is not super important on that front. We are fixing it and making sure it's in place. | 18:36 |
ayoung | morganfainberg, done | 18:37 |
morganfainberg | ayoung: -2 removed. | 18:37 |
mfisch | lbragstad: curious about the permissions you chose for the key folder and the keys | 18:39 |
mfisch | lbragstad: wouldn't you want only root to be able to write new keys? | 18:39 |
lbragstad | mfisch: I think it's just meant to be whatever user is the keystone user | 18:39 |
*** nowen has joined #openstack-keystone | 18:40 | |
mfisch | if that user is compromised I guess you might have other issues. | 18:40 |
mfisch | like the config file | 18:40 |
lbragstad | exactly | 18:40 |
mfisch | looks like crytography isn't packaged :( | 18:41 |
nkinder | mfisch: packaged for what? | 18:41 |
*** lufix has joined #openstack-keystone | 18:41 | |
*** lufix has quit IRC | 18:41 | |
*** lufix has joined #openstack-keystone | 18:41 | |
mfisch | nkinder: ubuntu | 18:41 |
mfisch | not that I can find anyway | 18:41 |
nkinder | not sure. I know someone on my team packaged the 0.9.0 release recently for Fedora and is working on RHEL packages (not that it helps you) | 18:42 |
lbragstad | https://cryptography.io/en/latest/installation/#supported-platforms | 18:43 |
nowen | greetings - I'm wondering if it's possible to use mod-auth-radius for authentication? | 18:43 |
*** mattfarina has joined #openstack-keystone | 18:43 | |
lbragstad | mfisch: are you using ubuntu 14.04? | 18:43 |
mfisch | y | 18:43 |
nkinder | nowen: mod_auth_* should work if it sets REMOTE_USER | 18:44 |
nkinder | nowen: the difficulty is figuring out how you supply the credentials depending on the client application | 18:44 |
mfisch | looks like it's in U and beyond, but not in 14.04 | 18:44 |
lbragstad | mfisch: might be worth dropping in the #cryptography-dev channel? | 18:44 |
mfisch | I have upload rights if I can find the motivation to not just use pip | 18:45 |
*** lufix has quit IRC | 18:47 | |
*** vilobhmm has joined #openstack-keystone | 18:47 | |
*** vilobhmm1 has quit IRC | 18:48 | |
nowen | nkinder: ok - and I gather I have to uncomment external = keystone.auth.plugins.external.DefaultDomain for it to work? | 18:49 |
nkinder | nowen: yes | 18:50 |
morganfainberg | dstanek: looking forwrd to seeing keystone + Flask | 18:50 |
*** mattfarina has quit IRC | 18:50 | |
morganfainberg | dstanek: btw :) | 18:50 |
nkinder | nowen: something similar to this - https://github.com/nkinder/rdo-vm-factory/blob/master/rdo-kerberos-setup/vm-post-cloud-init-rdo.sh#L130-L132 | 18:51 |
nkinder | nowen: you should be able name it 'radius' instead of 'kerberos', then use DefaultDomain instead of KerberosDomain | 18:51 |
nowen | ok | 18:51 |
*** tobe has joined #openstack-keystone | 18:53 | |
*** gokrokve has quit IRC | 18:53 | |
*** mattfarina has joined #openstack-keystone | 18:54 | |
morganfainberg | ayoung: is there any reason why the identity manager shouldn't be doing the auto-id generation and why this lives at the controller level? | 18:55 |
morganfainberg | ayoung: it seems weird that the controller is responsible for business logic | 18:55 |
ayoung | morganfainberg, predates me | 18:55 |
ayoung | it was how termie wrote it | 18:55 |
morganfainberg | ayoung: s/identity/resource | 18:55 |
morganfainberg | ayoung: sure. i'm asking more from a "should we make an effort to push this down a layer" and try and keep business logic out of the controller? | 18:55 |
ayoung | I think we can safely bury it | 18:56 |
*** gokrokve has joined #openstack-keystone | 18:56 | |
ayoung | I know that I was dumb in ussing UUIDs for Revocation events | 18:56 |
morganfainberg | ayoung: it's not a lot of changes, just one of those "hmmmm" we should just do that type things | 18:56 |
ayoung | would have been better to autoinc those from the DB, but those are not exposed anyway | 18:56 |
morganfainberg | ayoung: we can still move to an autoinc, it's not a complex migration | 18:56 |
ayoung | seems to be a Backend specific logic, just shared to use uuids, I think | 18:57 |
ayoung | yah, just have not done so. Its on my list | 18:57 |
morganfainberg | breton: do we have a review to push it to liberty? if not can you make that happen so we can start getting alembic awesome in keystone | 18:58 |
*** tobe has quit IRC | 18:58 | |
morganfainberg | ayoung: yeah no rush there. i'm still poindering how to move the extension migration repos into the main migration repo. | 18:58 |
morganfainberg | ayoung: so we can finish that cleanup | 18:58 |
ayoung | morganfainberg, if the tables don't have constraints between them. it is cleaner to have them in separate repos | 18:59 |
*** e0ne has quit IRC | 18:59 | |
ayoung | make the migration number assignement easier to deconflict | 18:59 |
morganfainberg | ayoung: alembic gets weird with multiple repos in a single db afaik | 19:00 |
ayoung | and, it makes a path toward ID and Assignment into two services | 19:00 |
morganfainberg | ayoung: that last part is going to be the same work regardless | 19:00 |
morganfainberg | ayoung: since those two are already merged | 19:00 |
morganfainberg | i'm thinking revocation events, endpoint filtering, etc | 19:00 |
ayoung | true, but that was my rationale for putting extensions in their own repos in the first place | 19:01 |
morganfainberg | ayoung: right and since we're doing away with in-tree extensions | 19:01 |
*** rushiagr is now known as rushiagr_away | 19:01 | |
*** spandhe has joined #openstack-keystone | 19:01 | |
ayoung | morganfainberg, If I were starting from scratch, I would put each of the backends in their own migrate repo | 19:01 |
morganfainberg | ayoung: having them always migrated w/o needing the extra shim to lookup/call the right repo migration is probably better | 19:01 |
morganfainberg | ayoung: i'd put them in their own database. | 19:02 |
ayoung | I think that was what temrie had in mind originally, he just only had one backend in sql | 19:02 |
morganfainberg | not just separate repos/tables | 19:02 |
ayoung | yep | 19:02 |
ayoung | in order to do that, we need to be able to have separate DB connectison, which we need for other features, too | 19:02 |
morganfainberg | now, i don't think the former extensions belong in the corner like they are | 19:03 |
ayoung | I'd like to use the same approach as domain specific backend for that, but call it named resources, and a DB connection would be a named resource. should tie in with dstanek 's DI cleanup | 19:03 |
ayoung | agreed | 19:03 |
morganfainberg | the endpoint filtering belongs in the same place catalog does | 19:03 |
ayoung | morganfainberg, assignemnt, oauth, and trusts all need to be in the same DB | 19:04 |
morganfainberg | revocation events belong in the same place token-things do. | 19:04 |
ayoung | no | 19:04 |
ayoung | tokens and revoke actually should be 2 DBs | 19:04 |
ayoung | the life cycle of them are different | 19:04 |
morganfainberg | ok well let me just say we shouldn't have bad shim code in place just to remember to migration another repo. | 19:05 |
ayoung | agreed | 19:05 |
morganfainberg | right now that is what we have | 19:05 |
morganfainberg | i'd rather see (until oslo.db gets better) everything always migrated from a single source. | 19:05 |
morganfainberg | because i don't know when the extra connector work will be done | 19:05 |
ayoung | but that is cuz our CLI only assumes there is on repo. db_sync should migrate all active repos, not \"the real one and oh by the way these others" | 19:05 |
morganfainberg | if that can be done soon, great separate things better | 19:05 |
ayoung | and db_version should be version by module | 19:05 |
ayoung | morganfainberg, why not leave it until we get an alembic solution in place, then, and do it as part of the alembic work, instead of doing it twice? | 19:06 |
morganfainberg | ayoung: i was thinking we would do the collapse to 1 repo with alembic landing | 19:06 |
ayoung | I see no reason to waste cycles on SQL-A imigrations f we are not going to stick with them long term | 19:06 |
ayoung | Is anyone taking on alembic? | 19:07 |
morganfainberg | ayoung: ^^ i was just asking breton about it | 19:07 |
morganfainberg | ayoung: which lead me to this convo :) | 19:07 |
morganfainberg | ayoung: i wouldn't merge with SQL-A-Migrate. | 19:07 |
morganfainberg | not worth the effort unless alembic is going to be late M-cycle or beyond | 19:08 |
gabriel-bezerra | ayoung: What is the link to the spec you assigned me and David Chadwick on Trello? | 19:08 |
ayoung | gabriel-bezerra, https://trello.com/b/260v4Gs7/dynamic-policy | 19:08 |
gabriel-bezerra | I can see many database things here: https://review.openstack.org/#/q/status:open+project:openstack/keystone-specs+branch:master+topic:dynamic-policy,n,z | 19:08 |
ayoung | gabriel-bezerra, miscliecked, was supposed to iorem | 19:09 |
gabriel-bezerra | plus this one, that is in another topic: https://review.openstack.org/#/c/133814 | 19:09 |
gabriel-bezerra | ayoung: ok | 19:09 |
ayoung | gabriel-bezerra, that is not assignment, BTW I'm just trying to track who is working on what, General guidance, not "you are on the hook" | 19:11 |
ayoung | at least, not there | 19:11 |
*** mattfarina has quit IRC | 19:12 | |
morganfainberg | ayoung: is there a reason dynamic policy board on trello is private? | 19:13 |
* morganfainberg would think it should be public. | 19:13 | |
morganfainberg | but thats just a open development view. | 19:13 |
HT_sergio | I'm fairly sure I found a bug in keystonemiddleware.auth_token. Who can talk to about this ? | 19:15 |
ayoung | morganfainberg, Just don't know how it would scale. I can try to make it public | 19:15 |
morganfainberg | ayoung: no worries just wasn't sure about it | 19:15 |
morganfainberg | HT_sergio: you can chat here. whats up? | 19:15 |
ayoung | morganfainberg, I am OK with anyone reading it, bu I only want people assigned to make changes. | 19:15 |
morganfainberg | ayoung: i only noticed it was private when i clicked on the link above ^^ | 19:16 |
ayoung | morganfainberg, I just made it public. According to the docs that means that only people added can make cahnges. but anyone can read it | 19:16 |
morganfainberg | cool | 19:16 |
*** gyee has joined #openstack-keystone | 19:16 | |
*** ChanServ sets mode: +v gyee | 19:16 | |
morganfainberg | ayoung: yeah much better | 19:17 |
HT_sergio | morganfainberg: I'm storing tokens in memcache. When I restart memcache the tokens are lost, but keystonemiddleware seems to be caching them internally which is causing nova/cinder/glance to fail pretty hard | 19:17 |
HT_sergio | *I'm storing = keystone is storing | 19:17 |
ayoung | HT_sergio, yep | 19:17 |
ayoung | its a feature | 19:17 |
morganfainberg | HT_sergio: there is an internal cache for validated tokens for middleware | 19:17 |
morganfainberg | HT_sergio: you can disable that cache, use (similarly) a memcache back | 19:18 |
morganfainberg | HT_sergio: (there was an or between those two statements) | 19:18 |
morganfainberg | but yes the endpoints to cache by default (300s) for a validated token | 19:18 |
HT_sergio | it's the nova/cinder/glance service's token (not the user token) that's being cached. When keystone rejects it, keystonemiddleware isn't asking for another token, it's just failing | 19:18 |
morganfainberg | HT_sergio: which version of openstack are you running? | 19:19 |
HT_sergio | how can this cache be disabled? I wasn't able to find such an option | 19:19 |
HT_sergio | Juno | 19:19 |
morganfainberg | HT_sergio: keystonemiddleware should be re-requesting tokens for the service user when it fails. | 19:19 |
HT_sergio | recently updated from Icehouse | 19:19 |
HT_sergio | it doesn't seem to be re-requesting tokens. I've confirmed this in the keystone logs (I see it rejecting the same token over and over, and it's not the user's token) | 19:20 |
morganfainberg | ayoung: and this is yet another reason i greatly lookforward to fernet tokens being the default. | 19:20 |
morganfainberg | HT_sergio: UUID tokens or PKI? | 19:20 |
HT_sergio | UUID | 19:20 |
ayoung | morganfainberg, this is not going to be fixed by Fernet. A cached expired token should act the same way | 19:21 |
ayoung | " When keystone rejects it, keystonemiddleware isn't asking for another token" | 19:21 |
morganfainberg | ayoung: no this is memcache being restarted and dumping all active tokens | 19:21 |
ayoung | Nope | 19:21 |
ayoung | that should be a viable thing to do | 19:21 |
morganfainberg | ayoung: yes. not the user token. | 19:21 |
ayoung | keystone middleware needs to request a new token | 19:21 |
morganfainberg | ayoung: but the whole not-dumping everything on a service restart would make this less icky. | 19:22 |
ayoung | I suspect it is the service token | 19:22 |
ayoung | it would just hiodc the bug | 19:22 |
morganfainberg | ayoung: i'm looking at ksm now to see what is going on | 19:22 |
ayoung | we have it out in daylight. SQUASH IT! | 19:22 |
HT_sergio | ayoung: you've seen this before ? | 19:22 |
ayoung | HT_sergio, nah, but I can guess at what is going on | 19:23 |
HT_sergio | it is the nova (for example) token that's being rejected | 19:23 |
ayoung | right | 19:23 |
morganfainberg | HT_sergio: haven't seen this actually occur since sometime around grizzly | 19:23 |
ayoung | He's runnning essex | 19:23 |
* ayoung ducks | 19:23 | |
HT_sergio | morganfainberg: I didn't see this in Icehouse either | 19:23 |
morganfainberg | ayoung: hah | 19:23 |
HT_sergio | only since switching to juno | 19:23 |
morganfainberg | HT_sergio: so nova gets the token the first time (on start) but doesn't refresh | 19:24 |
ayoung | HT_sergio, In juno, that code lives in Keystoneclient still (I think) | 19:24 |
morganfainberg | when you dump active keystone tokens by restarting memcache | 19:24 |
morganfainberg | ayoung: nope, juno moved to ksm package | 19:24 |
ayoung | morganfainberg, wasn't it just a link over...ah it was the other way | 19:24 |
ayoung | KSC to KSM | 19:24 |
HT_sergio | it's Keystone checking the tokens. I can see the rejection in KS's log | 19:25 |
morganfainberg | ayoung: never linked either, circular deps | 19:25 |
morganfainberg | ayoung: due to cms and subsequently session | 19:25 |
morganfainberg | HT_sergio: in your nova past.ini you're referencing the keystonemiddleware package for auth_token not keystoneclient.middleware correct? | 19:25 |
* morganfainberg is just making sure we're chasing the right code. | 19:26 | |
* HT_sergio checking | 19:26 | |
HT_sergio | morganfainberg: [filter:authtoken] paste.filter_factory = keystonemiddleware.auth_token:filter_factory | 19:27 |
morganfainberg | HT_sergio: great. | 19:27 |
morganfainberg | HT_sergio: and which version of keystonemiddleware are you using (should be... 1.3 something? or 1.2 something?) | 19:28 |
*** jsavak has quit IRC | 19:28 | |
*** jsavak has joined #openstack-keystone | 19:28 | |
morganfainberg | assuming ubuntu dpkg can tell you, on RDO you can search for the rpm. | 19:28 |
HT_sergio | hmm, it's 1.0.0 | 19:28 |
morganfainberg | ok | 19:28 |
HT_sergio | python-keystonemiddleware 1.0.0-1~cloud0 | 19:28 |
morganfainberg | cool that's fine | 19:29 |
openstackgerrit | Fernando Diaz proposed openstack/python-keystoneclient: WIP - Add openid connect client support https://review.openstack.org/134700 | 19:29 |
rodrigods | morganfainberg, ping... need to ask you about the possibility of backporting some patches | 19:29 |
*** mrutkows has quit IRC | 19:30 | |
morganfainberg | rodrigods: sure. also bknudson and dolphm are good for stable questions as well. | 19:30 |
rodrigods | morganfainberg, yep... bknudson is already ok with them | 19:30 |
*** timcline has quit IRC | 19:30 | |
rodrigods | morganfainberg, https://review.openstack.org/#/q/status:open+project:openstack/keystone+branch:stable/kilo+topic:bug/1442787,n,z | 19:30 |
HT_sergio | morganfainberg: I'll msg you later about my issue. I still don't know how I can fix it | 19:31 |
*** timcline has joined #openstack-keystone | 19:31 | |
*** mattfarina has joined #openstack-keystone | 19:31 | |
morganfainberg | HT_sergio: i'm looking right now at it :) | 19:31 |
HT_sergio | oh ok thanks :) | 19:31 |
morganfainberg | tying to see if there is a fix that was applied between 1.0.0 and sometime later | 19:31 |
morganfainberg | i remember something like this happening at one point | 19:31 |
morganfainberg | HT_sergio: in the log do you see: 'Keystone rejected admin token, resetting' | 19:32 |
morganfainberg | HT_sergio: (this would be in nova log it looks like) | 19:33 |
HT_sergio | no | 19:33 |
HT_sergio | let me paste the log from KS | 19:33 |
HT_sergio | RBAC: Invalid token | 19:34 |
*** mattfarina has quit IRC | 19:34 | |
HT_sergio | I added a bit more, so it says why the token was rejected: | 19:34 |
HT_sergio | RBAC: Invalid token (Could not find token: 871a9a6c11e24b6e896a30a28d69dd24) | 19:34 |
morganfainberg | HT_sergio: right, on the nova side you should (provided you have logging turned up to WARN for auth_token) see 'Keystone rejected admin token, resetting' | 19:35 |
HT_sergio | WARNING keystonemiddleware.auth_token [-] Authorization failed for token | 19:35 |
morganfainberg | HT_sergio: which is the log line we emit when the admin / service token for the nova user (what we use to validate) is rejected. | 19:35 |
HT_sergio | morganfainberg: it doesn't say admin token | 19:36 |
HT_sergio | morganfainberg: was that always the log statement, even way back in 1.0.0 ? | 19:36 |
morganfainberg | HT_sergio: yeah i'm looking at the 1.0.0 code in git right now | 19:36 |
morganfainberg | https://github.com/openstack/keystonemiddleware/blob/1.0.0/keystonemiddleware/auth_token.py#L1120-L1132 | 19:37 |
morganfainberg | oooh i wonder. | 19:37 |
morganfainberg | ayoung, dstanek, dolphm: did Juno have that fun bug where X-AUTH-TOKEN and X-SUBJECT-TOKEN returned the same bad status response? | 19:37 |
morganfainberg | or was that icehouse? | 19:37 |
ayoung | morganfainberg, look in the bug tracker, I forget | 19:38 |
morganfainberg | ayoung: i'm going to go look at some commits in github first. searching LP is a nightmare. | 19:38 |
morganfainberg | ayoung: i think that was icehouse | 19:40 |
*** csoukup has joined #openstack-keystone | 19:40 | |
*** timcline has quit IRC | 19:42 | |
*** timcline has joined #openstack-keystone | 19:42 | |
morganfainberg | HT_sergio: So this looks like to me that the user's token is being rejected [based on the logs] not the "nova" token. | 19:43 |
morganfainberg | HT_sergio: just from what you've shown and what i can see in the code | 19:43 |
morganfainberg | HT_sergio: so let me ask one more question | 19:43 |
morganfainberg | HT_sergio: and i'll keep looking | 19:44 |
HT_sergio | morganfainberg: I thought this too at first. But I'm seeing that nova rejects *all* tokens after restarting memcache. Here's what I did: | 19:44 |
morganfainberg | HT_sergio: ok let me see what your steps are and i'll poke at this a bit more | 19:44 |
HT_sergio | `nova --debug list` works. I see the token used in the debug output. Restart memcached and try the command again. I see the new token in the debug log, but keystone rejects it. In the keystone log I see it rejecting a different token (not the one from CLI debug output) | 19:45 |
HT_sergio | ** I see the new token in the debug output | 19:45 |
HT_sergio | because each CLI command uses a new token | 19:45 |
HT_sergio | each time I try `nova --debug list` I see it using a different token, but I see the keystone logs rejecting the same token over and over | 19:46 |
HT_sergio | I can repeat these steps now and pastebin the output if you want | 19:47 |
morganfainberg | hm. what status is keystone returning on the rejected token(s)? | 19:48 |
morganfainberg | 404 or 401? | 19:48 |
HT_sergio | let me put into debug and find out | 19:49 |
morganfainberg | sounds good | 19:49 |
gabriel-bezerra | ayoung: no worries. (about the assigning tasks on trello issue) | 19:49 |
HT_sergio | morganfainberg: yup it is indeed 401 | 19:50 |
HT_sergio | the CLI command output was saying 401 as well | 19:51 |
*** Aless has joined #openstack-keystone | 19:51 | |
morganfainberg | the CLI to nova part i expected that | 19:51 |
HT_sergio | there's 1 more funny thing that might shed some light on this | 19:51 |
*** timcline has quit IRC | 19:51 | |
morganfainberg | if keystone is sending a 401 back to nova (auth_token middleware) and we're not getting a new token some logic is being weeeeeeiiirrrrddd | 19:51 |
morganfainberg | since the code looks to be doing 100% the right thing | 19:52 |
Aless | Hello There I'm curious, is the Domain Approach feasible to divide Admin/Service Users from the "Regular" LDAP Users? | 19:52 |
*** timcline has joined #openstack-keystone | 19:52 | |
HT_sergio | morganfainberg: it should be following the code path from the link you sent me | 19:52 |
Aless | Or would i rather use something like a hybrid backend for that? | 19:52 |
HT_sergio | morganfainberg: I'll see if I can confirm that | 19:52 |
morganfainberg | HT_sergio: please do. I don | 19:52 |
morganfainberg | t see where the bug is directly, and I clearly haven't experienced it myself. | 19:53 |
HT_sergio | morganfainberg: The Nova should use keystonemiddleware too, right ? | 19:55 |
morganfainberg | ok so nova uses keystonemiddleware | 19:55 |
morganfainberg | HT_sergio: keystone uses a special bit of middleware because keystonemiddleware doesn't work inside keystone | 19:55 |
morganfainberg | it needs to make http requests to keystone.. | 19:55 |
*** gokrokve has quit IRC | 19:55 | |
morganfainberg | separate code paths | 19:55 |
morganfainberg | HT_sergio: so it is [NOVA (keystonemiddleware)] ------> [Keystone (keystone's special token validation middleware: keystone.middleware.AuthContextMiddleware)] | 19:56 |
morganfainberg | what runs inside keystone has the ability to directly query/validate with the internals of keystone. what runs in nova uses the REST calls to validate | 19:57 |
morganfainberg | ooh | 19:58 |
morganfainberg | HT_sergio: so. really really really dumb question | 19:58 |
morganfainberg | HT_sergio: when everything is broken like this | 19:58 |
HT_sergio | morganfainberg: yes keystone CLI commands still work. Is that the question ? | 19:58 |
morganfainberg | ah nope that wasn't the question, but it answered my question | 19:58 |
morganfainberg | HT_sergio: darn. | 19:59 |
morganfainberg | HT_sergio: this is a weird one. | 19:59 |
HT_sergio | morganfainberg: Right. So i expected the nova CLI stack trace to include middleware. It doesn't: http://paste.openstack.org/show/240571/ | 19:59 |
morganfainberg | HT_sergio: you'd need to look at nova's logs not what the client outputs | 19:59 |
HT_sergio | ok, nvm that then :) | 20:00 |
*** mestery_ has joined #openstack-keystone | 20:00 | |
morganfainberg | HT_sergio: i havr a call i need to hop on. | 20:00 |
HT_sergio | morganfainberg: Ok thanks for everything so far! | 20:00 |
morganfainberg | HT_sergio: i'll standup a devstack with juno once i'm done and see what happens | 20:00 |
morganfainberg | HT_sergio: i know where to look and the rough duplication steps. i'll be back in ~60-90mins. | 20:00 |
*** Rockyg has joined #openstack-keystone | 20:01 | |
*** mestery has quit IRC | 20:03 | |
*** g2` has quit IRC | 20:09 | |
gabriel-bezerra | Aless: what do you mean by Domain Approach? | 20:19 |
Aless | gabriel-bezerra: https://wiki.openstack.org/wiki/Domains | 20:20 |
gabriel-bezerra | Aless: a feasible way to do it is to have your regular users in a domain backed by a domain-specific ldap. Then you admin/service users can be in the default (or other) domain. | 20:20 |
gabriel-bezerra | s/Then you/Then your/ | 20:20 |
Aless | gabriel-bezerra: Does this have any limits on how the service in the default domains are not able to "do" stuff in the regular users domain? | 20:22 |
Aless | gabriel-bezerra: What I miss is some sort of list of implications. | 20:22 |
gabriel-bezerra | Aless: I don't think the services will be limited with the default policy-file samples. | 20:24 |
gabriel-bezerra | ayoung: ^ | 20:25 |
gabriel-bezerra | samueldmq rodrigods ^ | 20:25 |
Aless | gabriel-bezerra: OK, so is this something that others are doing as well? I want follow the happy path as close as possible. :-) | 20:25 |
ayoung | yes Aless many have trod this happy path | 20:26 |
Aless | OK great, thanks guys! | 20:26 |
gabriel-bezerra | you're welcome | 20:27 |
Aless | So, am I assuming right that this is sort of the answer to all this hybrid approach requests? | 20:31 |
Aless | https://github.com/SUSE-Cloud/keystone-hybrid-backend/tree/devel and the likes | 20:32 |
gabriel-bezerra | Aless: this is AN answer that seems to be an easy way to do it. You can kind of reach the same goal with federation, for instance, but it will be a lot more complex if you don't already have a SAML Identity Provider. | 20:37 |
*** tobe has joined #openstack-keystone | 20:42 | |
*** stevemar has quit IRC | 20:43 | |
ayoung | dstanek, our unit tests take way too long. | 20:45 |
dstanek | ayoung: haha, yes they do | 20:45 |
Aless | gabriel-bezerra: another alternative would be the use of REMOTE_USER header and have the frontend to use multiple backends - but i'm not sure whether this is being broadly used, based on online-readings | 20:45 |
ayoung | dstanek, I remember when running them was not counterproductive. How do we get back to that state? | 20:45 |
*** dsirrine has joined #openstack-keystone | 20:45 | |
dstanek | they are much faster now than what they were when i started working on keystone - we need to trim all of the shared setup as a first step | 20:46 |
*** tobe has quit IRC | 20:46 | |
gabriel-bezerra | Aless: I've never tried to do it in such way. I don't know about its adoption in production. | 20:50 |
Aless | gabriel-bezerra: Alright I will start off with seperate Domains, thanks for the quick support again. | 21:04 |
*** Aless has quit IRC | 21:04 | |
*** alanf-mc_ has joined #openstack-keystone | 21:05 | |
HT_sergio | Aless: if you have questions about the hybrid driver, feel free to ask me | 21:05 |
*** jsavak has quit IRC | 21:06 | |
morganfainberg | HT_sergio: I'm back and standing up a devstack so I can do some direct reproduction of your case with Juno | 21:07 |
HT_sergio | morganfainberg: cool thanks ! | 21:08 |
*** alanf-mc has quit IRC | 21:08 | |
HT_sergio | I've done a bit more poking around in the mean time | 21:08 |
morganfainberg | HT_sergio: I will be using the raw git checkouts vs. a distribution since i can roll commits forwards and backwards as needed | 21:08 |
morganfainberg | HT_sergio: i might need to snag a copy of your auth_token section from nova config (omitting passwords of course), if this isn't straightforward to duplicate | 21:09 |
HT_sergio | morganfainberg: ok | 21:09 |
morganfainberg | HT_sergio: i need to grab lunch soon and more coffee, but I'll do that once I kick off the actual devstack install | 21:09 |
morganfainberg | HT_sergio: you using 12.04? 14.04? some suse distro? Fedora? | 21:10 |
HT_sergio | morganfainberg: a little more info: the log msg 'Keystone rejected admin token, resetting' was not being printed for some reason, but it is going down that code path ! | 21:10 |
HT_sergio | 14.04 | 21:10 |
morganfainberg | ok great | 21:10 |
morganfainberg | HT_sergio: just making sure i'm setting up similar environments | 21:10 |
*** alanf-mc_ has quit IRC | 21:10 | |
HT_sergio | it looks like keystonemiddleware is somehow logging at WARN level, but the rest of the log is at INFO | 21:10 |
morganfainberg | HT_sergio: hopefully it's something trivial to fix (though i know how frustrating it gets) | 21:10 |
HT_sergio | I hope so too. | 21:11 |
*** samueldmq has quit IRC | 21:11 | |
HT_sergio | ideally it's just something silly I've done wrong :) | 21:11 |
morganfainberg | HT_sergio: auth_token is by design meant to log a bit higher for certain cases. | 21:11 |
morganfainberg | HT_sergio: but we need to downgrade some of those messages a bit too imo | 21:11 |
morganfainberg | too verbose in some ways | 21:11 |
*** mestery_ is now known as mestery | 21:12 | |
*** alanf-mc has joined #openstack-keystone | 21:12 | |
* morganfainberg sees a mestery and suddenly doesn't remember the important network-y question he had. | 21:12 | |
mestery | morganfainberg: lol | 21:12 |
mestery | :) | 21:13 |
morganfainberg | mestery: so... $network_question? what do you think? | 21:13 |
morganfainberg | mestery :P | 21:13 |
mestery | rofl | 21:13 |
* mestery hand waves, muttering SDN | 21:13 | |
*** lsmola_ has quit IRC | 21:13 | |
morganfainberg | mestery: just the kind of response I'd expect! | 21:14 |
mestery | lol | 21:14 |
* morganfainberg handwaves and mutters identity, and access... SDNy things phaw | 21:14 | |
morganfainberg | ok. that was silly | 21:15 |
HT_sergio | morganfainberg: On this line: https://github.com/openstack/keystonemiddleware/blob/1.0.0/keystonemiddleware/auth_token.py#L1122 | 21:18 |
HT_sergio | I printed self.admin_token before and after. I found that it wasn't defined before ! | 21:18 |
HT_sergio | that seems wrong to me ? | 21:18 |
morganfainberg | thats a bit odd. | 21:19 |
*** alanf-mc_ has joined #openstack-keystone | 21:20 | |
morganfainberg | let me finish up the setup here | 21:20 |
morganfainberg | and i'll poke around a bit and see if i can duplicate the issue | 21:20 |
HT_sergio | ah I think I found the issue! | 21:20 |
morganfainberg | ? | 21:20 |
HT_sergio | there's self.admin_token and self._admin_token | 21:20 |
HT_sergio | let me confirm this is the problem | 21:20 |
*** alanf-mc has quit IRC | 21:20 | |
morganfainberg | hmmmm. | 21:22 |
morganfainberg | interesting | 21:22 |
morganfainberg | yep | 21:22 |
HT_sergio | renaming it to self._admin_token seems to have fixed it | 21:22 |
morganfainberg | looks like we missed the _ on line: https://github.com/openstack/keystonemiddleware/blob/1.0.0/keystonemiddleware/auth_token.py#L1122 | 21:22 |
HT_sergio | WOOHOO! | 21:23 |
HT_sergio | I think this is my first major bugfix in an openstack project :D | 21:23 |
morganfainberg | HT_sergio: can you file a bug for me on launchpad against this? let me check the more modern versions as well. | 21:23 |
morganfainberg | hopefully this is not too widespread | 21:23 |
HT_sergio | morganfainberg: yes please do. I'll make the bug | 21:23 |
morganfainberg | ah | 21:24 |
morganfainberg | so | 21:24 |
boris-42 | morganfainberg: hey there | 21:24 |
boris-42 | morganfainberg: I will update rally jobs during this week | 21:24 |
morganfainberg | boris-42: thanks | 21:24 |
boris-42 | morganfainberg: I didn't forgot=) just too many things to do | 21:24 |
morganfainberg | HT_sergio: this might already be fixed | 21:24 |
morganfainberg | boris-42: yes i know. post summit :) | 21:25 |
boris-42 | forget* | 21:25 |
boris-42 | morganfainberg: crazy period of life each time=) | 21:25 |
mfisch | its getting all fernetty in my dev environment! | 21:25 |
morganfainberg | HT_sergio: the stable/juno branch is a good deal further forward than the 1.0.0 release | 21:25 |
morganfainberg | HT_sergio: can I have you try duplicating this with the code from https://github.com/openstack/keystonemiddleware/tree/stable/juno | 21:26 |
HT_sergio | sure | 21:26 |
HT_sergio | it'll take me a few minutes | 21:27 |
morganfainberg | HT_sergio: it might already be fixed and the cloud archive you're installing from just doesn't have the updated code. | 21:27 |
morganfainberg | it even looks like this might be fixed in 1.1.0 | 21:28 |
morganfainberg | HT_sergio: (i like fixes I can point people at when they're already done) | 21:28 |
morganfainberg | mfisch: just wait until you also have a flask for all the fernet | 21:29 |
morganfainberg | mfisch: /me stops making bad jokes. | 21:29 |
morganfainberg | (thats a lie, i wont stop making bad jokes) | 21:29 |
mfisch | just rolled it to my hwdev | 21:29 |
mfisch | okay so far | 21:29 |
*** samueldmq has joined #openstack-keystone | 21:30 | |
mfisch | morganfainberg: do I need to bounce the openstack services? | 21:31 |
HT_sergio | morganfainberg: it does look like 1.1.0 has the fix | 21:31 |
HT_sergio | should I even bother testing latest ? | 21:31 |
openstackgerrit | ayoung proposed openstack/keystone: IAM Models https://review.openstack.org/184651 | 21:31 |
morganfainberg | HT_sergio: the stable/juno branch is officially the supported branch for juno releases | 21:31 |
morganfainberg | HT_sergio: you don't need to test it, but you might want to use it (for security backports etc) | 21:32 |
mfisch | wow, services do NOT like us swithcing token providers! reboot all the things! | 21:33 |
morganfainberg | mfisch: the services should just fail with their service token and have to re-request | 21:34 |
*** pece has quit IRC | 21:34 | |
morganfainberg | mfisch: *should* | 21:34 |
mfisch | I had to bounce them | 21:35 |
mfisch | I waited 3-4 mins | 21:35 |
morganfainberg | hm. | 21:35 |
HT_sergio | mfisch: maybe you ran into exactly the problem I'm here about ? | 21:35 |
morganfainberg | i'll need to poke at that, it should be easier. | 21:35 |
HT_sergio | which, for me, boiled down to: I'm using keystonemiddleware v1.0.0 | 21:36 |
mfisch | we're all up | 21:36 |
mfisch | rebooted all services | 21:36 |
mfisch | they dont like the switchover | 21:36 |
mfisch | morganfainberg: how long should we have waited? | 21:37 |
morganfainberg | mfisch: we should explore that as an option. it should be perfectly fine to swap the token provider and not need to restart everything | 21:37 |
ayoung | morganfainberg, ^^ is the patch formerly known as access_info | 21:37 |
morganfainberg | mfisch: it should have been "on the next request that hits auth_token middleware" | 21:38 |
morganfainberg | mfisch: no specific timeframe. | 21:38 |
morganfainberg | mfisch: but immediate. | 21:38 |
mfisch | we were up to 25 icinga criticals before I bounced services | 21:38 |
morganfainberg | mfisch: juno services? | 21:39 |
mfisch | yes | 21:39 |
morganfainberg | kilo keystone? | 21:39 |
mfisch | yes | 21:39 |
morganfainberg | and which version of middleware? | 21:39 |
mfisch | we can repro this again tomorrow in my other environment | 21:39 |
mfisch | looking | 21:39 |
morganfainberg | you really might have just hit that same bug as HT_sergio | 21:39 |
morganfainberg | if you are running 1.0.0 | 21:40 |
morganfainberg | it's borked | 21:40 |
mfisch | keystonemiddleware (1.0.0) | 21:40 |
mfisch | boom | 21:40 |
*** ducttape_ has joined #openstack-keystone | 21:40 | |
morganfainberg | move to the stable/juno branch (whatever the last tag there is) | 21:40 |
mfisch | welcome eric | 21:40 |
morganfainberg | i think that is a 1.3.x but not 100% sure | 21:40 |
mfisch | morganfainberg: we're doing a K upgrade soon, should we just wait? | 21:40 |
morganfainberg | mfisch: well, this is an issue you probably want to move to at least 1.1.0 | 21:41 |
morganfainberg | to prevent things being just broken for a real juno deploy | 21:41 |
mfisch | morganfainberg: is it an issue even after the restart you mean? | 21:41 |
morganfainberg | mfisch: it will continue to be an issue as tokens for the service users expire | 21:41 |
*** gordc has quit IRC | 21:41 | |
*** kfox1111 has joined #openstack-keystone | 21:41 | |
kfox1111 | can an unscoped token access the catalog? | 21:42 |
morganfainberg | since ATM doesn't know that the token needs to be refreshed. a bug in the logic | 21:42 |
ducttape_ | restarting the svc should kick in new tokens though | 21:42 |
morganfainberg | kfox1111: I think so, but the catalog looks really odd. | 21:42 |
mfisch | so when these current tokens expire, everything breaks again? | 21:42 |
morganfainberg | kfox1111: because things don't substitute correctly | 21:42 |
kfox1111 | know where it shows up in the python-keystone v3 client object? | 21:42 |
mfisch | that doesnt seem righth | 21:42 |
morganfainberg | mfisch: well no, not when expires | 21:42 |
kfox1111 | ah. that makes sense. | 21:42 |
morganfainberg | mfisch: if a token is ever beyond expired/otherwise invalid | 21:43 |
morganfainberg | it can refresh near expiry | 21:43 |
mfisch | it only refreshes on expiry, got it | 21:43 |
morganfainberg | it *cant* handle a invalidated token | 21:43 |
kfox1111 | I don't think barbican puts the project in the url, so that would probably be ok. | 21:43 |
mfisch | got it! | 21:43 |
mfisch | morganfainberg: so technically we're okay for now with 1.0.0 if we restart | 21:43 |
morganfainberg | mfisch: yeah | 21:43 |
morganfainberg | but i'd still upgrade to 1.1.0 if you're looking at any real lag out towards a full k upgrade | 21:43 |
mfisch | ok | 21:43 |
morganfainberg | at least 1.1.0 | 21:43 |
mfisch | thanks! | 21:43 |
morganfainberg | HT_sergio: thanks for all the help on this today! | 21:44 |
morganfainberg | kfox1111: yeah that should be fine | 21:44 |
ducttape_ | it's mo' betta' - much faster with this stuff | 21:44 |
mfisch | glance is still unhappy with us | 21:44 |
HT_sergio | morganfainberg: thank you man! | 21:44 |
morganfainberg | mfisch: figures.. poor glance, no love | 21:44 |
ducttape_ | fernet should be the keystone / devstack default (my $.02) | 21:45 |
HT_sergio | you're now on my list of people to buy beer for at the next summit :) | 21:45 |
morganfainberg | ducttape_: it will be this cycle | 21:45 |
mfisch | +1000 | 21:45 |
morganfainberg | ducttape_: there is some work that needs to happen first. but it's on my short list | 21:45 |
kfox1111 | hm... so this doesn't work unscoped: [i.to_dict() for i in ic.endpoints.list()] | 21:45 |
morganfainberg | like... making devstack able to deploy fernet at all | 21:45 |
kfox1111 | is there another part of the client I should be using? | 21:45 |
morganfainberg | kfox1111: oh via client? i don't think it will work via client | 21:46 |
kfox1111 | ic being a v3 Client. | 21:46 |
morganfainberg | kfox1111: sorry i thought pure API call | 21:46 |
morganfainberg | kfox1111: pure api, it probably works. | 21:46 |
morganfainberg | kfox1111: but it's a bit wonky in client :( | 21:46 |
kfox1111 | I'm guessing I'm not looking in the right place, cause its: Forbidden: You are not authorized to perform the requested action: identity:list_endpoints (HTTP 403) | 21:46 |
*** ducttape_ has left #openstack-keystone | 21:46 | |
morganfainberg | kfox1111: /auth/catalogh | 21:47 |
morganfainberg | v3/auth/catalog | 21:47 |
kfox1111 | k. thanks. | 21:47 |
morganfainberg | but it might get really weird | 21:47 |
morganfainberg | or might just be very confusing | 21:47 |
kfox1111 | thats ok. I'm usually in that state. ;) | 21:47 |
morganfainberg | we have not included a catalog in unscoped tokens historically so this is pushing the limits of what we've tested. | 21:47 |
morganfainberg | ayoung does [iirc] want to put a catalog in unscoped (or jamielennox did) - not opposed to it but it changes the responses somewhat | 21:48 |
morganfainberg | and we need to be careful about that | 21:48 |
kfox1111 | fair enough. I'm just prototyping something at the moment for the nova instance -> barbican workflow. | 21:49 |
kfox1111 | Just trying to figure out if it will fly at all. | 21:49 |
kfox1111 | Its close to being doable I think. | 21:49 |
kfox1111 | if it will work, I'll write up a spec and pass it around. | 21:49 |
kfox1111 | morganfainberg: The v3/auth/catalog is the url path? | 21:50 |
kfox1111 | I'm still trying to find bits in the python client. | 21:50 |
morganfainberg | kfox1111: should be. | 21:51 |
kfox1111 | I'm in the nova code at the moment, so don't want to talk to keystone directly. | 21:51 |
openstackgerrit | Lance Bragstad proposed openstack/keystone: Don't fail on converting user ids to bytes https://review.openstack.org/186120 | 21:51 |
morganfainberg | let me 2x check | 21:51 |
morganfainberg | kfox1111: https://github.com/openstack/keystone/blob/master/keystone/auth/routers.py#L41-L45 | 21:52 |
morganfainberg | kfox1111: that is at least a kilo-ism | 21:52 |
morganfainberg | checking earlier | 21:52 |
kfox1111 | ah. the cloud I'm testing with is juno at the moment. | 21:52 |
morganfainberg | kfox1111: https://github.com/openstack/keystone/blob/stable/juno/keystone/auth/routers.py#L45-L49 | 21:53 |
*** nowen has quit IRC | 21:53 | |
morganfainberg | looks ok on juno checking code as well to see if it needs a scope | 21:53 |
morganfainberg | it might | 21:53 |
morganfainberg | kfox1111: doh! https://github.com/openstack/keystone/blob/stable/juno/keystone/auth/controllers.py#L611-L615 | 21:54 |
morganfainberg | kfox1111: yep you need a scope | 21:54 |
morganfainberg | kfox1111: sorry | 21:54 |
kfox1111 | yeah... hmm. ok. | 21:54 |
kfox1111 | and kilo too. | 21:54 |
*** mattfarina has joined #openstack-keystone | 21:55 | |
kfox1111 | there is no catalog included with the token on authentication? | 21:55 |
kfox1111 | yeah, the check is in trunk too. | 21:56 |
morganfainberg | kfox1111: we should have a catalog for non-scoped things | 21:57 |
kfox1111 | can you take a scoped token and switch projects? | 21:57 |
morganfainberg | but most services can't work with no-scope | 21:57 |
morganfainberg | kfox1111: yep you can | 21:57 |
kfox1111 | ok, so I can probably just make a dummy project for things so they are scoped to something and the catalog works. | 21:57 |
morganfainberg | kfox1111: long term we don't want you to do that, we want you to explicitly scope then if you need a new scope you use the unscoped token again. | 21:58 |
morganfainberg | today you can do scoped -> scoped | 21:58 |
morganfainberg | but for security reasons this is not optimal | 21:58 |
morganfainberg | the unscoped token should be like a session - and only used between client and keystone | 21:58 |
kfox1111 | (I know of one individual using a scoped token to get a new scoped token on the same project to refresh the token btw) | 21:58 |
morganfainberg | kfox1111: unless they've changed the keystone code, the expiry is maintained from the original token | 21:59 |
morganfainberg | so it doesn't actually refresh the token :P | 21:59 |
morganfainberg | there is at least one big deployer that allows for re-issue+extend expiry of a token | 21:59 |
kfox1111 | hmm... I'll double check with him. maybe he's just using it to validate the token is valid. | 21:59 |
kfox1111 | I can't quite remember now. | 21:59 |
kfox1111 | whichever the case, I told him its a bad idea. :) | 21:59 |
morganfainberg | kfox1111: could also just do a HEAD for the token validate to see ifit's valid | 21:59 |
kfox1111 | yeah. that sounds better. | 22:00 |
morganfainberg | kfox1111: i actually want to eventually support an IMS check | 22:00 |
morganfainberg | for lots of things in keystone | 22:00 |
kfox1111 | ok. so long term, keystone would like the unscoped+service catalog for this case. | 22:00 |
morganfainberg | kfox1111: yes. i would like to have at least a usable (maybe just pointing at keystone, otherthings to add later) service catalog in unscoped | 22:00 |
kfox1111 | I'm working on prototyping the nova instance keystone user thingy we talked about at the summit. | 22:01 |
morganfainberg | ah nice | 22:01 |
kfox1111 | maybe a flag in the catalog saying the service works unscoped. | 22:01 |
morganfainberg | sure. | 22:01 |
kfox1111 | I've got the vm asking nova metadata service for a token, and getting one back now. | 22:01 |
kfox1111 | and nova creating a user named <instances-uuiud> in the nova domain. | 22:02 |
*** gokrokve has joined #openstack-keystone | 22:02 | |
morganfainberg | lots of options on how to handle all of this | 22:02 |
kfox1111 | I was hoping to pass back the catalog too, and then the vm could look at the catalog/token and contact barbican directly. | 22:02 |
kfox1111 | With its authorization stuff, I think it would work with an unscoped token, | 22:02 |
kfox1111 | so the vm wouldn't have to get a scoped one from keystone. | 22:03 |
morganfainberg | well... nova *always* requires a scope to work | 22:03 |
morganfainberg | afaik | 22:03 |
morganfainberg | otherwise it doesn't know where things belong/who owns them | 22:03 |
kfox1111 | I'm thinking I pass back the token, the catalog, then the vm can find the barbican endpoint in the list, and contact it with the unscoped token. At that point in the proces, nova's out of the picture. | 22:04 |
bknudson | an unscoped token doesn't have any roles so the user won't have any auth. | 22:06 |
*** bknudson has quit IRC | 22:06 | |
kfox1111 | I think for barbican, since they are validating the token is valid, but since they are doing acl's themselves, thats probably ok. | 22:07 |
kfox1111 | I need to install barbican on this system and try that part of it. but I'm stuck at the previous step, trying to have the vm figure out where barbican is. | 22:08 |
kfox1111 | so, should I put in a blueprint for having the catalog work with unscoped tokens then? | 22:09 |
*** lhcheng_ has quit IRC | 22:11 | |
*** Rockyg has quit IRC | 22:11 | |
kfox1111 | and would I need to file one for both keystone and python-keystoneclient? | 22:12 |
*** timcline has quit IRC | 22:14 | |
morganfainberg | kfox1111: i think we have a spec/bp for that | 22:15 |
morganfainberg | kfox1111: check with ayoung and jamielennox on where we are on that | 22:15 |
kfox1111 | ok. cool. thanks. :) | 22:16 |
morganfainberg | kfox1111: but keep in mind, scope is important if you want anything more than authn | 22:16 |
morganfainberg | because unscoped token is effectively just AuthN | 22:16 |
morganfainberg | no authZ implied | 22:16 |
kfox1111 | agreed. I'm going to leave that up to the vm to go from unscoped to whichever scope they want. | 22:16 |
kfox1111 | well, let me ask you this... | 22:17 |
kfox1111 | policy is very open at the moment. | 22:17 |
kfox1111 | I could add the project the vm's being launched under into the vm's user, but it would be able to do a lot of bad things, like delete itself, or delete every other vm in the project. | 22:17 |
kfox1111 | So I'm thinking, if I leave it unscoped, and not assign a project to it at all, it will probably work for the barbican case as is, | 22:18 |
kfox1111 | and for more complicated things, the user (or heat) can add projects to the user themselves. | 22:18 |
*** dguerri is now known as dguerri`away | 22:18 | |
morganfainberg | kfox1111: so the issue is how do you know how to audit that data if there is no project? | 22:19 |
kfox1111 | in barbican, they just associate the secrets with users directly in their acl's, I think. | 22:20 |
morganfainberg | users can have access to many projects/tenants all with different groups that care if the resources are used and how | 22:20 |
kfox1111 | hmm.... | 22:20 |
morganfainberg | how many secrets are allocated? how much space can be used. | 22:20 |
morganfainberg | often a specific user doesn't have a creditcard associated [strawman here] | 22:20 |
morganfainberg | but the project or domain would | 22:20 |
morganfainberg | it's the "encompassing account" vs "that specific user" | 22:20 |
kfox1111 | yeah, so you almost need trusts again, but that was considered too heavy weight. | 22:21 |
morganfainberg | this is even more of an issue when you start getting into federated identity w/ ephemeral users | 22:21 |
jamielennox | morganfainberg: want to +a https://review.openstack.org/#/c/171448 - there's 2 +2s and we can get this underway | 22:21 |
morganfainberg | (users that don't linger in keystone) | 22:21 |
morganfainberg | jamielennox: looking | 22:21 |
morganfainberg | jamielennox: +a | 22:21 |
morganfainberg | kfox1111: just keep all of that in mind. | 22:22 |
kfox1111 | I was pushing for acl's to live in keystone, since it can more easily deal with some of these issues, but someone, I don't remember who, was pushing back and recomending each project manage the acl's themselves. | 22:22 |
morganfainberg | kfox1111: we can consider ACL support in keystone - but that starts looking a lot like dynamic policy, or keystone having to be asked for everything an *extra* time not just at token validation | 22:23 |
morganfainberg | kfox1111: it's a delicate line to walk - how far does keystone reach into the other projects | 22:23 |
kfox1111 | trueish, but I think you can avoid it somewhat the same way keystone middleware did. its under the keystone umbrella, but pushed to the services. | 22:23 |
morganfainberg | kfox1111: you should see if the dynamic policy stuff ayoung is striving for could be used. | 22:24 |
kfox1111 | the acl's show up in the token, or something like that, and the policy engine help enforce. | 22:24 |
morganfainberg | kfox1111: exactly. poke at ayoung some. | 22:24 |
kfox1111 | ok. will do. :) | 22:24 |
openstackgerrit | Jamie Lennox proposed openstack/keystone: Move endpoint_policy migrations into keystone core https://review.openstack.org/171916 | 22:24 |
morganfainberg | kfox1111: i am not opposed to making keystone better at the "AM" part of IAM | 22:24 |
kfox1111 | cool. :) | 22:25 |
morganfainberg | kfox1111: I want to be very careful to not be a bottleneck or worse try and do everything for everyone. | 22:25 |
kfox1111 | so, with the plan so far, doing unscoped tokens, fixing the catalog, that would work for the barbican case, and maybe the dynamic policy stuff or trusts or scoping the unscoped token, would work for other services. | 22:26 |
morganfainberg | kfox1111: sounds like a good place to start looking at things. | 22:26 |
kfox1111 | agreed. with my op hat on, I don't want to deploy it if it wont scale. :) | 22:26 |
kfox1111 | ok. I'll prototype this a bit further to make sure I can get it to work end to end and there are no other gotcha's, then submit some specs. | 22:27 |
kfox1111 | Thanks for the help. :) | 22:27 |
kfox1111 | hmm... is there any push to get v3 rc files into horizon? | 22:28 |
kfox1111 | remembering all the things to tweak to get a v2 to v3 hurts. :/ | 22:28 |
*** HT_sergio has quit IRC | 22:29 | |
*** tobe has joined #openstack-keystone | 22:30 | |
david-lyle | kfox1111: v3 rc files? | 22:31 |
*** jaosorior has quit IRC | 22:32 | |
kfox1111 | if you go to horizon, -> access & security -> api access, -> "Download OpenStack RC File", you get a file that has env vars for keystone v2. | 22:33 |
jamielennox | has anyone ever seen a CONF.project attribute? https://review.openstack.org/#/c/180769/9 | 22:33 |
jamielennox | i pulled it up in a previous review because i don't know how widespread this is | 22:34 |
david-lyle | kfox1111: we could easily support a v3 version in Horizon | 22:34 |
morganfainberg | jamielennox: that is a good question | 22:34 |
morganfainberg | david-lyle: can we please support a v3 version in horizon? ;) | 22:35 |
jamielennox | i'm wondering if it's one of those things nova doesn't realize they're the only one | 22:35 |
david-lyle | kfox1111: is it safe to assume if you're using v3 in horizon, you're using v3 throughout | 22:35 |
kfox1111 | that would be awesome. I'm worried when we go to pure v3, the users experience would be.... bad currently. :/ | 22:35 |
*** tobe has quit IRC | 22:35 | |
kfox1111 | with juno, some of the clients were broken with v3 creds. | 22:35 |
kfox1111 | neutron specifically. not sure about any of the others. | 22:36 |
kfox1111 | I heard they fixed that in kilo, so maybe pure v3 might be ok now. | 22:36 |
kfox1111 | we really REALLY would like to switch to v3 for everything on our cloud, since our users are ldap authenticated, and would like to have our service accounts in sql. | 22:36 |
david-lyle | kfox1111: that's my only worry | 22:37 |
kfox1111 | but in juno, some of the openstack components wouldn't work with v3 or without the service accounts being outside of the default domain. :/ | 22:37 |
david-lyle | but I'll work on a patch | 22:37 |
morganfainberg | kfox1111: heat has some issues with pure v3 in some odd ways | 22:37 |
morganfainberg | kfox1111: but it shouldn't stop your users from only using v3 | 22:38 |
kfox1111 | I'd say, for now, if its easy to add a v3 instead of just replacing the v2, that might be good. or alternatly, make it so that both v2 and v3 are in the same config, and has a flag to switch between them safely. | 22:38 |
morganfainberg | kfox1111: i think there are 2 or three other minor issues | 22:38 |
morganfainberg | kfox1111: but it should all be purely server-to-server not user facing at this point | 22:38 |
david-lyle | kfox1111: do you know what you're missing specifically in the rc file? | 22:38 |
*** vilobhmm has left #openstack-keystone | 22:38 | |
kfox1111 | david-lyle: let me dig up an example... | 22:39 |
david-lyle | domain_id or domain_name I would think | 22:39 |
kfox1111 | we're doing something like this: | 22:42 |
kfox1111 | http://pastebin.com/80cV3m64 | 22:42 |
kfox1111 | but I'm not sure that's 100% complete. | 22:42 |
kfox1111 | I think I still have to specify --os-identity-api-version 3 on cli's sometimes. | 22:43 |
david-lyle | ok, ENV var name changes too | 22:43 |
david-lyle | makes sense | 22:43 |
kfox1111 | we started adding the unsets so that when we swtich from v2 -> v3 and back, things don't break. :/ | 22:43 |
kfox1111 | it gets pretty grumpy otherwise. | 22:44 |
*** csoukup has quit IRC | 22:44 | |
david-lyle | makes sense to me | 22:44 |
*** geoffarnold has joined #openstack-keystone | 22:44 | |
*** timcline has joined #openstack-keystone | 22:44 | |
openstackgerrit | Ian Cordasco proposed openstack/keystoneauth: Replace datetime calculations with utility functions https://review.openstack.org/186076 | 22:48 |
*** timcline has quit IRC | 22:49 | |
morganfainberg | jamielennox: re: https://review.openstack.org/#/c/185806/ | 22:49 |
morganfainberg | I am inclined to say _utils should not be aliased as "utils" as suggested, but the @_utils... is really a wonky convention | 22:50 |
*** dsirrine has quit IRC | 22:50 | |
jamielennox | morganfainberg: i don't mind, i was just looking to make the file private | 22:50 |
morganfainberg | jamielennox: we could quickly just do the alias fix as suggested and push it through | 22:50 |
morganfainberg | jamielennox: happy to make that change for ya, i'd like to keep KSA momentum. | 22:51 |
* morganfainberg needs to rebase some changes onto your chain anyway | 22:51 | |
*** afazekas has quit IRC | 22:51 | |
jamielennox | that's ok, i will | 22:51 |
morganfainberg | ok. | 22:51 |
jamielennox | morganfainberg: did you catch dhellmann | 22:51 |
morganfainberg | yes. | 22:51 |
morganfainberg | i need to just drop him a sha and the branch name | 22:51 |
morganfainberg | was in meetings but that should get in line tomorrow | 22:51 |
kfox1111 | if you set the default project on user create, does it actually associate the user to the project too, or just registers a preference? | 22:52 |
*** geoffarnold has quit IRC | 22:53 | |
*** csoukup has joined #openstack-keystone | 23:00 | |
*** Rockyg has joined #openstack-keystone | 23:01 | |
openstackgerrit | Jamie Lennox proposed openstack/keystoneauth: Replace datetime calculations with utility functions https://review.openstack.org/186076 | 23:01 |
openstackgerrit | Jamie Lennox proposed openstack/keystoneauth: Make utils file private https://review.openstack.org/185806 | 23:01 |
openstackgerrit | Jamie Lennox proposed openstack/keystoneauth: Remove oslo.utils dependency https://review.openstack.org/185807 | 23:01 |
sigmavirus24 | jamielennox: thanks for rebasing the entire chain | 23:03 |
jamielennox | sigmavirus24: np | 23:04 |
*** gokrokve has quit IRC | 23:04 | |
*** csoukup has quit IRC | 23:05 | |
*** chlong has joined #openstack-keystone | 23:05 | |
openstackgerrit | Merged openstack/keystone: Move endpoint policy into keystone core https://review.openstack.org/171448 | 23:07 |
openstackgerrit | Jamie Lennox proposed openstack/keystone: Move endpoint_policy migrations into keystone core https://review.openstack.org/171916 | 23:09 |
openstackgerrit | Jamie Lennox proposed openstack/keystone: Move endpoint_policy migrations into keystone core https://review.openstack.org/171916 | 23:09 |
morganfainberg | jamielennox: once https://review.openstack.org/#/c/186220/ merges your new branch is ready | 23:19 |
jamielennox | morganfainberg: nice! i was expecting it to be in another repo so was surprised when i went to review and had +2 | 23:20 |
*** tobe has joined #openstack-keystone | 23:31 | |
morganfainberg | jamielennox: feature branches when done right are way better than new repo things | 23:32 |
samueldmq | 2x * [(+2) + (workflow+1)] = 186220 | 23:32 |
jamielennox | it appears that feature branch reviews don't show up in channel | 23:32 |
morganfainberg | jamielennox: no they don't | 23:33 |
morganfainberg | by design | 23:33 |
jamielennox | that's probably ok | 23:33 |
morganfainberg | we'd need to add them to the project-config | 23:33 |
morganfainberg | i'd rather not | 23:33 |
jamielennox | ok, well i added https://review.openstack.org/#/c/186223/1 just to see if it all works | 23:35 |
*** tobe has quit IRC | 23:36 | |
*** Ephur has quit IRC | 23:38 | |
jamielennox | morganfainberg: we're going to have to turn off the requirements job for the feature branch | 23:38 |
*** dims_ has quit IRC | 23:38 | |
*** dims_ has joined #openstack-keystone | 23:40 | |
*** vilobhmm has joined #openstack-keystone | 23:41 | |
vilobhmm | jamielennox : ping | 23:43 |
jamielennox | vilobhmm: hello | 23:43 |
vilobhmm | when a project/tenant is created how does the default quota get assigned to every project and how does the behaviour might change when we go to heirarchical projects ? | 23:43 |
vilobhmm | i am working on implementing nested quota driver for cinder | 23:43 |
vilobhmm | the thing i want to achieve is parent/root project gets default quota as set in /etc/cinder/cinder.conf or https://github.com/openstack/cinder/blob/master/cinder/quota.py#L37 | 23:44 |
vilobhmm | whereas when the child project is created the child should be assigned a default quota of zero for all resources | 23:45 |
vilobhmm | just to avoid the race | 23:45 |
*** timcline has joined #openstack-keystone | 23:46 | |
morganfainberg | vilobhmm: so quota owned by the project itself, e.g. nova, cinder etc | 23:46 |
vilobhmm | ok | 23:47 |
vilobhmm | makes sense | 23:47 |
morganfainberg | vilobhmm: we don't actively provision anything (afaik) when things happen. | 23:47 |
morganfainberg | e.g. new project created | 23:47 |
morganfainberg | when you boot an instance nova does some internal bootstrapping | 23:47 |
morganfainberg | and the like. i believe you can pre-allocate for some things | 23:47 |
morganfainberg | even if nova hasn't seen the project yet (there was a spec to call out and validate such things existed) | 23:48 |
morganfainberg | we make an effort to not have keystone actively provision things like quota with other services. | 23:48 |
jamielennox | vilobhmm: what he said :) | 23:48 |
jamielennox | morganfainberg: https://review.openstack.org/#/c/186228/ | 23:48 |
vilobhmm | morganfainberg : thanks…what i want to do is intialize default quota values = 0 for child projects whereas for the root keep them to default values…like quota_volumes=10, etc | 23:49 |
vilobhmm | just to prevent for gettign into some race conditions | 23:49 |
morganfainberg | vilobhmm: that makes sense. you will need to ensure the heirarchy is available. that should be related to the "does this exist" spec I saw a bit ago | 23:49 |
morganfainberg | for nova (asking keystone if something existed or not) | 23:50 |
vilobhmm | ok cool | 23:50 |
*** timcline has quit IRC | 23:50 | |
*** lsmola has joined #openstack-keystone | 23:51 | |
vilobhmm | but this module https://github.com/openstack/cinder/blob/master/cinder/quota.py#L37 will remain the same for parent and child and will govern the conf values so how do we distinguish what values to apply to a root and what for the child ? in the project's table we have fields like "parent_id" so in a heirarchical projects root will have parent_id=NULL where as for child projects it will be not NULL | 23:53 |
vilobhmm | morganfainberg, jamielennox : I don't think https://review.openstack.org/#/c/186228/ points to the right spec… | 23:55 |
jamielennox | vilobhmm: that's something else that we were discussing | 23:55 |
vilobhmm | ok …do you have the spec link handy by any chance.. | 23:56 |
jamielennox | you'll have to ask morganfainberg, i'm not sure which one he's referring to in nova | 23:59 |
Generated by irclog2html.py 2.14.0 by Marius Gedminas - find it at mg.pov.lt!