Monday, 2017-05-15

*** openstack has joined #openstack-keystone06:57
*** aloga has quit IRC07:01
*** aloga has joined #openstack-keystone07:01
*** shuyingya has joined #openstack-keystone07:08
*** belmoreira has joined #openstack-keystone07:12
*** adriant has quit IRC07:29
*** aojea has joined #openstack-keystone07:30
*** thorst_afk has joined #openstack-keystone07:35
*** thorst_afk has quit IRC07:40
*** masber has quit IRC07:45
*** rcernin has joined #openstack-keystone07:47
*** pcaruana has joined #openstack-keystone07:47
*** zzzeek has quit IRC08:00
*** zzzeek has joined #openstack-keystone08:00
*** jaosorior has joined #openstack-keystone08:09
*** faizy_ has quit IRC08:16
*** faizy_ has joined #openstack-keystone08:16
odyssey4me_morning everyone, I've raised a bug about some ambiguity related to cache settings that I'd like to get straightened out and would appreciate some eyes:
openstackLaunchpad bug 1690756 in oslo.cache "cache 'backend' argument description is ambiguous" [Undecided,New]08:36
*** thorst_afk has joined #openstack-keystone08:36
*** odyssey4me_ is now known as odyssey4me08:36
*** andymccr_ is now known as andymccr08:36
openstackgerritzhengliuyang proposed openstack/keystone master: Update explains about credentials
*** rha has quit IRC08:48
*** rha has joined #openstack-keystone08:49
*** thorst_afk has quit IRC08:55
openstackgerritHemanth Nakkina proposed openstack/keystone master: Change url scheme passed to oauth signature verifier
openstackgerritrocky proposed openstack/keystonemiddleware master: Remove log translations in keystonemiddle
*** jistr_ is now known as jistr09:30
*** zsli_ has quit IRC09:38
*** thorst_afk has joined #openstack-keystone10:13
*** szaher_ has quit IRC10:14
*** szaher has joined #openstack-keystone10:15
*** mariusv has quit IRC10:17
*** thorst_afk has quit IRC10:18
*** piliman974 has joined #openstack-keystone10:25
*** lunarlamp has joined #openstack-keystone10:26
*** belmoreira has quit IRC10:28
*** nicolasbock has joined #openstack-keystone10:33
*** namnh has quit IRC10:34
*** vaishali has joined #openstack-keystone10:45
*** basilAB has joined #openstack-keystone10:45
*** gongysh has quit IRC10:49
*** raildo has joined #openstack-keystone10:56
*** gongysh has joined #openstack-keystone10:56
*** dikonoor has joined #openstack-keystone10:58
*** lamt has joined #openstack-keystone10:59
*** lamt has quit IRC11:00
*** mvk has quit IRC11:11
*** thorst_afk has joined #openstack-keystone11:14
*** thorst_afk has quit IRC11:15
*** thorst_afk has joined #openstack-keystone11:16
*** gongysh has quit IRC11:21
*** shuyingya has quit IRC11:32
*** shuyingy_ has joined #openstack-keystone11:32
*** lunarlamp is now known as mariusv11:32
*** mvk has joined #openstack-keystone11:40
bretoni have a token. How do i make all requests with it using keystoneauth sessions?12:07
bretoni cannot fetch another one with it because it is trust-scoped, so i cannot use "token" plugin12:09
jamielennoxbreton: so you can use TokenEndpoint - but as implied you need to know the endpoints12:12
jamielennoxi mean there's no catalog so you have to specify what to actually communicate to12:12
bretonjamielennox: what i am trying to solve is . In Mistral novaclient is created here:
openstackLaunchpad bug 1690787 in Mistral "cron trigger uses trust-scoped token to create another token" [High,New]12:14
bretonjamielennox: i guess they are passing a token id and auth_url12:17
bretonjamielennox: can we tell keystoneauth to just fetch token body, without re-auth?12:18
*** edmondsw has joined #openstack-keystone12:20
bretonwhy doesn't keystone allow to use a trust-scoped token for getting another token?12:21
*** edmondsw has quit IRC12:25
*** edmondsw has joined #openstack-keystone12:26
jamielennoxbreton: i think there is actually a way to do that now - but it never got implemented12:27
jamielennoxbreton: there's a way you can fetch at least the catalog of an existing token12:28
jamielennoxbut it wasn't around when we started12:28
jamielennoxbreton: i'm guessing you can't rescope to something else, i'm not sure exactly12:28
jamielennoxbut you don't want to allow a delegated token to be reused for a different purpose12:29
*** edmondsw_ has joined #openstack-keystone12:29
jamielennoxany reason you have a token_id, it's a painful way to do things as it can expire any itme12:29
*** edmondsw has quit IRC12:30
breton  68         # Do not allow tokens used for delegation to12:30
breton  69         # create another token, or perform any changes of12:30
breton  70         # state in Keystone. To do so is to invite elevation of12:30
breton  71         # privilege attacks12:30
jamielennoxyea, makes sense12:31
bretoni tried to track this in git history, and it goes back to 2013 :) i still couldn't find the commit that introduced this message12:31
jamielennoxrealistically we should never have allowed tokens to be rescoped from project to project - but that was super hard to remove12:31
jamielennoxthere was a config flag to prevent token rescoping in keystone - it broke a lot of things12:31
bretonso i guess what mistral should do it switch to sessions and plugins12:32
breton*do is12:32
jamielennoxbreton: yes!12:33
jamielennoxgah, if you're trying to work around that then absolutely switch12:33
*** erhudy has joined #openstack-keystone12:36
*** belmoreira has joined #openstack-keystone12:43
*** flaper87 has quit IRC12:43
*** flaper87 has joined #openstack-keystone12:44
*** flaper87 has quit IRC12:45
*** flaper87 has joined #openstack-keystone12:47
*** flaper87 has quit IRC12:47
*** flaper87 has joined #openstack-keystone12:48
*** thorst_afk has quit IRC12:49
*** dave-mccowan has joined #openstack-keystone12:51
bretonjamielennox: that's hard. They have 21 clients and each needs to be switched.12:52
ayoungbreton, I'm responsible for that rule.12:53
ayoungA trust scoped token is a fixed scope.12:53
ayoungIt can neither get a wider nor narrower scope12:54
ayoungnarrower actually should be allowed, but due to mechanism is not implemented12:54
ayoungwider is, well, problematic for obvious reasons, as I hope you can see12:54
ayoungso, the only thing a user could do is re auth as them selves and re-execute the trust:12:54
bretonayoung: well, in my case it tries to get exactly the same scope12:55
ayoungbreton, for what purpose?  Just to get the service catalog?12:55
ayoungcuz there is another rule that shows a token can't be used to get another token just to lengthen its lifespan12:55
bretonayoung: due to a bug in client.12:55
bretonayoung: keystoneauth's Token plugin uses a token to authenticate with the token12:56
ayoungbreton, I wonder if what we really need is a "fetch service catalog for token" in that case?  jamielennox ?12:57
bretonayoung: yes, that's what i'd like to see in keystoneauth auth plugins. And we'll also have to teach other clients to use that.12:58
*** shuyingy_ has quit IRC12:59
jamielennoxyea, i would be ok with that13:00
jamielennoxit has definitely come up before13:00
jamielennoxjust for 99% of cases the rescope works, and for everyone else i try and make them use sessions properly13:01
jamielennoxmy main problem i don't have a solution for is after RPC13:01
jamielennoxi got buy in to fix that, but it just isn't on my priorites ATM13:01
jamielennoxanywhere else there's a plugin you can use from auth_token13:02
jamielennoxof just build your own plugin13:02
* jamielennox out 13:06
*** jaosorior has quit IRC13:15
*** arturb has quit IRC13:17
*** ducttape_ has joined #openstack-keystone13:18
*** faizy has joined #openstack-keystone13:22
*** lbragstad has joined #openstack-keystone13:24
*** ChanServ sets mode: +o lbragstad13:24
*** johnthetubaguy has left #openstack-keystone13:24
*** faizy_ has quit IRC13:25
*** johnthetubaguy has joined #openstack-keystone13:26
*** johnthetubaguy has quit IRC13:27
*** johnthetubaguy has joined #openstack-keystone13:29
*** lbragstad has quit IRC13:29
*** lbragstad has joined #openstack-keystone13:30
*** ChanServ sets mode: +o lbragstad13:30
*** johnthetubaguy has quit IRC13:33
*** johnthetubaguy has joined #openstack-keystone13:34
*** johnthetubaguy has quit IRC13:37
*** piliman974 has quit IRC13:37
*** piliman974 has joined #openstack-keystone13:39
*** gongysh has joined #openstack-keystone13:44
*** lamt has joined #openstack-keystone13:44
*** gongysh has quit IRC13:44
*** johnthetubaguy has joined #openstack-keystone13:47
*** johnthetubaguy has quit IRC13:48
*** jdennis1 has quit IRC13:48
*** jdennis has joined #openstack-keystone13:49
*** gongysh has joined #openstack-keystone13:58
*** nkinder has quit IRC14:03
*** johnthetubaguy has joined #openstack-keystone14:04
*** shuyingya has joined #openstack-keystone14:04
*** Trident has joined #openstack-keystone14:06
*** johnthetubaguy has quit IRC14:07
*** johnthetubaguy has joined #openstack-keystone14:07
*** johnthetubaguy has quit IRC14:08
*** gongysh has quit IRC14:09
*** shuyingya has quit IRC14:09
*** johnthetubaguy has joined #openstack-keystone14:10
*** johnthetubaguy has quit IRC14:10
openstackgerritMerged openstack/pycadf master: Updated from global requirements
*** johnthetubaguy has joined #openstack-keystone14:10
*** gagehugo_ is now known as gagehugo14:14
*** nkinder has joined #openstack-keystone14:15
*** johnthetubaguy has quit IRC14:17
*** johnthetubaguy has joined #openstack-keystone14:17
*** rderose has joined #openstack-keystone14:36
*** shuyingya has joined #openstack-keystone14:38
*** thorst_afk has joined #openstack-keystone14:41
openstackgerritHemanth Nakkina proposed openstack/keystone master: Change url scheme passed to oauth signature verifier
*** thorst_afk has quit IRC14:46
*** raildo has quit IRC14:47
*** raildo has joined #openstack-keystone14:49
*** piliman974 has quit IRC14:51
*** dikonoor has quit IRC14:52
*** dikonoor has joined #openstack-keystone14:54
*** thorst_afk has joined #openstack-keystone15:03
*** tobberyd_ has joined #openstack-keystone15:05
*** tobberydberg has quit IRC15:06
*** rcernin has quit IRC15:07
*** tobberyd_ has quit IRC15:11
*** MonkXmode has joined #openstack-keystone15:19
MonkXmodeHi there. Is anyone using keystone-LDAP I can pester for a few moments?15:19
*** hemna has joined #openstack-keystone15:20
MonkXmodeI have it set up, and connecting. However, I'm experiencing a few difficulties in getting the users authenticated to the project.15:20
MonkXmodeI'm trying to understand the mapping of LDAP users to projects.15:21
MonkXmodeAm I correct in assuming a relationship between the nonlocal_user entries and the project?15:21
*** pcaruana has quit IRC15:25
bretonMonkXmode: well, LDAP user id is stored in nonlocal_user. But it's hidden from you. Assignments are for User - Role - Project.15:28
breton(actually, afaik nonlocal_user is not even an LDAP entity, it's an id_mapping_api entity)15:29
MonkXmodebreton: Thanks. I came across this when keystone was complaining of duplicate entries.15:30
MonkXmodeHow can I sort the "admin" account from being looked up in ldap?15:30
MonkXmodeAs it stands, keystone says the admin account is not assigned to any projects. Given my expectations are that the admin is "authenticated" by LDAP and admin already exists in the authorization aspect...15:32
MonkXmodeSeems like a catch22 scenario; or i'm misunderstanding something fundamental.15:33
*** rmascena has joined #openstack-keystone15:35
*** raildo has quit IRC15:35
*** shuyingya has quit IRC15:36
bretonMonkXmode: there is no such thing as "admin"15:38
bretonMonkXmode: a user can have role admin in a project15:38
bretonMonkXmode: and, if that role has permissions in policy.json, they will be able to perform that action15:39
*** tobberydberg has joined #openstack-keystone15:40
*** lbragstad has quit IRC15:40
bretonMonkXmode: today there is a bug in default policy.json; a user that has role admin on project X automatically has permissions for other projects. But that's a bug and doesn't work for other roles.15:40
*** lbragstad has joined #openstack-keystone15:40
*** ChanServ sets mode: +o lbragstad15:40
bretonMonkXmode: so, in order to get a user with access to many things, the user needs to have role "admin" on project that has is_admin_project=True15:41
*** tobberydberg has quit IRC15:44
MonkXmodebreton: I initially set up the "admin" user with admin role for the "default" domain. Now that user (admin) is within LDAP to be looked up, it's not able to see any projects. So, in order to allow the LDAP "admin" user admin permissions..15:44
MonkXmodeI thought it was a catch22 scenario. So I assumed I can either set an ignore for that user (so will look up locally only) or somehow update the permissions for the LDAP admin user.15:45
bretonwhat is catch22 scenario? :)15:46
bretonMonkXmode: you have 2 options:15:46
MonkXmodebreton: To give user: Admin the correct permissions, I need to be an admin. And I can't do that without having an admin account via LDAP :-)15:46
breton1. Set up 2 domains. One domain for LDAP and one for local users (service users and cloud admin). . This is the preffered option.15:47
breton2. Bootstrap things again. Use "keystone-manage bootstrap" and pass admin's username. From the code i see that if user admin is already there, it will attempt to create it again and will just use it.15:51
*** jaosorior has joined #openstack-keystone15:51
bretonactually there is even option 3. User admin token. Look for "admin_token" it in your keystone.conf. Please don't forget to turn it off.15:52
breton*Use admin token15:52
MonkXmodewaw. Thanks for taking the time to explain. Given there's a preferred option (I assume it's best practice rather than easier or whatever?) I should really go down that route.15:54
*** jose-phi_ has quit IRC15:55
*** jose-phillips has joined #openstack-keystone15:56
openstackgerritHemanth Nakkina proposed openstack/keystone master: Change url scheme passed to oauth signature verifier
*** gyee has joined #openstack-keystone15:58
*** aojea has quit IRC16:00
openstackgerritFelipe Monteiro proposed openstack/keystone-specs master: Patrole (RBAC) Keystone Gating
*** rderose has quit IRC16:10
*** belmoreira has quit IRC16:16
*** piliman974 has joined #openstack-keystone16:16
MonkXmodebreton: Seems to do the trick. Now I need to create a new domain. Should be simple, right? :-)16:19
bretonMonkXmode: boostrap will probably do that16:22
*** nicolasbock has quit IRC16:22
bretonMonkXmode: yes, the first option is the best practice16:22
MonkXmodebreton: Thanks for confirming.16:23
MonkXmodebreton: If I do a bootstrap for keystone, will it blitz and start afresh?16:23
MonkXmodein other words, will I lose anything, and how will bootstrap set up a new domain? :-/ :-)16:24
MonkXmodeFeel free to tell me to rtfm btw :-)16:24
MonkXmodeooh, Is it as simple as appending the project name to the bootstrap?16:26
MonkXmode... --bootstrap-project-name foo ...16:27
lbragstaddstanek: it looks like mordred is going to be taking over the api key spec16:29
*** jose-phillips has quit IRC16:31
bretonMonkXmode: oh, i misunderstood things. I guess you will have to switch back to SQL where you already have user with role admin and create a domain from there16:32
MonkXmodeYep. I'm at that point now.16:33
MonkXmodeI may get dragged away shortly for a couple hours. So if you aren't here when I return and (hopefully) get it working, i'd like to offer my thanks.16:34
bretonyou're welcome16:34
*** jose-phillips has joined #openstack-keystone16:34
*** dikonoor has quit IRC16:43
*** harlowja has joined #openstack-keystone16:44
mordredlbragstad: yah - I'll do another rev on it probably tomorrow to try to incorporate stuff from the Forum16:44
*** david-lyle has quit IRC16:46
*** dklyle has joined #openstack-keystone16:46
dstaneklbragstad: nice16:46
*** rderose has joined #openstack-keystone16:55
lbragstadmordred: awesome16:56
lbragstadrderose: o/16:58
lbragstadrderose: just fyi - but after some conversations at the forum, mordred is going to try and pick up the spec work for api keys16:58
rderoselbragstad: that's cool, especially since my approach is not really api keys anymore16:59
rderoselbragstad: it's more application passwords16:59
rderoseor application credentials16:59
rderoselbragstad: anyway...17:00
*** bkudryavtsev has joined #openstack-keystone17:01
lbragstadrderose: yeah - we might need some more discussion on it17:01
lbragstadrderose: but it sounded like either would solve the issue we were talking about at the forum17:01
rderoselbragstad: yeah, true17:01
lbragstadwhich was to enable application developers writing things on top of openstack17:01
rderoselbragstad: just feel like application passwords gets us there a lot faster17:02
rderoselbragstad: I see17:02
lbragstadrderose: true - that's totally something to consider17:02
*** nicolasbock has joined #openstack-keystone17:03
bkudryavtsevHello! Is this bug still an issue?
openstackLaunchpad bug 1671196 in OpenStack Identity (keystone) "user list for LDAP group does not contain all members" [Medium,Triaged]17:06
*** mvk has quit IRC17:07
odyssey4meI've raised a bug about some ambiguity related to cache settings that I'd like to get straightened out and would appreciate some eyes:
openstackLaunchpad bug 1690756 in oslo.cache "cache 'backend' argument description is ambiguous" [Undecided,New]17:08
bretonbkudryavtsev: probably yes17:11
lbragstadodyssey4me: nice - i can take a look17:11
lbragstadodyssey4me: i was just digging around in some of that code last week at the summit17:12
*** aselius has joined #openstack-keystone17:12
lbragstadodyssey4me: fwiw - i think morgan wrote some of that17:12
bkudryavtsevI would like to work on bug 1671196. Any tips, suggestions?17:16
openstackbug 1671196 in OpenStack Identity (keystone) "user list for LDAP group does not contain all members" [Medium,Triaged]
*** jose-phillips has quit IRC17:21
*** jose-phillips has joined #openstack-keystone17:26
*** dklyle is now known as david-lyle17:37
*** jose-phillips has quit IRC17:39
*** mvk has joined #openstack-keystone17:41
*** bkudryavtsev has quit IRC17:47
*** bkudryavtsev has joined #openstack-keystone17:47
*** jose-phillips has joined #openstack-keystone17:47
samueldmqhi keystoners!17:57
*** nicolasbock has quit IRC17:57
lbragstadsamueldmq: o/18:01
*** nicolasbock has joined #openstack-keystone18:05
knikollalooks like the ksm gate is broken18:07
*** piliman974 has quit IRC18:15
knikollai do not understand what that specific failing unit test is meant to do18:16
samueldmqlbragstad: o/18:16
samueldmqknikolla: looking18:16
knikollasamueldmq: o/18:18
samueldmqknikolla: need to dig a bit on that, but perhaps the behavior might be changed in oslo_messaging ?18:18
samueldmqknikolla: would need to look more carefully, but I am finishing off something else right now :(18:19
samueldmqknikolla: a good step would be to try to reproduce it locally18:19
knikollasamueldmq: i'll give it a try locally in a few minutes.18:21
samueldmqknikolla: sweet, let me know how it goes18:21
*** nicolasbock has quit IRC18:22
*** nishaYadav has joined #openstack-keystone18:24
knikollasamueldmq: same test failed locally.18:24
samueldmqknikolla: that's great (that we can reproduce)18:25
samueldmqknikolla: should be able to analyze what's going on to try to figure out what changed18:26
samueldmqI mean, if you have time and are willing to solve this18:26
samueldmqnishaYadav: hi, welcome back from the summit18:26
knikollasamueldmq: i can spare some time. will go through the merged patches in oslo.messaging see if anything might be related.18:26
lbragstadknikolla: samueldmq that looks kind of familiar - we had a bunch of things going in from oslo.config recently18:26
*** nicolasbock has joined #openstack-keystone18:27
samueldmqlbragstad: ++18:27
samueldmqknikolla: nice18:27
samueldmqlbragstad: knikolla yeah my guess would be that it relates to config values being enforced somewhere18:27
samueldmqthat was the things that changed in Oslo config lately iirc18:27
lbragstadgcb was doing some work recently to get the type checking taken care of18:28
lbragstadbefore switching the default in oslo.config to enforce type checking by default18:28
knikollaseems like the switch happened18:30
nishaYadavsamueldmq Thanks. It was great meeting fellow contributors :)18:36
rmascenagagehugo, ping, are you around?18:36
rmascenagagehugo, about your summit talk :)18:36
nishaYadav@lbragstad, hi18:36
*** rmascena is now known as raildo18:37
*** nishaYadav has quit IRC18:39
*** spilla has joined #openstack-keystone18:39
*** nishaYadav has joined #openstack-keystone18:39
gagehugormascena what's up?18:40
samueldmqraildo: now I recognize that IRC nickname!18:41
*** jose-phillips has quit IRC18:41
lbragstadnishaYadav: o/18:45
lbragstadknikolla: yeah - that looks like the one18:46
knikollalbragstad: from the docstring and the code of oslo.config, None is not converted even if enforce_type is set to true. and the value we use is None.18:48
raildosamueldmq, haha to make easier18:50
raildogagehugo, so, I saw your talk, and it was a (good) surprise for me :) I'm working on the Custodia project18:51
gagehugoraildo awesome18:51
*** nishaYadav has quit IRC18:53
raildogagehugo, and one my short goals would be implement the oslo.config PoC (that you already did) so, I would love to review the code and help with anything that I can :)18:53
lbragstadknikolla: it looks like its failing on an oslo_messaging configuration option18:54
*** nishaYadav has joined #openstack-keystone18:54
raildoif you need some more explanation about Custodia, or how we are using it for other services18:54
lamtknikolla lbragstad : setting driver=None seems to throw out this weird message: "Could not load s, n, m, i, g, e, a" in that test.18:55
raildogagehugo, did you not submitted upstream yet, right?18:55
gagehugoraildo not yet, I think the changes are on a github fork though18:56
knikollalamt: it's pretty weird. it's one of the permutation of those letters18:57
lamtknikolla: should that really be set to 'noop'18:57
gagehugoraildo the changes def need some work before it's upstreamable18:57
raildogagehugo, do you know if will be necessary to write an spec for this feature?18:58
lamtthat gets rid of the cryptic msg, but the test still fails18:58
raildogagehugo, sure, no problem :)18:58
gagehugoraildo I would say yes since it adds new logic into oslo.config18:58
gagehugoif you are wanting to fetch values from remote locations via secret keys18:58
knikollalamt: yes, the test still fails.18:59
raildogagehugo, yeap, that what I excepted... so if you need some help, or want to someone else to put eyes on it, feel free to ping me :)18:59
*** jose-phillips has joined #openstack-keystone19:00
knikollalamt: i got it to pass with setting it to 'messaging', but I think that defeats the purpose of the test. since there is actual configuration and the test tests for lacking configuration.19:00
gagehugoraildo for sure!19:01
lamtknikolla: it seems to be permuting over the oslo_messaging_notifications driver19:03
lamtknikolla: if I do self.cfg.config(driver='log', group='oslo_messaging_notifications'), leaving audit_middleware_notifications to None19:04
lamtknikolla I see Could not load o, g, l19:04
knikollalamt: i see. so messagging is s, n, m, i, g, e, a (or permutation)19:05
gagehugoraildo I think one of the issues with the change is including something else between {oslo.config} and {secret store} that can talk between multiple {secret stores} vs just adding barbican logic in to oslo.config19:05
gagehugowhich we used custodia for in the PoC19:05
lbragstadknikolla: lamt interesting19:05
lbragstadknikolla: this is what you did?
knikollalbragstad: yes. test passed with that.19:06
lbragstadknikolla: ok - same here19:06
knikollaif i set the driver of oslo_messaging_notifications, I get "TypeError: argument of type 'NoneType' is not iterable"19:07
knikollanot sure why it's trying to iterate over a string.19:08
knikollato None*19:08
knikollaif i set the driver of oslo_messaging_notifications to None*19:08
raildogagehugo, yeah, that's a good point, I believe the right way to do this is having something in the middle, since there is a lot of clients with different secret stores instead of barbican, and we can just say: "hey, if you want to do this, stop using what you have and change now for barbican"19:08
gagehugoraildo +119:09
lbragstadknikolla: well - the oslo.messaging option defaults to an empty list19:09
*** aojea has joined #openstack-keystone19:09
knikollalbragstad: that makes sense19:10
raildogagehugo, actually, that's why we have projects like Custodia, to works like this "middleware" for this kind of system.19:10
lamtlbragstad knikolla This works:
lamtfor me,19:11
lbragstadknikolla: lamt it looks like the audit_middleware_notifications is attempting to pass the value from oslo through - but it gets munged19:11
lamtI think we have to pass in a list for oslo_messaging_notifications19:12
lbragstadlamt: ah - sure19:12
lbragstadthat makes sense19:12
raildogagehugo, in addition, we don't need any keystone user/password for this operation, so we don't need a "password" to store "passwords", this is another reason that I prefer this approach.19:12
lbragstadotherwise the string is treated like a list19:13
knikollalamt: you beat me by a few seconds. that worked for me too.19:13
lamtlbragstad but I am not sure how other test seems to be okay - like the test before: test_conf_middleware_messaging_and_oslo_msg_as_log19:13
raildogagehugo, anyway, I'm really happy to see this coming up at this point :)19:13
knikollalamt: cause something weird is happening when no value is present. it will iterate over the previous option, treating a string as a list, therefore iterating over the letters.19:14
lbragstadlamt: the behavior only appears to affect things when setting the audit_middleware_notification options to None19:14
lbragstadknikolla: right19:14
lbragstadit's something with how we're marshalling the data19:14
lamtlbragstad knikolla: ah19:14
gagehugoraildo yup!19:14
knikollaand driver is a multistropt. so that's not entirely inaccurate.19:15
* lbragstad isn't a fan of multistring opts19:15
knikollalamt: make the patch. i'll +1.19:16
lamtsure - should I change all the other .cfg.config(driver= in other tests as well so they are consistently a list?19:17
lbragstadlamt: i would19:17
lbragstadlamt: knikolla do either of you know where that translation is happening?19:18
knikollalbragstad: which translation are you referring to?19:19
knikollalbragstad: i think oslo.messaging provides the driver option as is to stevedore. and stevedore iterates over it.19:19
lbragstadfwiw - maybe we should follow up with gcb when he's online19:22
lbragstadi would consider this to be a unique case because we're defaulting to another groups configuration instead of a value (i.e. the default keyword)19:23
knikollalbragstad: yes. we should follow up. i still don't see any change which might be the root cause for this happening.19:24
lbragstadknikolla: i think it's because oslo.config enforces type by default19:24
knikollalbragstad: hmm… so maybe it would enforce a string to become a list of characters?19:25
knikollasince the option is a multi string19:25
ayounggagehugo, isn't tin going to post his Custodia change for oslo-config?19:25
knikollasounds plausible19:25
lamtayoung working on that19:26
ayounglamt, Awesome.  Very important work there.19:27
ayounglamt, I want to use that for a few thing:  getting the mysql and Rabbit passwords out of the config file, dealing with Keys for Fernet and Credentials.19:28
openstackgerritTin Lam proposed openstack/keystonemiddleware master: Update driver config parameter from string to list
*** piliman974 has joined #openstack-keystone19:31
lamtayoung that's what I want to do as well - I think there might be a spec in oslo.config but of a different scope. I'll check19:31
ayounglamt, please share what you have with raildo, as he is looking into custodia stuff elsewhere already, and he knows enough about Keystone to be
lamtayoung will do19:34
*** raildo has quit IRC19:34
*** rmascena has joined #openstack-keystone19:34
*** nkinder has quit IRC19:35
*** rmascena has quit IRC19:36
*** rmascena has joined #openstack-keystone19:36
rmascenaayoung, lamt  when we code, we are always dangerous hahaha19:38
*** rmascena is now known as raildo19:38
raildolamt, would be great to take a look on this spec :)19:39
*** raildo has quit IRC19:42
lamtraildo gagehugo we may need a separate spec - I think the existing one is about generating config and populate it using some kind of config management backend (e.g. database).  It is in one of the forums' etherpad.  I need to look.19:42
lamtBut we can probably throw a WIP out there though19:42
lbragstadlamt: thanks for the quick fix19:43
lamtlbragstad: np - I can revert the line break later19:44
*** raildo has joined #openstack-keystone19:45
raildoI hate my internet connection, right now...19:45
*** tobberydberg has joined #openstack-keystone19:46
lbragstadlamt: no worries - i don't mind it19:48
*** belmoreira has joined #openstack-keystone20:07
*** belmoreira has quit IRC20:08
lbragstadwe should really have better help text for keystone-manage20:10
lbragstadlike - we should be able to do `keystone-manage help bootstrap`20:10
*** nkinder has joined #openstack-keystone20:12
bkudryavtsevI cannot reproduce bug 167119 on my system. Users with id in format CN=LASTNAME\, FIRSTNAME are still displayed in group. Can someone see if that is correct?20:13
openstackbug 167119 in Inkscape "SVG import" [Undecided,Invalid]
*** ducttap__ has joined #openstack-keystone20:13
bkudryavtsevSorry, bug 167119620:13
openstackbug 1671196 in OpenStack Identity (keystone) "user list for LDAP group does not contain all members" [Medium,Triaged]
*** ducttape_ has quit IRC20:14
*** jose-phillips has quit IRC20:19
*** raildo has quit IRC20:22
*** ducttap__ has quit IRC20:23
*** ducttape_ has joined #openstack-keystone20:23
*** ducttap__ has joined #openstack-keystone20:24
*** ducttape_ has quit IRC20:25
*** nkinder has quit IRC20:27
*** jose-phillips has joined #openstack-keystone20:33
MonkXmodebreton: Are you still around?20:40
MonkXmodeOr if anyone else can help me... I have an LDAP backend for a specific domain, and whilst I can assign an LDAP user's "id" to a project via openstack's cli - I would hope to be able to assign a role: "user" inherently20:44
MonkXmodeas it's part of the specified group.20:44
MonkXmodeIs this related to the masking values in the keystone's config? Cos I've read the explanation a few times and I'm out of coffee and it's not making too much sense :- )20:45
MonkXmodeThe question to follow is: How do I define a list of Admins in ldap for the project/domain with ldap attributes or a specified group.20:51
*** dave-mccowan has quit IRC20:52
*** nishaYadav has quit IRC20:55
bretonMonkXmode: assign role to group20:56
bretonMonkXmode: openstack role add --group <group> --project <project> admin20:57
*** spilla has quit IRC21:00
*** tobberydberg has quit IRC21:00
MonkXmodebreton: Wouldn't I still be in the same position of having to manually specify people into a group "users" or a group "admin" within that project though?21:01
MonkXmodeSo, I want bob and alice to have admin privileges, and steve and martin to be user. How can I influence this directly via ldap schema/attributes rather than manually using the openstack cli?21:02
MonkXmode(Perhaps my use case is superfluous - but I would assume this is common?)21:03
*** jose-phillips has quit IRC21:05
*** aojea has quit IRC21:11
*** edmondsw_ has quit IRC21:17
*** edmondsw has joined #openstack-keystone21:18
*** jose-phillips has joined #openstack-keystone21:18
*** thorst_afk has quit IRC21:18
*** thorst_afk has joined #openstack-keystone21:19
*** edmondsw_ has joined #openstack-keystone21:20
*** edmondsw has quit IRC21:22
*** thorst_afk has quit IRC21:23
*** edmondsw_ has quit IRC21:24
*** nkinder has joined #openstack-keystone21:25
*** gongysh has joined #openstack-keystone21:26
*** gongysh has quit IRC21:27
*** bkudryavtsev has quit IRC21:32
MonkXmodebreton: I'll read more tomorow :-)21:35
MonkXmodeThanks for the help today. I will keep learning :-)21:35
*** MonkXmode has quit IRC21:39
*** edmondsw has joined #openstack-keystone21:48
*** edmondsw has quit IRC21:53
*** adriant has joined #openstack-keystone21:57
*** thorst_afk has joined #openstack-keystone22:03
*** ducttap__ has quit IRC22:04
openstackgerritLance Bragstad proposed openstack/keystone-specs master: Specification for global roles
*** ducttape_ has joined #openstack-keystone22:06
*** thorst_afk has quit IRC22:08
*** ducttape_ has quit IRC22:10
*** lamt has quit IRC22:15
*** ducttape_ has joined #openstack-keystone22:16
*** lamt has joined #openstack-keystone22:17
*** lamt has quit IRC22:17
*** piliman974 has quit IRC22:30
*** gongysh has joined #openstack-keystone22:39
*** gongysh has quit IRC22:40
*** morgan_ has joined #openstack-keystone22:41
*** pratapagoutham has quit IRC22:57
*** tobberydberg has joined #openstack-keystone23:01
*** tobberydberg has quit IRC23:05
*** rderose has quit IRC23:06
*** ducttape_ has quit IRC23:34
*** ducttape_ has joined #openstack-keystone23:38
*** ducttape_ has quit IRC23:43
*** harlowja has quit IRC23:46
*** hoonetorg has quit IRC23:54

Generated by 2.14.0 by Marius Gedminas - find it at!