Monday, 2017-03-13

*** adrian_otto has quit IRC00:00
*** kbaegis has joined #openstack-keystone00:04
*** adrian_otto has joined #openstack-keystone00:10
*** mnaser has left #openstack-keystone00:12
*** adrian_otto has quit IRC00:18
*** jamielennox is now known as jamielennox|away00:20
*** catintheroof has joined #openstack-keystone00:26
*** catintheroof has quit IRC00:26
*** catintheroof has joined #openstack-keystone00:26
*** jamielennox|away is now known as jamielennox00:27
*** liujiong has joined #openstack-keystone00:35
*** namnh has joined #openstack-keystone00:42
*** guoshan has joined #openstack-keystone00:45
*** bkudryavtsev has joined #openstack-keystone00:50
*** bkudryavtsev has quit IRC00:50
*** bkudryavtsev has joined #openstack-keystone00:51
*** bkudryavtsev has quit IRC00:51
*** dave-mccowan has joined #openstack-keystone00:59
*** ravelar has joined #openstack-keystone01:01
*** zhurong has joined #openstack-keystone01:11
*** ravelar has quit IRC01:12
*** guoshan has quit IRC01:16
*** guoshan has joined #openstack-keystone01:19
*** Shunli has joined #openstack-keystone01:21
*** guoshan has quit IRC01:23
*** wangqun has joined #openstack-keystone01:34
*** guoshan has joined #openstack-keystone02:09
*** guoshan has quit IRC02:10
*** guoshan has joined #openstack-keystone02:10
*** catintheroof has quit IRC02:18
openstackgerritMerged openstack/oslo.policy master: Allow multiline descriptions for RuleDefaults  https://review.openstack.org/44134202:32
*** yuvalb has quit IRC02:43
*** yuvalb has joined #openstack-keystone02:43
*** catintheroof has joined #openstack-keystone02:45
*** catintheroof has quit IRC02:45
*** catintheroof has joined #openstack-keystone02:45
*** Guest45610 has joined #openstack-keystone03:07
*** nicolasbock has quit IRC03:21
*** adrian_otto has joined #openstack-keystone03:31
*** dave-mccowan has quit IRC03:32
*** Guest45610 has quit IRC03:33
*** prashkre has joined #openstack-keystone03:34
*** catintheroof has quit IRC03:37
*** adrian_otto has quit IRC03:41
*** adrian_otto has joined #openstack-keystone03:50
*** prashkre has quit IRC03:54
*** frontrunner has quit IRC03:54
*** adrian_otto has quit IRC03:55
*** links has joined #openstack-keystone04:02
*** aojea has joined #openstack-keystone04:06
*** aojea has quit IRC04:11
*** chlong_ has quit IRC04:34
*** markvoelker has quit IRC04:35
*** aasthad has joined #openstack-keystone05:05
*** thorst_afk has joined #openstack-keystone05:19
*** thorst_afk has joined #openstack-keystone05:28
*** thorst_afk has quit IRC05:32
*** markvoelker has joined #openstack-keystone05:36
*** prashkre has joined #openstack-keystone05:40
*** markvoelker has quit IRC05:41
*** thorst_afk has joined #openstack-keystone05:43
*** thorst_afk has quit IRC05:47
*** tovin07 has joined #openstack-keystone06:00
*** h5t4 has joined #openstack-keystone06:09
*** adriant has quit IRC06:40
*** h5t4 has quit IRC06:54
*** YanXing_an has joined #openstack-keystone07:03
*** Shunli has quit IRC07:06
*** Shunli has joined #openstack-keystone07:07
*** jaybeers has quit IRC07:17
*** h5t4_ has joined #openstack-keystone07:27
*** henrynash has joined #openstack-keystone07:28
*** YanXing_an has quit IRC07:33
*** YanXing_an has joined #openstack-keystone07:34
*** henrynash has quit IRC07:43
*** Andrew_jedi has joined #openstack-keystone07:48
Andrew_jediHello folks, can we define a role that gives a user the ability to create a project, but not to modify any of its quota settings?07:49
*** belmoreira has joined #openstack-keystone07:54
*** zzzeek has quit IRC08:00
*** zzzeek has joined #openstack-keystone08:00
*** tovin07 has quit IRC08:07
*** tovin07 has joined #openstack-keystone08:12
*** tesseract has joined #openstack-keystone08:13
*** tesseract has quit IRC08:17
*** aojea has joined #openstack-keystone08:17
*** openstackgerrit has quit IRC08:18
*** aojea has quit IRC08:19
*** aojea has joined #openstack-keystone08:19
bretonyes, we can08:20
*** pcaruana has joined #openstack-keystone08:25
*** aojea_ has joined #openstack-keystone08:25
*** agrebennikov has joined #openstack-keystone08:28
*** aojea has quit IRC08:29
Andrew_jedibreton: great, could you please elaborate a bit as to how can we do it ?08:30
*** tesseract has joined #openstack-keystone08:32
*** agrebennikov has quit IRC08:33
YanXing_anhello, folks, i want to use barbican to store fernet keys. Do you known what projects are using barbican currently?08:36
Andrew_jediYanXing_an: I think magnum uses it08:38
YanXing_anAndrew_jedi: Thanks. I will have a look at magnum.08:41
bretonAndrew_jedi: you probably need to modify policy.json08:41
bretonAndrew_jedi: you probably need a role that can create_project in keystone's policy.json but cannot perform operations on quotas in nova's, neutron's and cinder's policy.json.08:43
bretoni don't know what are the functions that do it in services other than keystone unfortunately08:43
Andrew_jedibreton: oh, that is useful info, thanks!08:44
Andrew_jedibreton: btw Is there a way to create cross-domain tenants, i.e. tenants where users/groups from different domains can hold a role in a specific tenant?08:44
Andrew_jedibreton: AFAIK It is not possible to create cross-domain projects but it is possible for users to have roles in multiple domains? right ?08:45
bretonAndrew_jedi: that's right08:51
Andrew_jedibreton: but whats confusing me is this, if a single user can be a member of groups in different domains, and those groups are assigned roles in two different projects, then that would make them cross-domain projects, no?08:52
*** jaosorior has joined #openstack-keystone08:57
*** prashkre has quit IRC08:57
*** pnavarro has joined #openstack-keystone09:00
*** prashkre has joined #openstack-keystone09:06
bretonAndrew_jedi: i think that a single user cannot be a member of groups in different domains09:08
bretonAndrew_jedi: let me check what our unit tests say about this case09:09
*** henrynash has joined #openstack-keystone09:09
breton1204         self._assert_user_and_group_in_same_backend(09:15
breton1205             user_entity_id, user_driver, group_entity_id, group_driver)09:15
Andrew_jedibreton: I am sorry, it is not clear to me what does it mean ?09:17
bretonAndrew_jedi: it's not clear for me either :) still checking09:17
bretonwell, it seems to be possible, ok.09:20
Andrew_jedibreton: great, i was also checking this post from ayoung , https://adam.younglogic.com/2016/11/keystone-domains-are-projects/09:21
*** aasthad has quit IRC09:22
Andrew_jedibreton: It appears that we can also assign a role to a user at domain level so if i assign a role to a user in two different domains then this user will a have arole in all the projects in two domains.09:23
breton> then this user will a have arole in  all the projects in two domains.09:25
bretonnot really09:25
bretonAndrew_jedi: it depends on the policy used09:25
bretonAndrew_jedi: it is possible to write a policy this way, but the one policy that goes with devstack doesn't support it09:26
bretonAndrew_jedi: policy.v3cloudsample.json might support that, but i am not sure09:26
Andrew_jedibreton: Got it, I tried to look for an example keystone policy file over internet from a production deployment but the only example available is policy.v3cloudsample.json09:30
*** henrynash has quit IRC09:32
*** Shunli has quit IRC09:35
*** tovin07 has quit IRC09:39
*** openstackgerrit has joined #openstack-keystone10:04
openstackgerritiswarya vakati proposed openstack/keystonemiddleware master: Pass located tests directory in oslo debug  https://review.openstack.org/44479510:04
*** YanXing_an has left #openstack-keystone10:09
ayoungbreton,  a single user *can* be a member of groups in different domains10:16
ayoungA user in one domain can belong to a group in a second domain, and by that group, get a role on a project in a third domain.10:18
*** zhurong has quit IRC10:21
*** zhurong has joined #openstack-keystone10:22
*** nicolasbock has joined #openstack-keystone10:24
*** liujiong has quit IRC10:25
bretonayoung: if user and group are in the same backend, yes.10:26
ayoungbreton, Ah...yeah, that whole nastiness10:26
ayoungbreton, talk to rich derose when he's back and find out about that.  With the shadow user table should be able to be in any backend10:27
ayoungand with LDAP, I think it works if you use the id mapping backend, too.  But in both cases you need a local entry for the user prior to assignment, which is a PITA10:28
bretonayoung: today there is an assertion in the code, i posted a code snippet above. So even if it's theoretically possible, it needs to be patched.10:29
ayoungJOy.  Rapture.10:29
ayoungbreton, right.  That will mess up LDAP.10:30
ayoungbreton, not sure how it affects Federated users10:30
ayoungbreton, and this is why Keystone makes me sad.10:33
bretonayoung: how do you think we could fix this? :)10:34
ayoungbreton, I think we can use the dhadow user stuff .  Any user in there can be a member of a group anywhere.10:35
ayoungshadow10:35
*** guoshan has quit IRC10:35
*** lifeless has quit IRC10:37
Andrew_jediayoung: hello :). thanks for some very nice blog posts on keystone!10:38
ayoungAndrew_jedi, thanks for the positive feedback10:39
Andrew_jediayoung: fyi, my questions earlier were regarding this use case. We want to separate role assignments (and hence, permissions) per-tenant, we would like people whose user credentials live in separate Microsoft AD domains — which we want to map to Keystone domains — to collaborate on specific tenants.10:39
Andrew_jedi:)10:39
ayoungYeah, try hacking out that check in the python code and see if it works if you enable the id_mapping for the AD users10:40
*** nicolasbock has quit IRC10:41
*** markvoelker has joined #openstack-keystone10:41
bretoni think it won't work10:43
*** zhugaoxiao has quit IRC10:43
bretonprobably because user-group membership is done via Fk10:44
*** prashkre_ has joined #openstack-keystone10:44
*** zhugaoxiao has joined #openstack-keystone10:44
Andrew_jedibreton: Fk??10:45
*** lifeless has joined #openstack-keystone10:45
*** wangqun has quit IRC10:45
bretonAndrew_jedi: foreign key10:46
Andrew_jedibreton: ah, ok. thanks!10:46
*** markvoelker has quit IRC10:46
*** prashkre has quit IRC10:47
*** namnh has quit IRC10:47
Andrew_jediayoung: btw, Is it possible that two different users, being in two different groups, which belong to different domains, having roles in the same projects ?10:58
ayoungAndrew_jedi, yes10:58
ayoungAndrew_jedi, assuming they are all in the same backend, that is possible, and supported10:59
openstackgerritiswarya vakati proposed openstack/keystonemiddleware master: Pass located tests directory in oslo debug  https://review.openstack.org/44479511:02
Andrew_jediayoung: got it, thanks! :)11:06
*** evrardjp has joined #openstack-keystone11:08
*** nicolasbock has joined #openstack-keystone11:09
*** rodrigods has quit IRC11:18
*** rodrigods has joined #openstack-keystone11:18
Andrew_jediayoung: Could you please also comment on the ability of defining (or re-defining) a role that can create projects in a domain, but not modify their quotas? earlier,  breton was kind enough to suggest that this can be achieved by editing policy.json files across various OpenStack services11:21
*** rodrigods has quit IRC11:23
*** rodrigods has joined #openstack-keystone11:23
ayoungAndrew_jedi, Quotas for what?11:27
breton]/win 2711:27
*** mvk has quit IRC11:27
breton:(11:28
bretonAndrew_jedi: there is no such role now. You need to create it and then modify policy.json11:29
Andrew_jedibreton: yep, i understood that part :)11:29
Andrew_jediayoung: Quotas for Nova, Cinder and neutron.11:30
ayoungAndrew_jedi, those quotas would be managed by calls to the APis in the respective projects11:30
ayoungpolicy.json for Keystone would manage who could create a project11:30
Andrew_jediayoung: Sorry ... can we define a role that gives a user the ability to create a project, but not to modify any of its quota settings?11:31
ayoungcreate a roll called "quotator" and modify the calls in Neutron et alles to check for that role11:31
ayoungAndrew_jedi, yep11:31
*** henrynash has joined #openstack-keystone11:31
ayoungAndrew_jedi, so long as the API calls in Neutron etc require a more stringent role (like admin) to make the quota calls11:32
Andrew_jediayoung: I am a bit confused here, just to be clear you are saying that i need to create a role and then modify the keystone policy.json accordingly. And no changes in Neutron or Nova policy.json files.11:33
ayoungAndrew_jedi, I really can make no statement about what you have to do on any policy file other than Keystone.11:34
ayoungYou might have to change those files, or you might be fine.  I've not looked at the API calls11:35
ayoungin the case of Keystone, the create_project call would require that the user making the call have a token with the appropriate role and scope11:35
ayoungand I am not certain what you should look at for scope, whether it needs to be domain scoped or if you can use a project scoped token.11:36
ayoungI don't have the time to dig into the code right now to answer that.11:36
ayoungAnd, you would have to confirm yourself anyway, because I lie.11:36
Andrew_jediayoung: understood, thanks for your time. I appreciate it :)11:36
Andrew_jedilol11:36
*** nicolasbock has quit IRC11:37
Andrew_jediayoung: I just had a crazy idea, in the next summit, before the first day keynote is about to start, i can shout "Hey Adam, you lied to me" ... :)11:41
Andrew_jedi:P11:41
ayoungAnd I will respond "I told you I would"11:41
*** nicolasbock has joined #openstack-keystone11:42
*** markvoelker has joined #openstack-keystone11:42
Andrew_jediayoung: hahaha11:42
*** markvoelker has quit IRC11:46
*** henrynash has quit IRC11:49
*** henrynash has joined #openstack-keystone11:49
*** erlon has joined #openstack-keystone11:51
*** henrynash has quit IRC11:54
sigmaviruslbragstad: http://git.openstack.org/cgit/openstack/requirements/commit/global-requirements.txt?id=08b589c5ad0f0f49d8d5880f3a703cfae43b0a39 is why 2.13.0 is blocked iirc11:57
*** henrynash has joined #openstack-keystone12:01
*** mvk has joined #openstack-keystone12:01
*** henrynash has quit IRC12:05
*** henrynash has joined #openstack-keystone12:13
*** henrynash has quit IRC12:14
*** markvoelker has joined #openstack-keystone12:16
*** henrynash has joined #openstack-keystone12:18
*** henrynash has quit IRC12:20
*** Andrew_jedi has quit IRC12:25
*** DuncanT has joined #openstack-keystone12:26
*** lamt has quit IRC12:28
bretonTIL about http://alembic.zzzcomputing.com/en/latest/naming.html#integration-of-naming-conventions-into-operations-autogenerate12:30
*** edmondsw has joined #openstack-keystone12:31
*** guoshan has joined #openstack-keystone12:38
*** raildo has joined #openstack-keystone12:43
*** henrynash has joined #openstack-keystone12:43
*** henrynash has quit IRC12:46
*** henrynash has joined #openstack-keystone12:47
*** henrynash has quit IRC12:51
*** guoshan has quit IRC12:57
lbragstaddstanek o/13:01
lbragstaddstanek did you happen to see the note from dims about the keystone reviews? http://lists.openstack.org/pipermail/openstack-dev/2017-March/113813.html13:01
*** spilla has joined #openstack-keystone13:01
*** zhurong has quit IRC13:01
*** guoshan has joined #openstack-keystone13:03
*** nicolasbock has quit IRC13:05
*** nicolasbock has joined #openstack-keystone13:09
*** lamt has joined #openstack-keystone13:09
*** Kvisle has joined #openstack-keystone13:13
*** Kvisle has left #openstack-keystone13:14
*** dakhmetov has joined #openstack-keystone13:20
dakhmetovgreetings, guys!13:20
dakhmetovCould you please clarify, was (or will be) hierarchical projects implemented in keystone?13:21
lbragstaddakhmetov keystone already has support for nesting projects13:22
lbragstaddakhmetov but there are on-going efforts to get other things working with that structure (like quotas)13:22
dakhmetovlbragstad: awesome! In which OpenStack release it was presented?13:23
*** bknudson_ has joined #openstack-keystone13:27
lbragstaddakhmetov hmm - it was supported a while ago (I remember talking about the implementation approach during the Atlanta design summit in 2014)13:30
dimsdakhmetov : what exactly are you looking for? (support in horizon? CLI? what do you want to use it for)13:30
dakhmetovlbragstad: but Nova quota management for nested projects is not yet possible, right?13:30
lbragstadaccording to our specs repository - the server implementation landed in Juno http://specs.openstack.org/openstack/keystone-specs/specs/keystone/juno/hierarchical_multitenancy.html13:31
raildodakhmetov, no, it's not, for now, we only have support no cinder13:31
lbragstaddakhmetov right - we are working with other projects to get that support worked into other projects consistently13:31
raildoon cinder*13:31
dakhmetovI wondering if it's possible to manage quota for subproject.13:31
dakhmetovGot it. Thank you, guys!13:31
lbragstaddakhmetov we do have a couple specs proposed to keystone that contain a bunch of good information from the PTG though13:32
lbragstaddakhmetov https://review.openstack.org/#/q/topic:unified-limits13:32
lbragstadhere's a relatively straight forward keystonemiddleware review that closes a bug if anyone is interested - https://review.openstack.org/#/c/444795/213:34
*** frontrunner has joined #openstack-keystone13:37
*** richm has joined #openstack-keystone13:42
*** henrynash has joined #openstack-keystone13:46
*** lucasxu has joined #openstack-keystone14:00
*** dnalezyty has joined #openstack-keystone14:02
*** chlong has joined #openstack-keystone14:11
rodrigodslbragstad, ping... are you stable releases liaison too? :)14:15
lbragstadrodrigods i am14:16
*** links has quit IRC14:16
rodrigodslbragstad, i have a newton backport for a bug fixed in ocata https://review.openstack.org/#/c/420893/14:16
lbragstadrodrigods or i assume i am based on some wiki somewhere?14:16
rodrigodsyou have +1 there, was wondering if we can move this forward14:17
*** guoshan has quit IRC14:17
lbragstadrodrigods cool - i'm working on another set of reviews but once i finish those I'm going to look over some stable patches, I'll add this to that list14:20
rodrigodsthanks lbragstad14:21
*** kbaegis has quit IRC14:26
knikollao/14:31
*** dtroyer_zz has quit IRC14:33
*** dtroyer has joined #openstack-keystone14:33
*** kbaegis has joined #openstack-keystone14:35
*** dave-mccowan has joined #openstack-keystone14:35
*** kbaegis has quit IRC14:37
*** frontrunner has quit IRC14:41
*** rderose has joined #openstack-keystone14:41
*** chris_hultin|AWA is now known as chris_hultin14:46
*** dakhmetov has quit IRC14:51
*** henrynash has quit IRC14:58
*** henrynash has joined #openstack-keystone14:59
*** adrian_otto has joined #openstack-keystone15:06
*** h5t4_ has quit IRC15:15
*** ravelar has joined #openstack-keystone15:16
*** prashkre_ has quit IRC15:23
openstackgerritJose Castro Leon proposed openstack/keystone master: Skip multifactor when using LDAP identity backend  https://review.openstack.org/44494915:30
*** ravelar has quit IRC15:32
*** jaugustine has joined #openstack-keystone15:34
*** ravelar has joined #openstack-keystone15:36
openstackgerritLance Bragstad proposed openstack/keystone master: Add reno conventions to developer documentation  https://review.openstack.org/44495515:41
*** knangia has joined #openstack-keystone15:42
*** aasthad has joined #openstack-keystone15:44
*** ravelar has quit IRC15:45
openstackgerritLance Bragstad proposed openstack/keystone master: Add reno conventions to developer documentation  https://review.openstack.org/44495515:53
lbragstadrodrigods the fix for https://review.openstack.org/#/c/420893/ landed in ocata, right?15:54
lbragstadrodrigods or was it merged to master before ocata was released?15:54
notmorganlbragstad: that patch is broken15:59
notmorganlbragstad: it is doing the wrong thing15:59
lbragstadnotmorgan https://review.openstack.org/#/c/420893/ you mean?15:59
notmorganyep16:00
notmorganyou CANT have a FK between subsystems16:00
notmorganever16:00
notmorganEVER16:00
lbragstadohhhh16:00
notmorganfederated_table (FederatedUser is in Identity)16:00
lbragstadright16:00
notmorganthe protocol one is in federation16:00
notmorganso, we need to just drop the FK16:00
lbragstadwell - we must have merged that to master than16:00
lbragstadthen*16:00
notmorganwelp, we need to undo that now16:01
notmorganwith another migration16:01
notmorganand the backport has to be to drop the FK16:01
lbragstadwell - the backport never merged16:01
notmorganright16:01
notmorganthe backport needs to be dropping the original FK16:01
notmorganand code to maintain the interdependency16:01
notmorganthere is already an FK .16:01
notmorganthis is ugly to backport fwiw16:02
notmorganbecause we have to "fix" a merged migration too.16:02
notmorganto be idempotent16:02
notmorganwe need to create a sql validator test that identifies what subsystems things are part of and ensure we don't FK between them16:02
notmorganbut anyway16:05
notmorgan...16:05
notmorganuhm...16:05
notmorganyeah16:05
*** h5t4 has joined #openstack-keystone16:05
lbragstadhmm16:06
lbragstadrodrigods is this making sense?16:06
*** belmoreira has quit IRC16:06
notmorganso, the fix is as follows:16:07
notmorganmerge a new migration to master than drops the FK and adds code, and fixes the previous migration to be idempoent if the FK is already removed.16:08
notmorganbackport the code (maintaining the relationship in managers) and dropping the original FK.16:08
lbragstadnotmorgan question on requirements16:09
lbragstadOPB has this proposed to stable/ocata - https://review.openstack.org/#/c/443881/16:09
lbragstadand typically when pbr changes versions - there is a change to setup.py to change the version there, too16:10
lbragstadbut that doesn't seem to be happening with stable requirements16:10
* lbragstad https://github.com/openstack/python-keystoneclient/blob/stable/ocata/setup.py#L2816:10
*** kbaegis has joined #openstack-keystone16:12
rodrigodsnotmorgan, lbragstad arriving late to the discussion16:14
rodrigodsnotmorgan, got your point, i wish you had participated in the initial discussion16:15
notmorganrodrigods: sorry16:15
notmorgani can only keep track of so many things at once16:15
rodrigodsnotmorgan, heh16:15
*** david-lyle has joined #openstack-keystone16:15
rodrigodsnotmorgan, lbragstad, so the correct fix is to drop the FK and delete the user in the code layer?16:16
notmorganlbragstad: no idea about requirements, i saw a stable/ocata change that set <=2.0.0 that already merged afair16:16
notmorganlbragstad: i might have approved it16:16
notmorganrodrigods: correct. (manager layer, as managers are inter-subsystem communication tools)16:16
notmorganrodrigods: but you have ick to unwind now.16:16
notmorgansorry man16:16
lbragstadnotmorgan ok - i'll head over to openstack-requirements and ask16:16
rodrigodsno, i'm sorry16:17
rodrigodsi should have known about this :)16:17
*** nicolasbock has quit IRC16:21
openstackgerritGage Hugo proposed openstack/keystone-specs master: Add Project tags  https://review.openstack.org/43178516:21
*** nicolasbock has joined #openstack-keystone16:25
*** henrynash has quit IRC16:26
*** pcaruana has quit IRC16:38
*** mvk has quit IRC16:45
openstackgerritMerged openstack/keystonemiddleware master: Pass located tests directory in oslo debug  https://review.openstack.org/44479516:47
*** kbaegis has quit IRC16:49
*** dr_gogeta86 has joined #openstack-keystone16:59
*** kbaegis has joined #openstack-keystone17:00
dr_gogeta86hi guys17:01
dr_gogeta86i'm looking for some saml specialist17:02
*** kbaegis has quit IRC17:03
*** lucasxu has quit IRC17:03
openstackgerritAnthony Washington proposed openstack/oslo.policy master: Add additional param to policy.RuleDefault  https://review.openstack.org/43907017:04
*** prashkre_ has joined #openstack-keystone17:05
*** chlong has quit IRC17:07
*** kbaegis has joined #openstack-keystone17:10
*** prashkre_ has quit IRC17:12
*** prashkre_ has joined #openstack-keystone17:12
openstackgerritAnthony Washington proposed openstack/oslo.policy master: Add additional param to policy.RuleDefault  https://review.openstack.org/43907017:14
*** ayoung has quit IRC17:16
*** ayoung has joined #openstack-keystone17:17
*** openstackgerrit has quit IRC17:18
*** catintheroof has joined #openstack-keystone17:25
*** lucasxu has joined #openstack-keystone17:30
*** browne has joined #openstack-keystone17:35
-openstackstatus- NOTICE: restarting gerrit to address performance problems17:44
*** gutter has joined #openstack-keystone17:47
*** gutter has quit IRC17:47
*** jamielennox is now known as jamielennox|away17:53
*** nicolasbock has quit IRC17:54
*** aojea_ has quit IRC17:56
*** jaosorior has quit IRC17:56
*** adrian_otto has quit IRC17:57
*** nicolasbock has joined #openstack-keystone17:57
*** rderose has quit IRC17:57
*** ynirk has joined #openstack-keystone17:59
*** tesseract has quit IRC17:59
*** adrian_otto has joined #openstack-keystone18:01
*** openstackgerrit has joined #openstack-keystone18:04
openstackgerritAnusha Unnam proposed openstack/oslo.policy master: Seperate each policy rule with new line  https://review.openstack.org/44333218:04
*** thorst_afk has joined #openstack-keystone18:04
*** thorst_afk has quit IRC18:04
*** MasterOfBugs has joined #openstack-keystone18:16
*** adrian_otto has quit IRC18:17
*** adrian_otto has joined #openstack-keystone18:19
openstackgerritAnusha Unnam proposed openstack/oslo.policy master: Seperate each policy rule with new line  https://review.openstack.org/44333218:19
*** aojea has joined #openstack-keystone18:23
*** nicolasbock has quit IRC18:33
*** mvk has joined #openstack-keystone18:33
*** raildo has quit IRC18:39
*** nicolasbock has joined #openstack-keystone18:41
bretondr_gogeta86: we all are saml specialists here. Ask away!18:48
*** aojea has quit IRC18:53
*** kbaegis has quit IRC18:55
*** agrebennikov has joined #openstack-keystone18:58
*** zhugaoxiao has quit IRC19:04
*** zhugaoxiao has joined #openstack-keystone19:05
rodrigodsbreton, i'm not heh19:08
lbragstaddr_gogeta86 dstanek is probably one of the most knowledgeable folks around about saml19:10
lbragstaddr_gogeta86 i do know that he is going to be out until wednesday though - put please don't hesitate to ask anyway19:10
openstackgerritOpenStack Proposal Bot proposed openstack/python-keystoneclient master: Updated from global requirements  https://review.openstack.org/43935519:41
*** h5t4 has quit IRC20:02
*** chlong has joined #openstack-keystone20:04
openstackgerritAnthony Washington proposed openstack/oslo.policy master: Add additional param to policy.RuleDefault  https://review.openstack.org/43907020:05
openstackgerritAnthony Washington proposed openstack/oslo.policy master: Add additional param to policy.RuleDefault  https://review.openstack.org/43907020:07
lbragstadantwash nice work - that passes for me locally20:07
antwashlbragstad: thank you, I like the python properties its really cool20:08
*** raildo has joined #openstack-keystone20:09
*** aojea has joined #openstack-keystone20:09
lbragstadantwash yeah - makes things a little cleaner20:09
antwashlbragstad: def made the unittest shorter as well since checks are being taken care of at init level20:09
*** h5t4_ has joined #openstack-keystone20:09
lbragstadantwash we could add a few more negative test cases, too20:10
*** henrynash has joined #openstack-keystone20:11
antwashlbragstad: yeah, I can add some20:17
lbragstadantwash another thing we could do is make the exceptions more specific20:18
lbragstadsince we know exactly what is missing in specific cases - we could pass more of that information along to the developer20:18
lbragstadantwash here are a few tests I have locally - http://cdn.pasteraw.com/am1zwqs3t3g8pw6a5v00uuom7o5jqer20:19
antwashlbragstad: I was trying to figure how I was going to compare like the raised errors, but now I see how it's suppose to be handled20:22
antwashthanks for that, no more time wasted lol20:22
lbragstadantwash yep - and we could be more specific about those too if we end up adding different exceptions for those cases20:23
lbragstadI wouldn't expect an end user or deployer to ever see those, since they'd be primarily to catch developer mistakes20:23
lbragstadantwash yeah - we should totally make those more explicit20:26
lbragstadantwash i just spent 10 minutes trying to figure out why test_operations_only_contain_a_method_and_a_path passed for the wrong reason ;) http://cdn.pasteraw.com/by3ff7xl44opkkzxtqqir2h5d8bxpc20:26
lbragstadantwash can you spot it?20:26
*** adrian_otto has quit IRC20:27
* antwash let me see20:30
antwashlol we don't have the check for more than two keys?20:31
antwashI'll have to add that back, I removed it lol20:32
antwashlbragstad: ^20:32
lbragstadantwash nope ;)20:33
lbragstadantwash the way the test is written it should have failed *because* there was an extra key20:33
lbragstadantwash instead it that test gets a valid object back instead of an exception http://cdn.pasteraw.com/1zcr7olmz4o53nlrklpy8zjxx6ot5hk20:33
*** raildo has quit IRC20:34
lbragstadi was expecting it to fail but it passed because I wasn't passing it in as a list20:34
lbragstadI copy/pasted the previous tests that asserted operations must be a list20:35
lbragstadso it was fast failing20:35
antwashlbragstad: aweeee, I see!20:35
* lbragstad facepalms20:35
*** jamielennox|away is now known as jamielennox20:37
*** aojea has quit IRC20:39
*** adriant has joined #openstack-keystone20:51
*** catinthe_ has joined #openstack-keystone20:56
*** catintheroof has quit IRC20:58
*** edmondsw has quit IRC20:58
*** aojea has joined #openstack-keystone20:59
*** bww has joined #openstack-keystone20:59
openstackgerritGage Hugo proposed openstack/keystone-specs master: Add Project tags  https://review.openstack.org/43178521:02
*** pnavarro has quit IRC21:04
*** rderose has joined #openstack-keystone21:13
*** spilla has quit IRC21:14
*** henrynash has quit IRC21:16
*** catintheroof has joined #openstack-keystone21:31
*** chlong has quit IRC21:34
*** catinthe_ has quit IRC21:35
*** henrynash has joined #openstack-keystone21:38
* lbragstad rderose for the api key spec - https://review.openstack.org/#/c/438761/1221:42
lbragstadrderose wasn't there some discussion about whether or not we should all api-key scoped tokens?21:43
lbragstadi thought there was still some discussion on whether or not we should treat the API key as the authenticated bit of information or if we should treat it as the authentication mechanism21:44
rderosethere was discussion about treating api-keys as a credential vs token21:45
*** henrynash has quit IRC21:45
lbragstadbecause with traditional API keys, it acts as a credential, right?21:45
lbragstadI should be able to pass it to something and it should work like a token - but the way we are using it is like a scoping mechanism21:46
rderoselbragstad: well, I think dstanek would argue that traditionally it acts as a token21:46
rderoselbragstad: yeah, I'm treating it more like a credential, where you would use it to auth and then request a scoped token21:46
lbragstadrderose what was the usecase for having it operate like a credential?21:47
lbragstadversus a token?21:47
*** chlong has joined #openstack-keystone21:47
rderoselbragstad: use case is the same either way, I want to be able to create access keys for my tools with limited scope, so that I'm not putting my username/password into config files21:48
lbragstadsure - i should rephrase my question, what the reason for not having the same flow like traditional API keys?21:49
rderoselbragstad: I think from an implementation perspective, it would be easier21:50
lbragstadrderose how so?21:50
lbragstadrderose i just want to walk through it is all21:50
rderoselbragstad: agree, lets do that21:51
rderoseI think just the fact of trying to create another token type would make it more complicated.  Whereas, if I treat the key as a credential type, I simply have to create a new auth plugin.21:52
lbragstadrderose that makes sense21:52
rderoseThe CRUD should be the same either way21:53
lbragstadso it would be an application specific password that would live forever21:53
rderoseyeah, or until it expires or the client deletes it21:53
lbragstadright21:53
lbragstadso the client still has to have logic that understand the limitation of tokens21:54
rderoselbragstad: the client would have to know how request a new token if it expires21:54
lbragstad(i.e. do something, if it fails try and get a new token scoped with this thing, try again)21:55
rderoseyeah21:55
rderoselbragstad: and we could always change it later to act more like a token, without having to change the CRUD API21:55
rderosepotentially21:56
lbragstadyeah - i think that'd be hard to do either way we go about it21:56
lbragstadbecause it a new api21:56
lbragstadthey both solve the same problem - which is keeping passwords out of application config files21:57
rderoseyeah21:57
rderoseexactly21:57
*** prashkre_ has quit IRC21:57
lbragstadif we treat this like a credential, then I think we should consider alternative names21:58
rderoseyeah, was thinking about that21:58
lbragstadsince it's not API keys in the way users expect them to be API keys21:58
rderoseit shouldn't be called API keys, but more like 'access key credential'21:58
antwashlbragstad: when you say make  more explicit, are you referring to the exception?21:59
lbragstadif we decide to implement a new token type and maintain the same user experience users are familiar with, then i'm all for keeping it an API key21:59
antwashI added a diff message, when it's raised for each case21:59
openstackgerritAnthony Washington proposed openstack/oslo.policy master: Add additional param to policy.RuleDefault  https://review.openstack.org/43907021:59
lbragstadantwash yeah - just another thing we could do to make things easier for developers using it22:00
lbragstadantwash in the validation process we know *why* what they gave us failed to compute, so we can give them the exact reason22:00
rderoselbragstad: well, I want a name that will do both, so that it gives us flexibility should we make access keys act more like a token22:00
antwashlbragstad: yeah I added a diff message for each, oslo_policy/policy.py22:00
antwash*in22:00
rderoselbragstad: sort of why I named it API access keys22:00
rderoseand not API keys22:01
rderose*act more like tokens later22:01
lbragstadrderose i'm not sure we'll be able to make application specific passwords act like API keys in the future if we ever want to merge the two22:01
lbragstadwill we?22:01
rderoselbragstad: why not? if you create an access key, the value it just a long string22:02
rderosecould be token22:02
lbragstadrderose right - but its a difference in how they are used22:02
rderoselbragstad: yeah, my point is the CRUD api would still be the same22:02
lbragstadoh - right22:02
*** jamielennox is now known as jamielennox|away22:03
lbragstadyeah, that makes sense22:03
lbragstadi was thinking about trying to make the usage the same22:03
lbragstadi think that'd be tough because in one case you're treating it like a password that you use to authenticate for a token and in the other case you're treating it like the token22:04
openstackgerritGage Hugo proposed openstack/keystone-specs master: Add Project tags  https://review.openstack.org/43178522:04
rderoselbragstad: right, so if we change this later, we'd essentially be passing a token string as the access key value22:04
rderoseand then update the access key auth plugin and middleware22:05
rderoseto be able to deal with it22:05
lbragstadyeah22:05
rderoselbragstad: so we could allow the access key value to be used to auth and as a token22:06
lbragstadso - would it be confusing to have a service that implemented both and were super similar?22:06
rderoselbragstad: but the API shouldn't be impacted22:06
*** jamielennox|away is now known as jamielennox22:07
rderoselbragstad: well, I'm more in favor of trust treating access keys as credential (password) because I think it's easier and completely solves the use case22:07
lbragstadtrust treating access keys as credentials?22:08
rderoselbragstad: implemented both (access key credential and token)?22:08
lbragstadrderose right - having access key credentials and treating them like api keys22:08
rderose*just treating access keys as credential22:09
lbragstadah22:09
lbragstadwell - it would be flexible22:09
lbragstadbecause the flow would be something like:22:09
rderoselbragstad: I don't think it would be confusing, we already do this with tokens22:09
lbragstad1.) create an API key (which is the CRUD API)22:09
rderosetokens are using to auth for another token22:09
lbragstad2.) you can request a token scoped to your api key22:10
lbragstad3.) or you can use the API key like you would normally us it22:10
lbragstaduse it*22:10
rderoseyes, and #2 we already do today with tokens22:10
lbragstadwhich might provide a better way for people to migrate their applications from using username/password authentication to API keys22:10
rderoseyeah22:11
lbragstadright - i would imagine #3 is where people would want to be because they don't head to deal with the "is this token still valid problem"22:11
lbragstad"is this token still valid" problem *22:11
lbragstadin all their client/application code22:11
rderoseyeah, true22:11
rderoselbragstad: however, that wasn't the main use case for access keys22:13
*** catintheroof has quit IRC22:13
rderoseand treating them as credential first doesn't stop us from getting there22:14
lbragstadagree - but i don't want to call them API keys unless we commit to doing #322:14
*** catintheroof has joined #openstack-keystone22:14
*** catintheroof has quit IRC22:14
lbragstadonly so that we don't confuse people22:15
*** catintheroof has joined #openstack-keystone22:15
jamielennoxo/22:15
lbragstadjamielennox o/22:16
lbragstadrderose but yeah - that totally makes more sense22:16
jamielennoxsorry, i haven't looked over the spec yet22:16
lbragstadrderose I'll reparse the spec now that I have this understand22:16
lbragstadunderstanding*22:16
rderosejamielennox: what are your thoughts on treating api keys as credentials vs tokens22:16
jamielennoxrderose: they are definitely not tokens22:16
rderosejamielennox: https://review.openstack.org/#/c/438761/22:16
jamielennoxthey should be creentials22:16
jamielennoxthe same fetch scoped token workflow should apply22:17
rderoseyeah, that's my thought22:17
lbragstadjamielennox so you wouldn't want the traditional API workflow at all?22:17
lbragstadtraditional API key workflow*22:17
jamielennoxlbragstad: what's the traditional API workflow?22:17
jamielennoxoh22:17
rderosejamielennox: All calls made using that service object will include your API key22:17
lbragstadit's a token that I can use to authenticate - versus an application specific password that I have to use to authenticate to get a token22:18
jamielennoxwould a api key as credential not be typical?22:18
jamielennoxi mean you can't compare this to aws because it does everything via long lived cred ids22:18
lbragstadjamielennox that seems to be the million dollar question22:18
rderosejamielennox: agree22:18
lbragstadjamielennox well - api keys are not an AWS only thing22:18
openstackgerritMerged openstack/pycadf master: Updated from global requirements  https://review.openstack.org/44513522:18
lbragstadjamielennox you can get API keys for other services22:19
jamielennoxlbragstad: but for at least the "application specific password" concept, google for one definitiely does it as a password22:19
jamielennoxso we've always had a bearer token problem, i think that gets larger if all of a sudden your "token" lives forever22:19
jamielennox(still having only glanced at the spec)22:19
rderosejamielennox lbragstad: https://developers.google.com/api-client-library/python/guide/aaa_apikeys22:20
lbragstadyeah - that is true22:20
lbragstadrderose that seems like a token flow22:21
lbragstadnot a credential flow22:21
rderoseyeah, it does22:21
rderosewith google, the key is used to make api calls22:22
lbragstadyeah - so they don't do the step that would be similar to us getting a token and using that to make the API call22:22
jamielennoxinteresting, so i was thinking more of the application specific password that you use for things like IMAP access where you can't 2FA22:22
rderoselbragstad: google is authenticating the api_key, so still is credential22:25
rderoseit's just your not having to go get a bearer token22:25
lbragstadrderose right to isn't it the same thing as a token?22:26
lbragstadthat lives forever?22:26
*** chlong has quit IRC22:26
lbragstadso*22:26
rderoselbragstad: I think so, but looking22:27
jamielennoxrderose: some comments22:27
lbragstadrderose i'll parse this tonight yet22:28
jamielennoxbut yea, that's more or less what i imagined, access_key -> token, not something you can use directly22:28
lbragstadjamielennox good to know22:28
*** nkinder has quit IRC22:28
lbragstadjamielennox they both solve the problem that we have, so i think i'm fine with either,22:28
lbragstadjamielennox i just don't want to call it an API key if that's not what it is22:28
jamielennoxlbragstad: worth bringing up at a meeting, but i would vote for keeping the token flow we have including timeouts22:29
lbragstadjamielennox rderose makes sense22:29
jamielennoxlbragstad: yea, can name them whatever we like22:29
lbragstadjamielennox rderose do you mind if I put both of you down for that topic?22:30
rderoselbragstad: sure22:30
jamielennoxlbragstad: sure22:30
*** aojea has quit IRC22:30
* jamielennox sets that alarm 22:30
*** aojea has joined #openstack-keystone22:31
lbragstadjamielennox rderose thanks22:32
rderoselbragstad: cool, thank you22:32
lbragstadrderose no problem - thanks for walking me through it22:32
lbragstad:)22:32
* lbragstad runs to get some things done 22:33
*** aojea has quit IRC22:35
*** dave-mccowan has quit IRC22:36
*** catintheroof has quit IRC22:40
*** nkinder has joined #openstack-keystone22:42
*** chris_hultin is now known as chris_hultin|AWA22:50
*** henrynash has joined #openstack-keystone22:52
*** henrynash has quit IRC23:03
*** lamt has quit IRC23:15
*** lucasxu has quit IRC23:19
openstackgerritMerged openstack/keystone master: Updated from global requirements  https://review.openstack.org/44508523:20
*** jaugustine has quit IRC23:22
*** erlon has quit IRC23:25
*** henrynash has joined #openstack-keystone23:52
openstackgerritColleen Murphy proposed openstack/keystone master: Fix description for 204 response  https://review.openstack.org/44524523:59

Generated by irclog2html.py 2.14.0 by Marius Gedminas - find it at mg.pov.lt!