Monday, 2017-07-10

*** thorst has joined #openstack-keystone00:02
*** thorst has quit IRC00:08
*** thorst has joined #openstack-keystone00:36
*** zhurong has joined #openstack-keystone00:48
*** dave-mccowan has joined #openstack-keystone01:33
*** thorst has joined #openstack-keystone01:52
*** ducttape_ has joined #openstack-keystone01:54
*** thorst has quit IRC01:56
*** ducttape_ has quit IRC01:59
*** lbragstad has joined #openstack-keystone02:10
*** ChanServ sets mode: +o lbragstad02:10
*** zzzeek_ has joined #openstack-keystone02:30
*** zhurong has quit IRC02:43
*** aojea has joined #openstack-keystone03:11
*** aojea has quit IRC03:15
*** ducttape_ has joined #openstack-keystone03:38
*** ducttap__ has joined #openstack-keystone03:40
*** ducttape_ has quit IRC03:40
*** ducttap__ has quit IRC03:44
*** Dinesh_Bhor has joined #openstack-keystone03:52
*** thorst has joined #openstack-keystone03:53
*** thorst has quit IRC03:57
*** lbragstad has quit IRC04:04
*** dave-mccowan has quit IRC04:05
*** ducttape_ has joined #openstack-keystone04:42
*** ducttape_ has quit IRC04:44
*** ducttape_ has joined #openstack-keystone04:44
*** zhurong has joined #openstack-keystone04:46
*** ducttape_ has quit IRC04:46
*** ducttape_ has joined #openstack-keystone04:49
*** ducttape_ has quit IRC04:53
*** tobberydberg has joined #openstack-keystone05:29
*** ducttape_ has joined #openstack-keystone05:49
*** thorst has joined #openstack-keystone05:54
*** ducttape_ has quit IRC05:55
*** thorst has quit IRC05:59
*** rvba has joined #openstack-keystone06:28
*** rvba has quit IRC06:28
*** rvba has joined #openstack-keystone06:28
*** rcernin has joined #openstack-keystone06:47
*** belmoreira has joined #openstack-keystone06:54
*** Shunli has joined #openstack-keystone06:59
*** clenimar has quit IRC07:04
*** harlowja has quit IRC07:11
*** zsli_ has joined #openstack-keystone07:14
*** Shunli has quit IRC07:17
*** aojea has joined #openstack-keystone07:21
*** tesseract has joined #openstack-keystone07:36
*** nicolasbock has joined #openstack-keystone07:37
*** masber has quit IRC07:40
*** masber has joined #openstack-keystone07:53
*** namnh has joined #openstack-keystone07:54
*** thorst has joined #openstack-keystone07:54
*** ducttape_ has joined #openstack-keystone07:58
*** zzzeek has quit IRC08:00
*** thorst has quit IRC08:00
*** zzzeek has joined #openstack-keystone08:02
*** ducttape_ has quit IRC08:03
*** jistr|off is now known as jistr08:25
*** afazekas|away is now known as afazekas08:34
*** namnh has quit IRC08:39
*** slunkad has joined #openstack-keystone08:59
*** ducttape_ has joined #openstack-keystone08:59
*** mdavidson has joined #openstack-keystone09:04
*** ducttape_ has quit IRC09:04
*** mvk has joined #openstack-keystone09:21
*** thorst has joined #openstack-keystone09:23
*** zsli_ has quit IRC09:27
*** thorst has quit IRC09:28
*** ducttape_ has joined #openstack-keystone10:02
*** ducttape_ has quit IRC10:04
*** ducttape_ has joined #openstack-keystone10:05
*** ducttape_ has quit IRC10:10
*** sjain has joined #openstack-keystone10:12
openstackgerritSamriddhi proposed openstack/keystone master: Expanded the best practices subsection in devdocs  https://review.openstack.org/47654110:23
openstackgerritSamriddhi proposed openstack/keystone master: Reorganised developer documentation  https://review.openstack.org/47660610:24
openstackgerritSamriddhi proposed openstack/keystone master: Added new subsections to developer docs  https://review.openstack.org/47663510:25
openstackgerritSamriddhi proposed openstack/keystone master: Added configuration options using oslo.config  https://review.openstack.org/47963110:52
openstackgerritSamriddhi proposed openstack/keystone master: Added configuration references to documentation  https://review.openstack.org/47454310:52
*** ducttape_ has joined #openstack-keystone11:06
*** ducttape_ has quit IRC11:10
*** edmondsw has joined #openstack-keystone11:25
*** edmondsw has quit IRC11:25
*** edmondsw has joined #openstack-keystone11:25
samueldmqmorning11:26
*** tobberyd_ has joined #openstack-keystone11:31
*** shuyingya has joined #openstack-keystone11:34
*** tobberydberg has quit IRC11:35
*** tobberyd_ has quit IRC11:36
*** shuyingya has left #openstack-keystone11:36
*** sjain_ has joined #openstack-keystone11:36
*** sjain has quit IRC11:38
samueldmqsjain_: morning11:38
sjain_Hi samueldmq: morning :)11:39
*** raildo has joined #openstack-keystone11:51
*** thorst has joined #openstack-keystone11:53
*** dave-mccowan has joined #openstack-keystone11:55
*** d0ugal has joined #openstack-keystone12:04
*** d0ugal has quit IRC12:04
*** d0ugal has joined #openstack-keystone12:04
openstackgerritSamriddhi proposed openstack/keystone master: Added configuration options using oslo.config  https://review.openstack.org/47963112:05
*** d0ugal has quit IRC12:12
*** brad[] has quit IRC12:16
*** sjain_ has quit IRC12:17
*** brad[] has joined #openstack-keystone12:18
*** bhagyashris has joined #openstack-keystone12:30
*** iurygregory has quit IRC12:31
*** zhurong has quit IRC12:36
*** sjain has joined #openstack-keystone12:38
*** jmlowe has quit IRC12:40
*** iurygregory has joined #openstack-keystone12:41
bhagyashrissamueldmq: itted working progress (proposed solution for [1]) patch: https://review.openstack.org/#/c/478143/ but that is not that much feasible so Is the logging the request and "request_id" at info level is feasible in the keystoneauth12:44
bhagyashrissamueldmq: Hi, I need your opinion Need your opinion12:44
bhagyashrissamueldmq: please ignore above msg mistakenly send it12:45
samueldmqbhagyashris: no problem12:45
bhagyashrissamueldmq: Similar to all python-*clients I have proposed patch in openstacksdk [1]: https://review.openstack.org/#/c/478143/to return request-id from all openstacksdk API's but there is a objection saying why can not we just refer to the request-id logged in keystoneauth. The proposal is to change to logging request-d from DEBUG level [2] to INFO level. Please refer to the Brain's proposal.12:45
samueldmqbhagyashris: I will try to keep an eye on that, and also copy others. this week is gonna be kinda super busy for me, but I will try, thanks for the heads up12:47
samueldmqbhagyashris: also, try to get a full working version (removing from WIP) and get tests passing12:47
samueldmqwill help getting reviews :)12:48
bhagyashrissamueldmq: Actaully I just need your opinion regarding logging request-d from DEBUG level [2] to INFO level.12:50
samueldmqbhagyashris: I am not seeing any logging in https://review.openstack.org/#/c/47814312:51
bhagyashrissamueldmq: I have submitted patch in pyhton-openstacksdk and on that I have got comment to make this change in keystoneauth as I have mentioned above because the patch [1] proposal  that I have submitted is anyways will not be accepted.12:52
samueldmqbhagyashris: I see Brian's comments now12:52
bhagyashrissamueldmq: yeah that imp12:52
samueldmqif you want to see what's wrong with your call (check the logs)12:52
samueldmqif you are checking what's wrong, debug should be fine (you're effectively debugging it)12:53
bhagyashrissamueldmq: yes12:53
bhagyashrissamueldmq: but for operators point of view12:54
*** d0ugal has joined #openstack-keystone12:54
*** d0ugal has quit IRC12:54
*** d0ugal has joined #openstack-keystone12:54
samueldmqbhagyashris: for operators, is it bad to have debug level for debugging?12:54
bhagyashrissamueldmq: it should be info IMO12:55
samueldmqbhagyashris: so it would be logging as info the request-id for every single request that hits keystoneauth?12:56
bhagyashrissamueldmq: yes12:57
samueldmqbhagyashris: ok, I dont see why it'd need to be logged as info. I'd like to hear from  mordred morgan or jamielennox on that12:58
samueldmqsince they have a broader knowledge than me on request-ids12:58
samueldmqmordred: morgan: jamielennox: there is a proposal to log request-id at INFO level (it's currently under DEBUG). thoughts?12:59
*** d0ugal has quit IRC12:59
*** catintheroof has joined #openstack-keystone13:04
*** masber has quit IRC13:06
*** d0ugal has joined #openstack-keystone13:08
*** lbragstad has joined #openstack-keystone13:08
*** ChanServ sets mode: +o lbragstad13:08
bhagyashrismordred: morgan: jamielennox: Hi, waiting for some thoughts as mentioned above.13:12
cmurphysdague might also be a good person to ask about that13:16
bhagyashriscmurphy: ok thanks.13:18
openstackgerritSamriddhi proposed openstack/keystone master: Replaced policy.json with policy.yaml  https://review.openstack.org/48213913:19
openstackgerritMatthew Edmonds proposed openstack/keystone master: fix identity:get_identity_providers typo  https://review.openstack.org/48214213:22
*** ducttape_ has joined #openstack-keystone13:24
edmondswI'm not sure what the keystone stance is on backward compatibility and changes like ^13:25
edmondswbut with all the changes being made for policy in pike, it seems like a good time to fix that one way or another13:26
*** ducttap__ has joined #openstack-keystone13:26
*** bknudson has joined #openstack-keystone13:28
*** ducttape_ has quit IRC13:29
*** belmorei_ has joined #openstack-keystone13:31
*** belmoreira has quit IRC13:32
bretonedmondsw: so... what was the default rule for the action before the change?13:33
bretonedmondsw: could i as non-admin get an identity provider?13:33
*** zzzeek_ has quit IRC13:34
edmondswbreton admin required13:37
edmondswbreton I didn't change the default.. just the name of the rule13:40
edmondswfrom plural to singular, since it's a get, not a list13:40
*** sjain has quit IRC13:45
*** sjain has joined #openstack-keystone13:46
edmondswsamueldmq yeah, that's what I was trying to start a discussion about ^13:49
edmondswI can certainly add a release note13:50
edmondswthat all?13:50
samueldmqedmondsw: yeah, I am not sure it's worth it, and we don't have deprecation workflow for those things13:50
samueldmqedmondsw: if we had a keystone doctor check on the policy rules, to make sure they're all there and valid or somehting13:52
samueldmqthat'd certainly help in cases like that one13:52
edmondswyeah13:52
edmondswcan't check that they're all there, because they always will now that there are defaults in the code, but you could check if there are rules that *aren't* used13:53
samueldmqedmondsw: yes, and fail if there are any13:54
edmondswwell not fail... warn13:55
edmondswbecause someone could be extending keystone and need those extra rules for that, and we wouldn't know13:55
bretonedmondsw: did the old name work? And really prevented non-admin from getting an idp?13:59
edmondswbreton I assume so... I don't use federation, so...14:00
samueldmqedmondsw: if we just warn it would be easier for someone to ignore and that go in (e.g your change) without being noticed14:00
samueldmqthey can just ignore the failure (saying the list of not recognized policies) if they have something besides what we offer14:00
bretonedmondsw: i have a slight feeling that it didn't work14:01
sjainHi, can someone please take a look at this patch and suggest why the tests are failing, https://review.openstack.org/#/c/479631/14:01
*** gagehugo_ has joined #openstack-keystone14:02
*** superdan is now known as dansmith14:02
sjainIt is giving me unauthorized access message in error14:02
*** d0ugal has quit IRC14:03
bretonso the default is `"default": "rule:admin_required"`14:04
bretondepending on this default rule we operators can be either covered or no14:05
edmondswbreton the default rule is no longer used/relevant since we moved policy into code14:07
edmondswbecause that rule is only checked if the rule isn't found, and with policy in code the rule will always be found... in code, if not in policy.yaml14:07
bretonedmondsw: i think we should treat this as a micro security bug. Because of it if some operator modified policy.json and changed rule for get_identity_providers, or changed the "default" rule, it didn't get applied.14:07
*** gyee has joined #openstack-keystone14:07
bretonedmondsw: but "get_identity_provider" is never found, neither in your code, nor before14:08
bretonedmondsw: well, *neither with policy-in-code, nor before policy-in-code14:08
edmondswbreton let me check if the code looked for get_identity_provider or get_identity_providers in ocata...14:09
bretonedmondsw: it's "get_identity_provider" what is protected by @protected decorator, not "get_identity_providers". "get_identity_prodivers" action never existed, so that rule applied to nothing14:09
bretonedmondsw: i checked already14:09
bretonedmondsw: it's broken there14:10
edmondswk14:11
edmondswsamueldmq if breton's right about this being broken in ocata, I think that should negate your concerns with the change14:12
bretonmorgan: lbragstad: what's your opinion on this bug being of minor security type?14:12
edmondswbreton good catch14:12
*** ducttap__ has quit IRC14:13
*** raildo has quit IRC14:14
*** rmascena has joined #openstack-keystone14:14
*** ducttape_ has joined #openstack-keystone14:14
openstackgerritMatthew Edmonds proposed openstack/keystone master: fix identity:get_identity_providers typo  https://review.openstack.org/48214214:15
samueldmqedmondsw: yeah I agree with breton14:17
samueldmqthat's an unfortunate bug :(14:17
bretonit might be worth cheking other rules14:18
bretonthat they match respective controllers14:18
bretonand maybe write some unit-tests that would check the match14:18
edmondswbreton agreed14:21
mordredsamueldmq, bhagyashris: so - in shade (fwiw, I made a specific logger for request ids - shade.request-ids) to allow a user/operator to decide if they want to see or not see request ids14:23
*** chlong_ has joined #openstack-keystone14:24
mordredrequest ids at the info level by default in keystoneauth would be VERY chatty for people just using keystoneauth to make their HTTP requests14:24
*** bombart has joined #openstack-keystone14:24
mordredbut - I think there's also a great argument to be made for being able to turn them on easily and get them at the info level14:25
*** ducttape_ has quit IRC14:25
mordredso pehaps including them, as we do now, in the debug level of the http layer "request to {url} used request id {id}" - but also emit in the same place a similar message to a request_ids logger at the INFO level14:26
mordred(turns out python logging is incredibly powerful 07708114:26
mordredand being able to configure what you want to see at the application layer is really useful)14:26
*** ducttape_ has joined #openstack-keystone14:27
*** zzzeek_ has joined #openstack-keystone14:28
bretonwe don't have "default" rule any more?14:30
*** zhurong has joined #openstack-keystone14:30
bretonwe do! ./base.py:        name='default',14:30
*** bombart has quit IRC14:31
*** chandankumar has joined #openstack-keystone14:32
edmondswbreton then that's another bug... we shouldn't14:32
edmondswit doesn't make sense with policy in code14:32
*** bombart has joined #openstack-keystone14:33
bretonedmondsw: well, it served great as a fuse14:34
edmondswa fuse?14:34
bretonwell14:35
bretonsafety valve14:35
chandankumarbreton: please have a look on this bug https://bugs.launchpad.net/keystone/+bug/1701541 thanks :-)14:35
openstackLaunchpad bug 1701541 in tempest "Keystone v3/roles has differnt response for HEAD and GET (again)" [Undecided,New]14:35
*** sjain has quit IRC14:35
* breton 's english in this stuff is not good14:35
bretonchandankumar: i have no idea what to do with it :p14:37
chandankumarbreton: whom can i catch for the same.14:37
chandankumarfrom keystone side.14:37
edmondswbreton your english was fine... but I'm not following how it was a fuse / safety valve14:39
edmondswbreton I opened https://bugs.launchpad.net/keystone/+bug/170339214:40
openstackLaunchpad bug 1703392 in OpenStack Identity (keystone) "default rule no longer applies with policy in code" [Undecided,New]14:40
*** belmorei_ has quit IRC14:41
*** phalmos has joined #openstack-keystone14:42
openstackgerritMatthew Edmonds proposed openstack/keystone master: remove default rule  https://review.openstack.org/48216414:46
*** aselius has joined #openstack-keystone14:48
*** toddnni has quit IRC14:48
*** zhurong has quit IRC14:56
*** rcernin has quit IRC14:57
*** chlong_ has quit IRC15:16
bretonedmondsw: well, if there was no default rule, what would be the rule for get_identity_provider?15:18
edmondswthe one we define once the bug I opened is fixed15:19
edmondswbreton all the things we check *should* be defined, so there is no need for a default rule15:19
*** ducttape_ has quit IRC15:19
edmondswif we miss something, that's a bug... one we shouldn't hide by having a default rule that makes things look like they're working15:20
edmondswwhen they're not working as expected...15:20
edmondswbreton ^15:20
*** d0ugal has joined #openstack-keystone15:20
*** d0ugal has quit IRC15:20
*** d0ugal has joined #openstack-keystone15:20
bretonedmondsw: if we remove default rule, who can access list_roles_for_trust?15:22
edmondswbreton whether or not we remove default rule, the answer is the same... everyone: https://github.com/openstack/keystone/blob/2edcfb9fe7b74340ff0220e46e8099a4c0732115/keystone/common/policies/trust.py#L2615:23
bretonedmondsw: so the default rule is not operational now?15:24
edmondswbreton it is... sortof15:24
edmondswit would get used if there was a mismatch where code checks for a rule but that rule is not defined in code15:25
edmondswthat should never happen though... that's a bug15:25
edmondswa perfect example is the get_identity_provider bug I just opened15:25
edmondswthat's the only case where default rule would get checked15:26
bretonedmondsw: is there a unit test for it? Or maybe you could show me the code that does that?15:26
edmondswbreton that does what?15:26
bretonedmondsw: the check of "default" rule15:27
edmondswbreton it's in oslo.policy: https://github.com/openstack/oslo.policy/blob/master/oslo_policy/policy.py#L21315:28
*** ducttape_ has joined #openstack-keystone15:30
*** chlong_ has joined #openstack-keystone15:30
bretonok, my bad15:31
bretoni thought that default rule is a replacement for empty rule15:31
edmondswnp15:35
breton"identity:delete_trust": ""15:36
* breton sighs15:36
edmondswbreton ooo... yeah, ugh15:36
edmondswbreton you gonna open a bug on that I hope?15:37
bretonedmondsw: well, no :p we are covered there in the code15:38
edmondswbreton did they mixup delete_trust and create_trust?15:38
edmondswI could see create_trust being '' because there can't be an owner yet, right?15:38
edmondswor is that checking owner from the request?15:39
bretonedmondsw: https://git.openstack.org/cgit/openstack/keystone/tree/keystone/trust/controllers.py#n23215:39
edmondswI haven't done much with trusts, not even sure if there is an owner in the request15:39
edmondswbreton ok good15:40
openstackgerritAndy McCrae proposed openstack/keystone master: [TEST] Test OSA upgrade job's status.  https://review.openstack.org/48218915:41
openstackgerritMatthew Edmonds proposed openstack/keystone master: don't validate trust in policy  https://review.openstack.org/48219015:47
edmondswbreton ^15:47
*** gongysh has joined #openstack-keystone15:51
*** d0ugal has quit IRC15:56
*** aojea has quit IRC16:03
*** chlong_ has quit IRC16:06
*** gongysh has quit IRC16:15
*** chlong_ has joined #openstack-keystone16:20
openstackgerritEric Fried proposed openstack/keystoneauth master: Expand some discover.py docstrings  https://review.openstack.org/48220716:22
*** amyge has joined #openstack-keystone16:33
amygeHi I have a question about the keystone token. If I have 10 commands in a shell script and I pass in a valid token which created by myself. will the script generate 10 new tokens from the one I pass in? or will it just create one new token from the one I pass in and use it for all 10 commands? or will it use the token I pass in?16:35
amygeI think I'm a bit confused about the specific definition of 'scenario' in 'one token per scenario' during the discussion I had here last Friday.16:37
*** harlowja has joined #openstack-keystone16:37
*** chlong_ has quit IRC16:38
openstackgerritEric Fried proposed openstack/keystoneauth master: Expand some discover.py docstrings  https://review.openstack.org/48220716:38
*** lwanderley has joined #openstack-keystone16:40
*** tesseract has quit IRC17:01
*** bombart has quit IRC17:01
*** sjain has joined #openstack-keystone17:02
*** aojea has joined #openstack-keystone17:09
morganamyge: it really depends on how you invoke the commands. It could use the token you created, it may generate 10 new tokens based upon the token you created, etc. There are many variations on the invocations of CLI tools17:10
samueldmqmordred: thanks, a separate log for request-ids might make sense for keystoneauth too17:13
*** aojea has quit IRC17:13
*** aojea has joined #openstack-keystone17:13
samueldmqbhagyashris:  ^17:13
samueldmqlet's hear more from others and see what we get :)17:13
sjainsamueldmq: can you review this please, https://review.openstack.org/#/c/476541/, should be an easy one, you gave +2 to this before :)17:15
*** lwanderley has quit IRC17:16
samueldmqsjain: sure17:16
sjainthanks :)17:16
amygemorgan: I see. for example if I am just trying to generate nova, neutron and bunch of other clients in the command, and do some basic information list like 'nova service-list', 'flavor-list'... will it generate new token for each command?17:23
*** ducttape_ has quit IRC17:28
*** sjain has quit IRC17:29
*** lwanderley has joined #openstack-keystone17:37
openstackgerritEric Fried proposed openstack/keystoneauth master: normalize_version_number([1]) => (1, 0) and docs  https://review.openstack.org/48130917:37
*** aojea has quit IRC17:48
*** jmlowe has joined #openstack-keystone17:58
*** ducttape_ has joined #openstack-keystone18:00
*** aojea has joined #openstack-keystone18:01
*** dmellado has quit IRC18:02
*** dmellado has joined #openstack-keystone18:02
lbragstadbreton: sorry - just got your ping, in meeting all day today18:04
lbragstadbreton: i'll review the conversation in a bit and check it out18:05
*** aojea has quit IRC18:06
rmascenalbragstad, hey sir, can you add this patch in your review list? https://review.openstack.org/#/c/480287/ I'm looking to send the backport asap18:22
*** rmascena is now known as raildo18:22
lbragstadraildo: sure thing - i'll review today18:23
raildolbragstad, thanks :)18:23
lbragstadraildo: thank you for the backport18:23
lbragstadraildo: is that going all the way back to stable/newton?18:23
lbragstadlooks like it18:24
raildolbragstad, yeap18:24
raildoocata and newton18:24
lbragstadraildo: then this can be reproposed? https://review.openstack.org/#/c/469514/18:25
raildolbragstad, exactly, I was thinking in send a new patch and ask for abandon this change18:27
raildosounds good for you?18:27
lbragstadraildo: works for me18:28
raildook18:28
lbragstadraildo: https://review.openstack.org/#/c/480287/4 looks good18:28
lbragstadwant to add a release note?18:28
raildosure, I can do it :)18:28
lbragstadhttps://docs.openstack.org/keystone/latest/devref/development_best_practices.html18:28
*** aojea has joined #openstack-keystone18:39
morganamyge: if you use --os-token (and provide the endpoints via... --os-endpoint? [cc mordred, stevemar, lbragstad]) it should not generate new tokens, but if you don't have a catalog it will.18:46
amygemorgan: I see~~ and just one more question, is there a way in python/command line for me to check if a new token is generated?(e.g. in osclient I can do osclient.keystone.auth_ref.auth_token)18:57
morganwith debug output, possibly18:58
morgannot 100% sure on that18:58
bknudsonwe had code in keystoneclient to cache the token in a keystore but that seems to have disappeared with keystoneauth18:58
bknudsonnot sure if it ever really worked… probably doesn't now especially since the version of keystore is pinned.18:58
catintheroofhi guys, quick question, does keystone support trust relationship for services like nova and neutron to comunicate with keystone without user/passwd right? do i have some documentation to read on setting that up ?19:00
amygemorgan: you mean '--debug' in my command? will try that19:02
bknudsoncatintheroof: keystone supports tokenless authentication https://docs.openstack.org/keystone/latest/advanced-topics/configure_tokenless_x509.html . I've never used it.19:03
catintheroofbknudson: thanks!19:05
mordredmorgan, amyge: re-using tokens across different clients in a shell script like that is ultimately going to get to a hard-to-understand place - if it were me, I'd just write whatever you're scripting in python instead - but I dont have context, so that might not be possible19:05
openstackgerritEric Fried proposed openstack/keystoneauth master: Make Discover.version_data accept null max_version  https://review.openstack.org/48225019:06
amygemordred: yeah I'm actually writing it in python. but just wanted to understand more about using the same token across clients so I asked about shell script~19:07
amygemordred, morgan: btw, in python, I know that if I cache and use the same session across clients, I will be able to use the same token. but is there any method that I can call to check if I'm using the same token across clients?19:09
mordredamyge: you can just look at the token in the session with session.get_token()19:10
mordredamyge: if you pass the same session to each client, then ksa will use the same token (it only has one token)19:10
amygemordred: oh i see. thanks!^^19:11
mordredamyge: although if you're writing python and using different clients from python-*client I'd ALSO recommend not doing that :)19:11
mordredbut that's a whole different issue19:11
*** jmlowe has quit IRC19:14
amygemordred: i see. just got a question for caching session then. right now I'm caching the session in osclient object, but when I create a new osclient and update auth_ref, I will have to generate a new session, which will generate a new token. Is there better way to cache session so that I can use the token longer?19:17
mordredamyge: what's osclient from?19:20
openstackgerritEric Fried proposed openstack/keystoneauth master: Expand some discover.py docstrings  https://review.openstack.org/48220719:21
openstackgerritRaildo Mascena proposed openstack/keystone master: Fixing flushing tokens workflow  https://review.openstack.org/48028719:23
*** ducttape_ has quit IRC19:23
*** ducttape_ has joined #openstack-keystone19:23
*** lwanderley has quit IRC19:24
*** tobberydberg has joined #openstack-keystone19:38
*** tobberydberg has quit IRC19:43
*** jessegler has joined #openstack-keystone19:43
openstackgerritEric Fried proposed openstack/keystoneauth master: Nix EndpointData.get_versioned_data(authenticated)  https://review.openstack.org/48226019:45
*** edmondsw_ has joined #openstack-keystone19:53
openstackgerritEric Fried proposed openstack/keystoneauth master: Fix _run_discovery caching  https://review.openstack.org/48175419:56
*** edmondsw has quit IRC19:56
*** edmondsw has joined #openstack-keystone19:57
*** d0ugal has joined #openstack-keystone19:57
*** edmondsw_ has quit IRC19:59
lbragstadraildo: one comment on the release note - otherwise it looks good20:06
lbragstadraildo: thank you!20:06
raildolbragstad, thanks for the review, I'll fix it and send a new patch set now20:08
openstackgerritRaildo Mascena proposed openstack/keystone master: Fixing flushing tokens workflow  https://review.openstack.org/48028720:11
lbragstadcc stevemar ^20:12
openstackgerritEric Fried proposed openstack/keystoneauth master: Miscellaneous cleanup in discover.py  https://review.openstack.org/48227120:16
openstackgerritSamuel Pilla proposed openstack/python-keystoneclient master: WIP: Add project tags to keystoneclient  https://review.openstack.org/48122320:29
*** ducttape_ has quit IRC20:31
*** nicolasbock has quit IRC20:34
*** ducttape_ has joined #openstack-keystone20:34
*** rderose has joined #openstack-keystone20:34
openstackgerritEric Fried proposed openstack/keystoneauth master: normalize_version_number([1]) => (1, 0) and docs  https://review.openstack.org/48130920:38
*** thorst has quit IRC20:42
*** aojea has quit IRC20:44
*** thorst has joined #openstack-keystone20:45
*** aojea has joined #openstack-keystone20:46
*** aojea has quit IRC20:46
*** aojea has joined #openstack-keystone20:46
*** thorst has quit IRC20:49
*** d0ugal has quit IRC20:52
*** catintheroof has quit IRC20:53
*** thorst has joined #openstack-keystone21:00
*** phalmos has quit IRC21:11
*** raildo has quit IRC21:13
*** sghosh has quit IRC21:14
*** dklyle has joined #openstack-keystone21:18
*** dgedia has quit IRC21:18
*** david-lyle has quit IRC21:19
*** aojea has quit IRC21:28
*** aojea has joined #openstack-keystone21:28
*** aojea has quit IRC21:34
*** rderose has quit IRC21:37
*** zzzeek_ has quit IRC21:37
*** eandersson has joined #openstack-keystone21:38
eanderssonWe have an interesting issue with service catalog21:39
eanderssonWe are using the file based catalog21:39
eanderssonand we are getting a list of dictionaries21:39
eanderssonwhich causes calls like this to pick the first region in the list21:40
eanderssonhttps://github.com/openstack/horizon/blob/master/openstack_dashboard/api/base.py#L26221:40
*** zzzeek_ has joined #openstack-keystone21:40
eanderssonWe have to fix these type of issues using patches like this http://paste.openstack.org/show/614967/21:40
*** gongysh has joined #openstack-keystone21:47
*** rderose has joined #openstack-keystone21:57
*** rderose has quit IRC21:58
*** rderose has joined #openstack-keystone21:58
*** thorst has quit IRC22:02
nkinderlbragstad: is there anyone working on the application credentials implementation?22:03
jamielennoxsamueldmq: agree with mordred, putting request-id at info would be very noisy in logs, however i'd be ok with putting a new handler name in so that anyone who wants that info could turn up the logging for just that22:11
mordredeandersson: liucky for you - we just added apis to keystoneauth to do all of those things for you22:12
mordredeandersson: I'm going to strongly recommend that you migrate to using the keystoneauth library - most of that file, from the looks of it, will be able to be deleted22:13
mordredeandersson: I'm in another meeting-  but we should connect - there's really no reason for y'all to have your own copy of service and version discovery directly in horizon anymore22:14
mordredand it turns out it's a massively complex topic22:14
samueldmqjamielennox: ++22:15
samueldmqbhagyashris: ^ see jamielennox's comment above. same as mordred's suggestion22:15
eanderssonmordred, the above patch is for horizon22:16
eanderssonops missed your last comment22:17
*** deep-book-gk_ has joined #openstack-keystone22:18
*** deep-book-gk_ has left #openstack-keystone22:20
lbragstadnkinder: mordred is tackling that work22:23
mordrednkinder: it's on my plate - I have not started writing any code as of yet (the rest of my plate needs to burn down a bit before I can get to it in earnest)22:24
*** phalmos has joined #openstack-keystone22:27
*** aojea has joined #openstack-keystone22:30
*** phalmos_ has joined #openstack-keystone22:31
*** phalmos has quit IRC22:31
eanderssonmordred, simple question when hitting keystone get_v3_catalog are service types intended to contain all regions? e.g. dns contain regionOne, regionTwo?22:31
*** zzzeek_ has quit IRC22:32
*** bknudson has quit IRC22:34
mordredeandersson: yes22:35
mordredeandersson: you may want to check out: http://specs.openstack.org/openstack/api-wg/guidelines/consuming-catalog.html22:35
eanderssonSo the templated code does not do that22:35
*** aojea has quit IRC22:36
eanderssonPretty sure the templated catalog does not behave as intended22:36
mordredeandersson: http://paste.openstack.org/show/614968/22:37
*** ducttape_ has quit IRC22:37
mordredeandersson: there is an example from citycloud's public cloud22:37
mordredeandersson: when you say "the templated catalog" - what do you mean?22:38
eanderssontemplated backend22:39
eanderssonhttps://github.com/openstack/keystone/blob/master/keystone/catalog/backends/templated.py22:39
*** catintheroof has joined #openstack-keystone22:43
eanderssonmordred, http://paste.openstack.org/show/614969/22:43
eanderssonI would expect that the above would have the endpoints for both regions in a single dict22:45
*** ducttape_ has joined #openstack-keystone22:45
mordredthe endpoint for a service in v3 should have a list of dicts - each dict has region, interface and url22:46
mordredlike - there is no structure to handle more than one region in a single dict22:47
mordredsince region, interface and url are all keys22:47
*** zzzeek_ has joined #openstack-keystone22:50
*** ducttape_ has quit IRC22:50
openstackgerritMatthew Edmonds proposed openstack/keystone master: fix assert_admin  https://review.openstack.org/48235922:58
eanderssonmordred, so compared the result of openstack catalog list on templated vs. sql23:03
eanderssonwith the sql backend you have nova/compute with all regions23:04
eanderssonwith the templated backend you have a nova/compute per region23:05
mordredeandersson: oh - wow - looking at code there - that seems to be a very weird version od the v2 catalog23:05
mordredI especially like this: https://github.com/openstack/keystone/blob/master/keystone/catalog/backends/templated.py#L170-L17123:06
mordredmorgan: ^^ what new form of torture has eandersson found for me?23:06
eanderssonI almost feel vindicated - been working around this "issue" for so long :D23:08
mordredeandersson: :)23:09
mordredeandersson: well - honestly - the main thing we really need to do is get you out of the business of parsing service catalogs23:09
mordredeandersson: and on to the business of letting the keystoneauth library do it for you23:10
mordredbecuase if keystone is emitting catalogs that keystoneauth can't parse - well, that's a clear bug now isn't it?23:10
*** ducttape_ has joined #openstack-keystone23:12
*** thorst has joined #openstack-keystone23:17
*** ducttape_ has quit IRC23:20
*** gagehugo_ has quit IRC23:21
*** thorst has quit IRC23:21
*** rderose has quit IRC23:22
eanderssonyea - makes sense23:23
jamielennoxthe file based backend was deprecated a number of cycles ago wasn't it?23:23
jamielennoxat least particularly the one called templated, because it only produced a v2 format and then it had to be converted to v3 rather badly23:24
jamielennoxthere was a proposal (i'm pretty sure i was involved) to make it like a yaml file with a non version related format23:25
eanderssonYea - looking at the code it has never worked properly for v3 and multi-region23:25
jamielennoxbut that cloud kinda went up in smoke and so the urgency fell away23:25
eanderssonIt's not marked as deprecated in the config though23:27
jamielennoxeandersson: you're right, there's no sign of a deprecation notice23:28
jamielennoxbut i would consider it largely untested and probably broken23:29
eanderssonIt works in general I think, but breaks a couple of services (e.g. Horizon won't work with multi-region).23:30
eanderssonThe fact that the openstack client gives the wrong result probably indicates that it needs to be fixed on the keystone side23:32
eanderssonor maybe deprecated and eventually removed :D23:32
morganmordred: the templated catalog is terrible23:36
morganand it should never be used23:36
morgani advocated deleting it... but everyone said no23:36
morganbecause it's easy for CMS to deploy23:36
morganthe sad part is.. it is almost 100% not validated23:36
morganso, good luck?23:36
morganyeah untested at best23:37
morganbroken most likely23:37
mordredeandersson, morgan, jamielennox: I advocate for removed. it's broken23:39
*** edmondsw has quit IRC23:40
mordredit produces invalid catalogs23:40
eanderssongood - because we are totally not using it in PROD23:41
*** thorst has joined #openstack-keystone23:57
*** catintheroof has quit IRC23:59

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