*** code-R has quit IRC | 00:01 | |
*** knikolla has quit IRC | 00:06 | |
*** knikolla has joined #openstack-keystone | 00:09 | |
openstackgerrit | Samuel de Medeiros Queiroz proposed openstack/keystonemiddleware: Make sure audit can handle API requests which does not require a token https://review.openstack.org/320725 | 00:16 |
---|---|---|
*** jamielennox|away is now known as jamielennox | 00:20 | |
*** darosale has joined #openstack-keystone | 00:34 | |
openstackgerrit | Samuel de Medeiros Queiroz proposed openstack/keystone: Invalidate token cache after token delete https://review.openstack.org/316991 | 00:43 |
*** rdo has quit IRC | 00:43 | |
*** rdo has joined #openstack-keystone | 00:46 | |
*** dan_nguyen has joined #openstack-keystone | 00:47 | |
*** lhcheng has joined #openstack-keystone | 00:53 | |
*** ChanServ sets mode: +v lhcheng | 00:53 | |
*** lhcheng has quit IRC | 00:57 | |
*** georgem1 has joined #openstack-keystone | 01:21 | |
*** EinstCrazy has joined #openstack-keystone | 01:25 | |
*** iurygregory_ has quit IRC | 01:28 | |
*** flwang2 has joined #openstack-keystone | 01:43 | |
*** julim has quit IRC | 01:44 | |
*** flwang has quit IRC | 01:44 | |
*** markvoelker has joined #openstack-keystone | 01:51 | |
*** markvoelker has quit IRC | 01:55 | |
*** code-R has joined #openstack-keystone | 01:57 | |
*** julim has joined #openstack-keystone | 02:00 | |
*** code-R has quit IRC | 02:02 | |
*** julim has quit IRC | 02:04 | |
*** tangchen has joined #openstack-keystone | 02:31 | |
*** sdake_ has joined #openstack-keystone | 02:46 | |
*** sheel has joined #openstack-keystone | 02:47 | |
*** sdake has quit IRC | 02:50 | |
*** eszxy has joined #openstack-keystone | 02:52 | |
*** diazjf has joined #openstack-keystone | 02:52 | |
*** diazjf has quit IRC | 02:52 | |
*** EinstCrazy has quit IRC | 03:00 | |
*** edmondsw has joined #openstack-keystone | 03:02 | |
openstackgerrit | OpenStack Proposal Bot proposed openstack/python-keystoneclient: Updated from global requirements https://review.openstack.org/323084 | 03:06 |
*** sdake_ has quit IRC | 03:07 | |
*** dan_nguyen has quit IRC | 03:30 | |
*** EinstCrazy has joined #openstack-keystone | 03:30 | |
*** darosale has quit IRC | 03:33 | |
openstackgerrit | ChangBo Guo(gcb) proposed openstack/keystonemiddleware: Use method split_path from oslo.utils https://review.openstack.org/323101 | 03:34 |
*** georgem1 has quit IRC | 03:45 | |
*** rcernin has joined #openstack-keystone | 03:49 | |
*** links has joined #openstack-keystone | 03:50 | |
*** markvoelker has joined #openstack-keystone | 03:52 | |
*** neophy has joined #openstack-keystone | 03:54 | |
*** markvoelker has quit IRC | 03:56 | |
*** code-R has joined #openstack-keystone | 03:58 | |
*** code-R has quit IRC | 04:03 | |
*** pgbridge has joined #openstack-keystone | 04:12 | |
*** itisha has quit IRC | 04:20 | |
*** jaosorior has joined #openstack-keystone | 04:39 | |
stevemar | jamielennox: notmorgan i opened https://bugs.launchpad.net/keystone/+bug/1587239 | 04:48 |
openstack | Launchpad bug 1587239 in OpenStack Identity (keystone) "cover job is failing too frequently" [High,New] | 04:48 |
notmorgan | stevemar: joy | 04:52 |
notmorgan | ideas on cause? | 04:52 |
*** gcb has joined #openstack-keystone | 04:52 | |
*** rcernin has quit IRC | 04:52 | |
*** chlong has quit IRC | 04:54 | |
*** flwang2 has quit IRC | 05:02 | |
stevemar | notmorgan: probably cause the tox target doesn't follow upper-constraints | 05:03 |
*** pgbridge has quit IRC | 05:04 | |
notmorgan | oh shoukd fix that | 05:05 |
openstackgerrit | Merged openstack/keystoneauth: Updated from global requirements https://review.openstack.org/323068 | 05:12 |
*** chlong has joined #openstack-keystone | 05:12 | |
openstackgerrit | Merged openstack/oslo.policy: Updated from global requirements https://review.openstack.org/323080 | 05:14 |
openstackgerrit | Merged openstack/keystonemiddleware: Updated from global requirements https://review.openstack.org/323069 | 05:17 |
*** jamielennox is now known as jamielennox|away | 05:24 | |
openstackgerrit | Merged openstack/python-keystoneclient: Updated from global requirements https://review.openstack.org/323084 | 05:27 |
*** jamielennox|away is now known as jamielennox | 05:28 | |
*** d34dh0r53 has quit IRC | 05:33 | |
*** d34dh0r53 has joined #openstack-keystone | 05:36 | |
jamielennox | notmorgan: here? | 05:45 |
*** neophy has quit IRC | 05:46 | |
*** GB21 has joined #openstack-keystone | 05:50 | |
*** markvoelker has joined #openstack-keystone | 05:52 | |
*** markvoelker has quit IRC | 05:57 | |
*** code-R has joined #openstack-keystone | 05:59 | |
*** code-R has quit IRC | 06:04 | |
*** jamielennox is now known as jamielennox|away | 06:15 | |
notmorgan | jamielennox|away: ? | 06:22 |
notmorgan | its 2322 here whats up? | 06:22 |
*** GB21 has quit IRC | 06:34 | |
*** belmoreira has joined #openstack-keystone | 06:46 | |
*** neophy has joined #openstack-keystone | 06:53 | |
*** GB21 has joined #openstack-keystone | 06:54 | |
*** tesseract has joined #openstack-keystone | 06:57 | |
*** rcernin has joined #openstack-keystone | 07:02 | |
*** neophy has quit IRC | 07:04 | |
*** yolanda has quit IRC | 07:05 | |
*** yolanda has joined #openstack-keystone | 07:05 | |
*** dimonv has joined #openstack-keystone | 07:05 | |
*** jamielennox|away is now known as jamielennox | 07:18 | |
jamielennox | notmorgan: yea - but that doesn't mean you're not here | 07:19 |
jamielennox | notmorgan: i wanted to ask about https://github.com/openstack-dev/devstack/blob/master/lib/keystone#L251-L252 | 07:19 |
jamielennox | the bug mentioned is marked as fixed, but it's a bit past my oslo.cache knowledge | 07:20 |
jamielennox | is it safe to remove from devstack? | 07:20 |
*** code-R has joined #openstack-keystone | 07:22 | |
*** code-R_ has joined #openstack-keystone | 07:25 | |
*** code-R has quit IRC | 07:28 | |
*** sdake has joined #openstack-keystone | 07:34 | |
aloga | jamielennox: around? probably you have a hint regarding https://bugs.launchpad.net/nova/+bug/1555045 | 07:50 |
openstack | Launchpad bug 1555045 in OpenStack Compute (nova) "Volume wouldn't been detach after delete with reclaim_instance_interval" [Medium,Triaged] | 07:50 |
*** markvoelker has joined #openstack-keystone | 07:53 | |
*** yolanda has quit IRC | 07:54 | |
*** yolanda has joined #openstack-keystone | 07:55 | |
*** yolanda has quit IRC | 07:56 | |
*** yolanda_ has joined #openstack-keystone | 07:56 | |
*** markvoelker has quit IRC | 07:58 | |
*** zzzeek has quit IRC | 08:00 | |
*** TxGVNN has joined #openstack-keystone | 08:00 | |
*** zzzeek has joined #openstack-keystone | 08:01 | |
openstackgerrit | Davanum Srinivas (dims) proposed openstack/keystone: [WIP] Testing latest u-c https://review.openstack.org/318435 | 08:10 |
*** jaosorior has quit IRC | 08:11 | |
*** jaosorior has joined #openstack-keystone | 08:12 | |
*** woodster_ has quit IRC | 08:18 | |
*** mkrcmari__ has quit IRC | 08:22 | |
*** dmk0202 has joined #openstack-keystone | 08:26 | |
*** tangchen has quit IRC | 08:26 | |
*** sdake_ has joined #openstack-keystone | 08:32 | |
*** sdake has quit IRC | 08:35 | |
*** jaosorior is now known as jaosorior_lunch | 08:39 | |
*** TxGVNN has quit IRC | 08:39 | |
*** code-R_ has quit IRC | 08:42 | |
*** code-R has joined #openstack-keystone | 08:49 | |
*** henrynash has joined #openstack-keystone | 08:51 | |
*** ChanServ sets mode: +v henrynash | 08:51 | |
*** mkrcmari__ has joined #openstack-keystone | 08:54 | |
openstackgerrit | Rudolf Vriend proposed openstack/keystone: Allow domain admins to list users in groups with v3 policy https://review.openstack.org/321128 | 08:56 |
*** flwang has joined #openstack-keystone | 08:57 | |
*** nisha has joined #openstack-keystone | 08:58 | |
*** nisha has quit IRC | 08:58 | |
*** permalac has quit IRC | 09:16 | |
*** daemontool has joined #openstack-keystone | 09:22 | |
*** jbell8 has joined #openstack-keystone | 09:23 | |
*** chlong has quit IRC | 09:29 | |
*** srushti has quit IRC | 09:29 | |
*** nisha has joined #openstack-keystone | 09:34 | |
jamielennox | aloga: the Service catalog is empty message is kind of self explanatory - the token you validated doesn't have a service catalog to know how to talk to another service | 09:41 |
jamielennox | aloga: you either need to turn off the ?no_catalog flag to whatever is validating tokens, or have some other way of passing an endpoint in | 09:41 |
aloga | jamielennox: I don't get it | 09:41 |
aloga | jamielennox: this is something done by nova | 09:42 |
aloga | jamielennox: I am not doing anything :-) | 09:42 |
*** mkrcmari__ has quit IRC | 09:43 | |
*** flwang has quit IRC | 09:43 | |
aloga | jamielennox: if I am not wrong, the catalog is coming from this class https://github.com/openstack/nova/blob/master/nova/context.py#L39 | 09:44 |
jamielennox | aloga: have you got include_service_catalog = False in your nova keystone_authtoken config? | 09:44 |
aloga | jamielennox: no | 09:44 |
jamielennox | aloga: what service is it trying to contact? | 09:44 |
aloga | jamielennox: cinder | 09:45 |
aloga | but this is a delayed task | 09:45 |
aloga | jamielennox: so it is usin an admin context | 09:45 |
aloga | this is the volume cleanup task | 09:45 |
aloga | if the cleanup is done as a delayed task it fails | 09:46 |
*** chlong has joined #openstack-keystone | 09:47 | |
aloga | if the cleanup is done straight away (i.e. no reclaim interval) it works | 09:47 |
*** mvk has joined #openstack-keystone | 09:47 | |
aloga | so my guess is that, since the delayed task is using an admin context, it does not contain the service catalog | 09:47 |
jamielennox | aloga: yea, that makes sense | 09:48 |
jamielennox | get_admin_context doesn't have any catalog: https://github.com/openstack/nova/blob/master/nova/context.py#L225 | 09:49 |
jamielennox | so how is nova supposed to know how to talk to cinder ? | 09:49 |
aloga | indeed | 09:49 |
jamielennox | what token is it using? | 09:50 |
jamielennox | the nova service user? | 09:50 |
*** agireud has quit IRC | 09:50 | |
aloga | jamielennox: you mean in the delayed task? | 09:52 |
aloga | jamielennox: I think that the nova service user should be used | 09:52 |
jamielennox | right, something has to make the request | 09:52 |
aloga | jamielennox: but this then requires that the nova service user has permissions in cinder as well | 09:52 |
jamielennox | there's something in neutron that requires admin so i think the nova user is already pretty powerful | 09:53 |
jamielennox | but there's a scoping issue - the nova user won't be in the project that it wants to delete resource for | 09:53 |
jamielennox | aloga: is this a new feature? | 09:53 |
jamielennox | has it worked in the past? | 09:53 |
aloga | jamielennox: no, it does not work in the past | 09:53 |
aloga | jamielennox: this has been an issue in our cloud for a while | 09:54 |
aloga | (we're in Liberty right now and we see the error) | 09:54 |
*** markvoelker has joined #openstack-keystone | 09:54 | |
aloga | s/does/did/ | 09:55 |
*** sdake_ is now known as sdake | 09:57 | |
*** markvoelker has quit IRC | 09:58 | |
aloga | you can override the cinder endpoint in an configuration option (i.e. it won't get the endpoint from the catalog) so in that case the cleanup obviously works | 09:58 |
nisha | Hey all :) | 10:01 |
nisha | I have been trying to use the V3 client API , following the steps on http://docs.openstack.org/developer/python-keystoneclient/using-api-v3.html and http://docs.openstack.org/developer/python-keystoneclient/using-sessions.html | 10:02 |
nisha | I tried authenticating using sessions and then ran users.list() on the object. But I am getting a connection error. Can anyone please help? | 10:04 |
jamielennox | aloga: but that's just your cloud right? it is a feature that has worked | 10:05 |
jamielennox | oh, so most people override the cinder endpoint? | 10:05 |
jamielennox | nisha: what sort of connectionerror? | 10:05 |
henrynash | morning | 10:05 |
nisha | ttp://paste.openstack.org/show/506535/ | 10:05 |
jamielennox | what's the message | 10:05 |
*** jaosorior_lunch is now known as jaosorior | 10:06 | |
nisha | hi jamielennox the above http://paste.openstack.org/show/506535/ | 10:06 |
nisha | raise exceptions.ConnectFailure(msg) | 10:07 |
nisha | keystoneauth1.exceptions.connection.ConnectFailure: Unable to establish connection to https://my.keystone.com:5000/v3/auth/tokens | 10:07 |
jamielennox | nisha: hmm, unfortunately that doesn't help much - it's fairly generic | 10:07 |
jamielennox | does like wget https://my.keystone.com:5000/v3/ return anything? | 10:07 |
nisha | jamielennox, I have been trying since yesterday, i can't open the link https://my.keystone.com:5000/v3/ in my browser | 10:09 |
jamielennox | nisha: so it sounds like an actual connection error, as in you can't connect to the server | 10:09 |
jamielennox | if you can't connect in a browser then maybe the server isn't exposed, maybe firewall issues, | 10:10 |
jamielennox | there's a lot of things there that could be a thing | 10:10 |
*** agireud has joined #openstack-keystone | 10:11 | |
*** pcaruana has joined #openstack-keystone | 10:11 | |
nisha | jamielennox, the documentation said Upon successful authentication, a keystoneclient.v3.client.Client object is returned (when using the Identity v3 API). And I do get >>> type(keystone) | 10:11 |
nisha | <class 'keystoneclient.v3.client.Client'> | 10:11 |
aloga | jamielennox: I don't know for other clouds, but if you see the bug report this is something that happens to others | 10:12 |
aloga | jamielennox: and it is reproducible with devstack, if you configure an instance reclaim interval | 10:12 |
aloga | jamielennox: so I guess this is something generalized | 10:12 |
jamielennox | nisha: if that's in there then it's related to an older way of authenticating, that url is the first point of contact where you get a token so i don't think your keystone is working at all | 10:12 |
aloga | jamielennox: either people override the endpoint, or they do not have set a reclaim interval | 10:13 |
jamielennox | aloga: yep, ok - can you point me to where the code for this is? where it's getting its auth from? | 10:13 |
jamielennox | nisha: doing wget https://my.keystone.com:5000/v3 should return some version information without needing a token so if you can't see that then your service is not up | 10:14 |
aloga | jamielennox: sure, https://github.com/openstack/nova/blob/master/nova/compute/manager.py#L2175 | 10:14 |
*** chlong has quit IRC | 10:15 | |
nisha | jamielennox, thanks for help | 10:17 |
jamielennox | nisha: no worries, sorry i couldn't be more useful | 10:17 |
jamielennox | aloga: do you know what calls that? | 10:17 |
jamielennox | aloga: or like a traceback to that point? i want to know where the context is created i think | 10:18 |
aloga | jamielennox: that method is being called by _delete_instance (https://github.com/openstack/nova/blob/master/nova/compute/manager.py#L2234) that is being called by _reclaim_queued_deletes (https://github.com/openstack/nova/blob/master/nova/compute/manager.py#L6237) | 10:18 |
*** jbell8 has quit IRC | 10:18 | |
aloga | that is being execued as a periodic task (https://github.com/openstack/nova/blob/master/nova/service.py#L251) | 10:19 |
aloga | so, the original context is obtained in https://github.com/openstack/nova/blob/master/nova/service.py#L251 | 10:20 |
*** jbell8 has joined #openstack-keystone | 10:20 | |
*** henrynash_ has joined #openstack-keystone | 10:21 | |
*** zerda2 has joined #openstack-keystone | 10:22 | |
*** nisha_ has joined #openstack-keystone | 10:22 | |
*** henrynash has quit IRC | 10:22 | |
*** henrynash has joined #openstack-keystone | 10:23 | |
*** ChanServ sets mode: +v henrynash | 10:23 | |
zerda2 | Hello. In nova and neutron there is a possibility to log wall clock data for each request. How to do that with keystone+apache? Only by changing apache log format to include %D? | 10:24 |
zerda2 | *wall clock time | 10:24 |
*** nisha has quit IRC | 10:26 | |
*** yolanda has joined #openstack-keystone | 10:27 | |
*** nisha_ is now known as nisha | 10:27 | |
*** yolanda_ has quit IRC | 10:27 | |
*** chlong has joined #openstack-keystone | 10:27 | |
jamielennox | aloga: so i'm fairly confused how this works | 10:31 |
jamielennox | aloga: so here is where the context ends up https://github.com/openstack/nova/blob/master/nova/volume/cinder.py#L78 | 10:31 |
jamielennox | so from the highlight i can see the difference as to why it works when you set endpoint_template, it sets endpoint_override and works | 10:32 |
aloga | jamielennox: yes | 10:32 |
*** EinstCrazy has quit IRC | 10:32 | |
jamielennox | aloga: what i can't see is where in get_admin_context when you have got an endpoint_template set - where is the token coming from? | 10:33 |
jamielennox | https://github.com/openstack/nova/blob/master/nova/context.py#L225 doesn't handle it at all | 10:33 |
aloga | jamielennox: I am not following you | 10:34 |
aloga | :-? | 10:34 |
aloga | the problem is here: https://github.com/openstack/nova/blob/master/nova/volume/cinder.py#L70 | 10:34 |
aloga | auth = context.get_auth_plugin() | 10:34 |
aloga | then in line https://github.com/openstack/nova/blob/master/nova/volume/cinder.py#L82 | 10:35 |
aloga | it tries to get the endpoint, and it fails, as there is no catalog | 10:35 |
*** code-R has quit IRC | 10:35 | |
aloga | if you go through the other branch of the if https://github.com/openstack/nova/blob/master/nova/volume/cinder.py#L78 | 10:35 |
aloga | because you have a template set, it will work | 10:36 |
jamielennox | aloga: yep, but that seems to get started from here: https://github.com/openstack/nova/blob/master/nova/service.py#L251-L254 | 10:36 |
aloga | yes | 10:36 |
jamielennox | ok, so assume from that you have endpoint_template set - where is auth_token coming from? | 10:36 |
*** jbell8 has quit IRC | 10:36 | |
*** henrynash has quit IRC | 10:37 | |
aloga | jamielennox: ahhh, sorry | 10:37 |
jamielennox | i mean you ahve to call cinder with some sort of token | 10:37 |
aloga | jamielennox: I misunderstood you | 10:37 |
aloga | jamielennox: yes, you are right | 10:37 |
aloga | jamielennox: we never set the endpoint template, so to be honest I do not know if this worked before | 10:38 |
aloga | jamielennox: I can test it quickly though | 10:38 |
jamielennox | aloga: if you could because it must work for people | 10:39 |
jamielennox | and we'd get the service catalog from the same place we get the token from | 10:39 |
jamielennox | (wherever that is) | 10:39 |
*** agireud has quit IRC | 10:39 | |
jamielennox | aloga: are we sure the request is being made from nova api rather than nova scheduler? | 10:42 |
aloga | jamielennox: yes, the scheduler is not involved here | 10:46 |
openstackgerrit | ChangBo Guo(gcb) proposed openstack/keystonemiddleware: Use method split_path from oslo.utils https://review.openstack.org/323101 | 10:47 |
*** nisha_ has joined #openstack-keystone | 10:47 | |
*** permalac has joined #openstack-keystone | 10:48 | |
*** code-R has joined #openstack-keystone | 10:49 | |
*** nisha has quit IRC | 10:50 | |
*** mou has joined #openstack-keystone | 10:51 | |
aloga | jamielennox: it works | 10:54 |
aloga | ah, no, sorry | 10:54 |
aloga | jamielennox: you were right, it fails: Ignoring unknown exception for volume 4a8940a5-1d42-4f34-86e1-d949630d94fd: No valid authentication is available | 11:00 |
jamielennox | aloga: in that case i have absolutely no idea how it should work :) | 11:01 |
jamielennox | that's my reading of the code. there is no token available for making requests | 11:01 |
jamielennox | so i'm not sure how it ever worked | 11:01 |
aloga | jamielennox: I would say: "I'm not sure if it ever worked" :) | 11:01 |
jamielennox | aloga: yep - i'd agree | 11:02 |
jamielennox | which i always find amazing | 11:02 |
aloga | jamielennox: well, it works if there is not a reclaim interval | 11:02 |
aloga | jamielennox: that is, if the attachment is cleaned straight away when the user does a delete | 11:03 |
jamielennox | aloga: i'd figure out from nova what is supposed to happen there - but what i think you'll want to do is have a keystoneauth plugin created for the nova credentials that is passed as user_auth_plugin in get_admin_context | 11:03 |
jamielennox | if there's a plugin in there things should just work | 11:04 |
*** nisha_ is now known as nisha | 11:04 | |
samueldmq | nisha: morning | 11:04 |
aloga | jamielennox: so the operation will be done with a token issued for the service user, right? | 11:05 |
nisha | samueldmq, hey, morning | 11:05 |
jamielennox | aloga: that would be the outcome yes | 11:05 |
jamielennox | aloga: i can only assume that's the intention | 11:05 |
aloga | jamielennox: great, many thanks | 11:05 |
aloga | jamielennox: I will check if I can handle this... | 11:06 |
jamielennox | aloga: no worries - hope it helped | 11:06 |
*** code-R has quit IRC | 11:06 | |
*** dmk0202 has quit IRC | 11:07 | |
*** raildo-afk is now known as raildo | 11:13 | |
samueldmq | jamielennox: hi | 11:24 |
samueldmq | jamielennox: who usually release keystoneauth ? is it you or stevemar ? | 11:25 |
jamielennox | samueldmq: normally stevemar but i can probably do it in case of emergency - what's up? | 11:33 |
samueldmq | jamielennox: yolanda did some updates for keystoneauth fixture she needs to consume in shade | 11:34 |
samueldmq | jamielennox: she's been asking for a release lately; are there any specific requirements to make a cut ? | 11:34 |
jamielennox | samueldmq: not specific requirements no, normally either we really need something elsewhere, have urgent bug or it's just been a while | 11:35 |
jamielennox | there's been a few things merged since last release | 11:36 |
jamielennox | samueldmq: so i would like to get https://review.openstack.org/#/c/321814/ merged before a release | 11:36 |
patchbot | jamielennox: patch 321814 - keystoneauth - Make the kerberos plugin loadable | 11:36 |
jamielennox | samueldmq: which requires ayoung (or someone) to actually spin up a full kerberos environment and make sure it's all working | 11:37 |
jamielennox | but that's the only open review at the moment close to merging that should be included | 11:37 |
samueldmq | jamielennox: nice, so we work on merging that and we should be good to make a cut | 11:38 |
jamielennox | if you bug him about +A-ing that then we should be able to do a release | 11:38 |
samueldmq | jamielennox: I assume setting up a full kerberos env requires a lot of work | 11:38 |
samueldmq | jamielennox: specially for someone who have never done it | 11:38 |
jamielennox | stevemar will likely be lurking at the meeting tomorrow - but i'm guessing that would be ok with him | 11:39 |
jamielennox | samueldmq: it's a bit specific if you're not used to working with kerberos | 11:39 |
jamielennox | maybe even if you are | 11:39 |
*** agireud has joined #openstack-keystone | 11:39 | |
yolanda | jamielennox, samueldmq, thx | 11:40 |
jamielennox | especially that method is a bit older, from before federation so I can't remember all the details | 11:40 |
jamielennox | but you're welcome/encouraged to try :) | 11:40 |
jamielennox | it's one i would love to have running as a functional test | 11:40 |
samueldmq | yolanda: you're welcome; I will work with other cores to get that merged so we can make a cut | 11:40 |
jamielennox | but realistically requires freeipa | 11:41 |
samueldmq | jamielennox: k, I hope ayoung will be able to set that env up and test it | 11:41 |
samueldmq | jamielennox: otherwise I will give it a try in order to make things move | 11:42 |
*** dmk0202 has joined #openstack-keystone | 11:42 | |
jamielennox | sounds good, i'll be around for the meeting tomorrow so we can talk to him them | 11:43 |
jamielennox | then | 11:43 |
*** dimonv has quit IRC | 11:45 | |
*** dimonv has joined #openstack-keystone | 11:46 | |
samueldmq | jamielennox: nice, thanks | 11:47 |
*** woodster_ has joined #openstack-keystone | 11:52 | |
*** jbell8 has joined #openstack-keystone | 11:54 | |
*** markvoelker has joined #openstack-keystone | 11:55 | |
*** rodrigods has quit IRC | 11:56 | |
*** code-R has joined #openstack-keystone | 11:56 | |
*** rodrigods has joined #openstack-keystone | 11:56 | |
*** markvoelker has quit IRC | 11:57 | |
*** markvoelker has joined #openstack-keystone | 11:57 | |
*** henrynash has joined #openstack-keystone | 11:57 | |
*** ChanServ sets mode: +v henrynash | 11:57 | |
*** itisha has joined #openstack-keystone | 12:04 | |
*** zerda2 has quit IRC | 12:05 | |
openstackgerrit | ChangBo Guo(gcb) proposed openstack/keystonemiddleware: Use method split_path from oslo.utils https://review.openstack.org/323101 | 12:07 |
*** code-R_ has joined #openstack-keystone | 12:14 | |
*** code-R has quit IRC | 12:17 | |
openstackgerrit | Rudolf Vriend proposed openstack/keystone: Allow domain admins to list users in groups with v3 policy https://review.openstack.org/321128 | 12:17 |
*** GB21 has quit IRC | 12:24 | |
*** dave-mccowan has joined #openstack-keystone | 12:25 | |
*** sdake has quit IRC | 12:27 | |
*** gordc has joined #openstack-keystone | 12:32 | |
*** nisha has quit IRC | 12:34 | |
*** nisha has joined #openstack-keystone | 12:48 | |
*** julim has joined #openstack-keystone | 12:53 | |
*** georgem1 has joined #openstack-keystone | 12:54 | |
*** georgem1 has quit IRC | 13:04 | |
*** georgem1 has joined #openstack-keystone | 13:04 | |
*** pauloewerton has joined #openstack-keystone | 13:11 | |
openstackgerrit | Rodrigo Duarte proposed openstack/keystone: Fix credentials_factory method call https://review.openstack.org/323360 | 13:13 |
rodrigods | ^ if anyone could review/+A that | 13:17 |
rodrigods | it is currently breaking keystone's functional tests | 13:17 |
*** ayoung has joined #openstack-keystone | 13:22 | |
*** ChanServ sets mode: +v ayoung | 13:22 | |
*** shewless has joined #openstack-keystone | 13:28 | |
shewless | Hello. I'm hoping someone can help me with my keystone ldap authentication using openstack Mitaka. I've got the actual authentication working using ldap (just using read only for identity) but I'm trying to figure out the best way to handle the roles and projects. I want all "ldap" users to have a default role and project. Does anyone know of any documentation for this? I couldn't find any on the keystone website | 13:29 |
*** nisha_ has joined #openstack-keystone | 13:39 | |
lbragstad | henrynash does role assignment inheritance span groups? | 13:39 |
*** nkinder has joined #openstack-keystone | 13:40 | |
raildo | lbragstad: only if you grant the inherited role on the group | 13:41 |
lbragstad | raildo so - should this work? https://bugs.launchpad.net/keystone/+bug/1583142 | 13:41 |
openstack | Launchpad bug 1583142 in OpenStack Identity (keystone) "Roles inheritance for groups is not visible in user's role assignments" [Undecided,New] | 13:41 |
henrynash | lbragstad: how do you mean “span groups”? | 13:42 |
lbragstad | henrynash https://bugs.launchpad.net/keystone/+bug/1583142 | 13:42 |
openstack | Launchpad bug 1583142 in OpenStack Identity (keystone) "Roles inheritance for groups is not visible in user's role assignments" [Undecided,New] | 13:42 |
*** nisha has quit IRC | 13:42 | |
*** yolanda_ has joined #openstack-keystone | 13:43 | |
lbragstad | henrynash i could be using "span" in the wrong context here | 13:43 |
henrynash | lbragstad: let me read up on the bug…. | 13:43 |
raildo | lbragstad: I think this bug is invalid, a group role shouldn't be listed in the role assignment for users | 13:43 |
*** yolanda has quit IRC | 13:44 | |
lbragstad | henrynash raildo - thanks. I got a few pings about that bug over the weekend and I wanted to talk to the experts | 13:44 |
henrynash | lbragstad, raildo: agreed, it is invalid | 13:44 |
lbragstad | henrynash do you want to update it with a comment? | 13:45 |
henrynash | lbragdstad: will do | 13:45 |
lbragstad | henrynash raildo thanks guys! | 13:45 |
raildo | lbragstad: yw | 13:45 |
*** jbell8 has quit IRC | 13:49 | |
shewless | Hi guys. Does anyone know a good place to read up on keystone configuration? I'm using this guide but it does not give enough detail on LDAP configuration: http://docs.openstack.org/developer/keystone/configuration.html | 13:51 |
henrynash | lbragstad: done | 13:52 |
shewless | Do I need to download the source code and read it or is there some proper documentation that I just can't find? | 13:52 |
*** TxGVNN has joined #openstack-keystone | 13:53 | |
*** tonytan4ever has joined #openstack-keystone | 13:54 | |
henrynash | shewless: what kind of info do you need? | 13:54 |
shewless | +henrynash: keystone ldap authentication using openstack Mitaka. I've got the actual authentication working using ldap (just using read only for identity) but I'm trying to figure out the best way to handle the roles and projects. I want all "ldap" users to have a default role and project. | 13:55 |
henrynash | shewless: so your roles and projects are in SQL I assume | 13:55 |
*** ametts has joined #openstack-keystone | 13:56 | |
*** edtubill has joined #openstack-keystone | 13:56 | |
*** richm has joined #openstack-keystone | 13:57 | |
shewless | +henrynash: they are stored in SQL. But I created two domains.. one "default" and one "ldap". All of the service accounts are in the "default" domain. | 13:57 |
henrynash | shewless: a perfectly sensible set up... | 13:58 |
shewless | +henrynash: I think I could create a role/project in the ldap domain and then manually assign a user to it.. but we have about 300 users in ldap and I want them all to be able to login without having to manually assign roles, etc. Is that possible? | 13:58 |
shewless | +henrynash: do I use policy.json? | 13:59 |
henrynash | shewless: no, not policy.json…. | 13:59 |
henrynash | shawless: is there a group that these uses are a member of | 13:59 |
henrynash | shawless:? | 13:59 |
shewless | +henrynash: from an active directory perspective.. no | 14:00 |
henrynash | shewless: hmm, that’s a shame | 14:00 |
shewless | +henrynash: I wanted to avoid that but if it was completely necessary I could probably make it happen. In the end the ldap connection must be read only though.. | 14:01 |
henrynash | shewless: so the simplest way would be to have them in a group in AD, which would therfore show up as a group in keystone (via the ldap connection), and then you coould assign a role to the group on a project or domain. | 14:02 |
*** jbell8 has joined #openstack-keystone | 14:02 | |
henrynash | shewless: you could even assign an inherited role to the domain, so that they had a role on ALL projects if that’s what you wanted | 14:02 |
*** jaosorior has quit IRC | 14:03 | |
rodrigods | do we know the issue with keystone-coverage-db? | 14:03 |
*** eszxy has quit IRC | 14:04 | |
shewless | +henrynash: okay I can try that. what config would I have to change to make that happen? Also I think I want each user to have their own project. Is there a way to do that? | 14:04 |
shewless | +henrynash: unfortunately I have to go right now. but I'll be back in an hour or so. I hope I can sync up with you on this. Is there a good way to get a hold of you ? | 14:04 |
rodrigods | raildo, did you investigate further yesterday ^ ? | 14:04 |
henrynash | shewless: so there isn’t a way of auto creating such proejcts….I think you are starting to talk about an orchestrator type functionality | 14:05 |
henrynash | shawless: I should be around here. | 14:05 |
*** rderose has joined #openstack-keystone | 14:08 | |
raildo | rodrigods: no :( | 14:12 |
*** d0ugal has quit IRC | 14:15 | |
*** d0ugal has joined #openstack-keystone | 14:16 | |
*** phalmos has joined #openstack-keystone | 14:19 | |
*** EinstCrazy has joined #openstack-keystone | 14:19 | |
*** phalmos_ has joined #openstack-keystone | 14:22 | |
*** pushkaru has joined #openstack-keystone | 14:23 | |
*** phalmos has quit IRC | 14:26 | |
*** darosale has joined #openstack-keystone | 14:28 | |
*** nisha_ has quit IRC | 14:29 | |
*** tonytan4ever has quit IRC | 14:30 | |
openstackgerrit | Ron De Rose proposed openstack/keystone: PCI-DSS Change password requirements https://review.openstack.org/320156 | 14:32 |
openstackgerrit | Ron De Rose proposed openstack/keystone: Add password table columns to meet PCI-DSS change password requirements https://review.openstack.org/314284 | 14:38 |
openstackgerrit | Ron De Rose proposed openstack/keystone: PCI-DSS Change password requirements https://review.openstack.org/320156 | 14:38 |
*** jaugustine has joined #openstack-keystone | 14:41 | |
*** raddaoui has joined #openstack-keystone | 14:42 | |
*** gagehugo has joined #openstack-keystone | 14:44 | |
*** henrynash has quit IRC | 14:45 | |
rodrigods | raildo, found it: https://review.openstack.org/#/c/321704/5 | 14:49 |
patchbot | rodrigods: patch 321704 - oslo.messaging - Updated from global requirements | 14:49 |
raildo | rodrigods: \o/ | 14:49 |
*** ayoung has quit IRC | 14:51 | |
openstackgerrit | Ron De Rose proposed openstack/keystone: WIP - PCI-DSS Password strength requirements https://review.openstack.org/320586 | 14:51 |
openstackgerrit | Ron De Rose proposed openstack/keystone: WIP - PCI-DSS Password strength requirements https://review.openstack.org/320586 | 14:51 |
*** wasmum has quit IRC | 14:52 | |
*** doug-fish has joined #openstack-keystone | 14:55 | |
openstackgerrit | Ron De Rose proposed openstack/keystone: WIP - PCI-DSS Password strength requirements https://review.openstack.org/320586 | 14:55 |
*** timcline has joined #openstack-keystone | 14:55 | |
*** code-R_ has quit IRC | 14:59 | |
openstackgerrit | Ron De Rose proposed openstack/keystone: PCI-DSS Change password requirements https://review.openstack.org/320156 | 14:59 |
shewless | +henrynash: okay so step #1 would be to be allowed to login in the first place using ldap :) In order to do this I guess I have to assign a default role and project. You're saying I should do both of those with a group in active directory? | 14:59 |
openstackgerrit | Ron De Rose proposed openstack/keystone: WIP - PCI-DSS Password strength requirements https://review.openstack.org/320586 | 14:59 |
*** code-R has joined #openstack-keystone | 15:02 | |
stevemar | rodrigods: https://bugs.launchpad.net/keystone/+bug/1587239 and https://bugs.launchpad.net/nova/+bug/1586979 are a good start | 15:04 |
openstack | Launchpad bug 1587239 in OpenStack Identity (keystone) "cover job is failing too frequently" [High,New] | 15:04 |
openstack | Launchpad bug 1586979 in OpenStack Compute (nova) "AMQP 2.0 prevents services from starting" [Undecided,New] | 15:04 |
openstackgerrit | Ron De Rose proposed openstack/keystone: Config settings to support PCI-DSS https://review.openstack.org/314679 | 15:06 |
openstackgerrit | Ron De Rose proposed openstack/keystone: Add password table columns to meet PCI-DSS change password requirements https://review.openstack.org/314284 | 15:06 |
openstackgerrit | Ron De Rose proposed openstack/keystone: PCI-DSS Change password requirements https://review.openstack.org/320156 | 15:06 |
openstackgerrit | Ron De Rose proposed openstack/keystone: WIP - PCI-DSS Password strength requirements https://review.openstack.org/320586 | 15:06 |
*** rcernin has quit IRC | 15:07 | |
shewless | henrynash_: okay so step #1 would be to be allowed to login in the first place using ldap :) In order to do this I guess I have to assign a default role and project. You're saying I should do both of those with a group in active directory? | 15:07 |
openstackgerrit | Alexander Makarov proposed openstack/keystone: Add password table columns to meet PCI-DSS failed https://review.openstack.org/322961 | 15:08 |
*** daemontool_ has joined #openstack-keystone | 15:08 | |
*** daemontool has quit IRC | 15:10 | |
*** daemontool_ has quit IRC | 15:11 | |
*** daemontool__ has joined #openstack-keystone | 15:11 | |
shewless | I see there is this option in the ldap config section: #user_default_project_id_attribute | 15:12 |
shewless | I guess I could create a project in my ldap domain and then fill in this value as a start | 15:12 |
amakarov | rderose, hi! Why have you extracted logic to Authenticator? | 15:13 |
*** links has quit IRC | 15:15 | |
*** code-R has quit IRC | 15:16 | |
*** TxGVNN has quit IRC | 15:16 | |
rderose | amakarov: Planning to add PCI security code to sql_security.py, which included authentication. Authenticator seemed like a nice way to break this up. | 15:16 |
amakarov | rderose, is it a place I should put my changes to? | 15:17 |
amakarov | I mead, related to auth attempts? | 15:17 |
amakarov | s/mead/mean/ | 15:17 |
rderose | amakarov: no, because would only be for sql driver | 15:17 |
rderose | amakarov: lock out is at a higher level | 15:18 |
amakarov | rderose, I need to store the attempts history somewhere | 15:18 |
amakarov | do you have any suggestion? | 15:18 |
amakarov | I thought Password table is a good place for that | 15:18 |
*** dtroyer has joined #openstack-keystone | 15:19 | |
rderose | amakarov: hmm... Password table to keep track of auth attempts? | 15:19 |
amakarov | rderose, failed attempts | 15:19 |
dolphm | dstanek: have your saml work in review somewhere? | 15:20 |
rderose | amakarov: I don't that would belong in the Password table | 15:20 |
rderose | amakarov: seems like a new backend to me | 15:20 |
rderose | amakarov: * I don't think failed auth attempts belongs in the Password table | 15:21 |
amakarov | rderose, why& | 15:21 |
amakarov | ? | 15:21 |
*** belmoreira has quit IRC | 15:22 | |
*** amrith is now known as _amrith_ | 15:22 | |
*** _amrith_ is now known as amrith | 15:23 | |
rderose | amakarov: so you're thinking of adding a failed attempts count to the password table? that column wouldn't make sense for expired passwords. | 15:24 |
amakarov | rderose, not a count - a log. timestamps | 15:25 |
amakarov | rderose, so that it it can be tracked | 15:25 |
stevemar | dolphm: i just realized you were on superuser tv https://www.youtube.com/watch?v=s3JxnnuBBe4 | 15:25 |
stevemar | dolphm: so famous! | 15:25 |
rderose | amakarov: right, so I don't see how this fits with the password table, e.g. user has 2 passwords saved and have 5 failed attempts | 15:27 |
dolphm | stevemar: there's no way i'm watching that | 15:27 |
rderose | amakarov: how many rows are in the password table? | 15:27 |
stevemar | dolphm: i shall watch it | 15:27 |
dolphm | stevemar: that was after 2 or 3 days of super minimal sleep. i had a terrible headache :( | 15:27 |
*** EinstCrazy has quit IRC | 15:28 | |
*** EinstCrazy has joined #openstack-keystone | 15:29 | |
*** EinstCrazy has quit IRC | 15:29 | |
rderose | amakarov: it seems like a new table to me, failed_auth_history or something (user_id, timestamp, msg...) | 15:29 |
*** spzala has joined #openstack-keystone | 15:29 | |
amakarov | rderose, well, I haven't seen it from this point: thought it's only 1 password per user | 15:29 |
amakarov | rderose, I agree about a new table then | 15:30 |
rderose | amakarov: local_user to password is 1 to many | 15:30 |
rderose | amakarov: cool | 15:30 |
*** openstackgerrit has quit IRC | 15:33 | |
*** openstackgerrit has joined #openstack-keystone | 15:33 | |
lbragstad | stevemar dolphm I love tim's plug at the end to upgrade to keystone v3 | 15:34 |
dolphm | lol | 15:35 |
*** code-R has joined #openstack-keystone | 15:35 | |
*** wasmum has joined #openstack-keystone | 15:38 | |
*** phalmos_ has quit IRC | 15:40 | |
*** TxGVNN has joined #openstack-keystone | 15:40 | |
*** phalmos has joined #openstack-keystone | 15:40 | |
*** KevinE has joined #openstack-keystone | 15:41 | |
*** dmk0202 has quit IRC | 15:42 | |
shewless | hi dudes. I have ldap auth working (for identity).. but I have to do two steps manually for every new user: openstack project create --domain foo.com user_1 openstack role add --project user_1 --user user_1 --user-domain foo.com user | 15:43 |
shewless | I have to do that because I want each user to have their own project (which is the same name as their user). Anyone know if there is a way to do that automagically? | 15:43 |
*** ayoung has joined #openstack-keystone | 15:45 | |
*** ChanServ sets mode: +v ayoung | 15:45 | |
KevinE | https://review.openstack.org/#/c/321809/ I got my change reviewed and got -1 all around. Can anyone take a look and help me understand what the reviewers are suggesting I change? I'm really lost aside from them knowing it's wrong | 15:50 |
patchbot | KevinE: patch 321809 - python-keystoneclient - OS_INTERFACE ignored when determining endpoint_type | 15:50 |
*** tesseract has quit IRC | 15:54 | |
*** tonytan4ever has joined #openstack-keystone | 15:54 | |
*** nisha_ has joined #openstack-keystone | 15:56 | |
amakarov | rderose, it looks like I have to add that backend directly to auth rather than identity if I want it independent from the identity driver | 15:56 |
amakarov | rderose, is there a spec CR about PCI or it already merged? | 15:57 |
*** pcaruana has quit IRC | 15:59 | |
*** dan_nguyen has joined #openstack-keystone | 15:59 | |
*** nisha_ has quit IRC | 15:59 | |
*** henrynash has joined #openstack-keystone | 16:00 | |
*** ChanServ sets mode: +v henrynash | 16:00 | |
*** gyee has joined #openstack-keystone | 16:00 | |
*** ChanServ sets mode: +v gyee | 16:00 | |
henrynash | shewless: hi | 16:01 |
*** dimonv has quit IRC | 16:01 | |
*** nisha_ has joined #openstack-keystone | 16:02 | |
*** gokrokve has joined #openstack-keystone | 16:04 | |
*** lhcheng has joined #openstack-keystone | 16:07 | |
*** ChanServ sets mode: +v lhcheng | 16:07 | |
rderose | amakarov: hmm... do you think failed attempts belongs in identity though? we're only talking about locking failed auth for identity (ldap, sql, custom...) | 16:10 |
*** phalmos has quit IRC | 16:11 | |
rderose | amakarov: and not federation for example | 16:11 |
rderose | amakarov: PCI specs: #link https://github.com/openstack/keystone-specs/blob/master/specs/keystone/newton/pci-dss.rst | 16:11 |
amakarov | rderose, thank you | 16:15 |
rderose | amakarov: np | 16:15 |
*** pushkaru has quit IRC | 16:17 | |
dstanek | dolphm: no, but i'm working on keystone again today so i can start pushing | 16:21 |
*** nisha_ has quit IRC | 16:22 | |
dstanek | rderose: i just reviewed the shadow ldap patch and i'm wondering if there is some sort of migration need or if non-local users created on the fly is sufficient | 16:24 |
*** ayoung has quit IRC | 16:25 | |
*** mugsie_ has joined #openstack-keystone | 16:25 | |
*** nisha_ has joined #openstack-keystone | 16:25 | |
rderose | dstanek: to me on-the-fly (authentication) is sufficient, but do you have a concern | 16:26 |
samueldmq | rderose: just a minor comment in patch 314679 | 16:28 |
patchbot | samueldmq: https://review.openstack.org/#/c/314679/ - keystone - Config settings to support PCI-DSS | 16:28 |
samueldmq | rderose: otherwise looks good | 16:28 |
rderose | samueldmq: makes sense, thanks | 16:28 |
openstackgerrit | Ron De Rose proposed openstack/keystone: Config settings to support PCI-DSS https://review.openstack.org/314679 | 16:30 |
KevinE | actually new idea, can someone check this out when you have a free second? https://review.openstack.org/#/c/320056/ | 16:30 |
patchbot | KevinE: patch 320056 - rally - Tie endpoint_type to interface | 16:30 |
KevinE | I know it's a rally change, but it's really a keystone issue | 16:31 |
*** pushkaru has joined #openstack-keystone | 16:31 | |
samueldmq | rderose: thanks | 16:32 |
rderose | samueldmq: thank you :) | 16:33 |
dstanek | rderose: no, no concern. just trying to figure out if i should be | 16:33 |
samueldmq | is it just on my patches, or keystone-coverage-db is so broken that no patch pass jenkins jobs ? | 16:33 |
rderose | dstanek: cool. yeah, the only reason I think to do a migration is if were changing the user ID | 16:34 |
rderose | samueldmq: it's failing my patches as well | 16:35 |
*** jbell8 has quit IRC | 16:35 | |
*** arunkant has joined #openstack-keystone | 16:36 | |
nisha_ | samueldmq, I am trying to follow this guide http://docs.openstack.org/developer/python-keystoneclient/api/keystoneclient.v3.html#module-keystoneclient.v3.groups | 16:36 |
nisha_ | samueldmq, there is an example using >>> user = keystone.users.get(USER_ID) | 16:37 |
nisha_ | >>> user.delete() | 16:37 |
samueldmq | nisha_: nice, that describes the group operation in the client | 16:38 |
nisha_ | samueldmq, what should I use in place of USER_ID? | 16:38 |
samueldmq | nisha_: the ID of an existing user in keystone server | 16:39 |
samueldmq | nisha_: to see what users exist, you can list them all with keystone.users.get() | 16:39 |
samueldmq | nisha_: doing keystone.users.get(USER_ID) will return the user object (from keystone server) that matches the provided ID, it it exists | 16:40 |
nisha_ | samueldmq, so, after doing keystone.users.list() i can put any user's id in place of USER_ID in the command right? | 16:41 |
*** ayoung has joined #openstack-keystone | 16:42 | |
*** ChanServ sets mode: +v ayoung | 16:42 | |
*** nisha_ has quit IRC | 16:42 | |
openstackgerrit | Merged openstack/keystone-specs: Microversions https://review.openstack.org/315180 | 16:42 |
*** permalac has quit IRC | 16:42 | |
*** rderose has quit IRC | 16:44 | |
*** TxGVNN has quit IRC | 16:45 | |
*** tonytan4ever has quit IRC | 16:46 | |
*** diazjf has joined #openstack-keystone | 16:47 | |
*** nisha_ has joined #openstack-keystone | 16:49 | |
openstackgerrit | Merged openstack/keystonemiddleware: Use method split_path from oslo.utils https://review.openstack.org/323101 | 16:50 |
*** diazjf has quit IRC | 16:50 | |
*** nisha_ has quit IRC | 16:50 | |
openstackgerrit | Alexander Makarov proposed openstack/keystone-specs: Allow admin to specify project id on creation https://review.openstack.org/323499 | 16:51 |
*** mvk has quit IRC | 16:51 | |
*** spandhe has joined #openstack-keystone | 16:53 | |
*** nisha_ has joined #openstack-keystone | 16:59 | |
*** nisha_ has quit IRC | 17:00 | |
*** sigmavirus24 is now known as sigmavirus24_awa | 17:00 | |
*** links has joined #openstack-keystone | 17:00 | |
*** clenimar has joined #openstack-keystone | 17:00 | |
*** woodburn has joined #openstack-keystone | 17:00 | |
*** alex_xu has quit IRC | 17:00 | |
*** mugsie_ is now known as mugsie | 17:01 | |
*** rcernin has joined #openstack-keystone | 17:01 | |
*** phalmos has joined #openstack-keystone | 17:02 | |
*** alex_xu has joined #openstack-keystone | 17:02 | |
*** nisha_ has joined #openstack-keystone | 17:04 | |
*** gokrokve has quit IRC | 17:06 | |
*** amrith is now known as _amrith_ | 17:09 | |
*** rderose has joined #openstack-keystone | 17:10 | |
*** links has quit IRC | 17:11 | |
*** jbell8 has joined #openstack-keystone | 17:12 | |
openstackgerrit | guang-yee proposed openstack/keystonemiddleware: Support local config options https://review.openstack.org/321882 | 17:12 |
nisha_ | samueldmq, I have been trying to add a user to a group using add_to_group(user, group) | 17:13 |
samueldmq | nisha_: nice, for that you will need to provide both a valid user ID and group ID | 17:13 |
nisha_ | samueldmq, yeah, I did that, but it says NameError: name 'add_to_group' is not defined | 17:14 |
samueldmq | nisha_: again, you can create them; or simply list what's available with client.users.list() and client.groups.list() | 17:14 |
samueldmq | nisha_: keystone.users.add_to_group(...) ? | 17:15 |
samueldmq | nisha_: notice it's in users module http://docs.openstack.org/developer/python-keystoneclient/api/keystoneclient.v3.html#keystoneclient.v3.users.UserManager.add_to_group | 17:15 |
*** tonytan4ever has joined #openstack-keystone | 17:16 | |
shewless | +henrynash: hi | 17:17 |
henrynash | shewless: hi | 17:17 |
*** rderose_ has joined #openstack-keystone | 17:18 | |
nisha_ | samueldmq, I did this user = ks.users.get(USER_ID) and group = ks.users.get(GROUP_ID) and then ran add_to_group(user,group) | 17:18 |
nisha_ | samueldmq, what should have been the exact command? | 17:18 |
samueldmq | nisha_: didn't that work ? | 17:19 |
shewless | +henrynash: so I got ldap to work and i used "user_default_project_id_attribute" = "user_name_attribute" | 17:19 |
henrynash | shawless: ok | 17:19 |
shewless | +henrynash: that will associate each user with their own unique project. | 17:19 |
nisha_ | samueldmq, Also, when I run delete(user), NameError: name 'delete' is not defined | 17:19 |
henrynash | shawless: although it won’t create such a project | 17:19 |
shewless | +henrynash: but I need to manually create the project | 17:19 |
samueldmq | nisha_: client.users.delete(user) | 17:20 |
nisha_ | samueldmq, when I do user.delete() then it deletes | 17:20 |
henrynash | shewless: indeed…you ar really into orchestration territory here…. | 17:20 |
shewless | +henrynash: exactly... using an ldap group wouldn't help me with that would it? | 17:20 |
samueldmq | nisha_: see http://docs.openstack.org/developer/python-keystoneclient/api/keystoneclient.v3.html#keystoneclient.v3.users.UserManager.delete | 17:20 |
shewless | +henrynash: I'm not sure what you mean by that.. | 17:20 |
samueldmq | nisha_: all the operations are documented there | 17:20 |
henrynash | shewless: so we often have this debate about how much “automaction” keystone should do in these kinds of situations | 17:20 |
*** rderose has quit IRC | 17:21 | |
*** tonytan4ever has quit IRC | 17:21 | |
samueldmq | nisha_: if it's users module, then keystone.users.<operation>; for groups: keystone.groups.<operation>, etc | 17:21 |
nisha_ | samueldmq, yes, I am trying to follow it | 17:21 |
samueldmq | nisha_: the operations are described there, by module | 17:21 |
shewless | +henrynash: I'd be okay doing it outside of keystone if that's what it took.. but I'm not sure where I would do it. It's like I'm 90% where I need to be :D | 17:21 |
henrynash | shewless: and I think, in general, we consider the need to auto create a project fro each user in LDAP more of an ochestration feature….which is not keystone | 17:21 |
*** _amrith_ is now known as amrith | 17:21 | |
shewless | +henrynash: okay: do you know what service I would use for orchestration? | 17:22 |
samueldmq | nisha_: so you don't call delete(user), you always need to call the keystoneclient instance | 17:22 |
shewless | ..and would I experience this same challenge if I used "federation"? | 17:22 |
samueldmq | nisha_: so in your case: keystone.users.delete(x), where x is a user object or a user ID | 17:22 |
*** nisha_ has quit IRC | 17:22 | |
henrynash | shewless: yes, if you really want to auto-create a project per user, then federation doesn’t help you | 17:23 |
henrynash | shewless: the groups don’t either, that would be for a different use case | 17:24 |
shewless | +henrynash: so when you say "orchestration" I think "heat" -- but that's not what you're talking about here right? | 17:24 |
henrynash | shewless: in theory the openstack mistral project should be the thing to use | 17:24 |
henrynash | shewless: or at least that would be the pure openstack solution…I have never used it | 17:25 |
*** tonytan4ever has joined #openstack-keystone | 17:25 | |
shewless | +henrynash: thanks for your help | 17:26 |
*** nisha_ has joined #openstack-keystone | 17:26 | |
henrynash | shewless: e.g. really dumb solution would…write a workflow that occasionally read teh users from keystone that were in the ldap domain, and made sure each of them had a proejct created for them and a role assigned | 17:26 |
henrynash | shewless: not vrey nice, since polling all users from ldap is not a nice thing to do….but you get teh concept | 17:27 |
*** nisha_ has quit IRC | 17:31 | |
*** agrebennikov has joined #openstack-keystone | 17:31 | |
*** nisha_ has joined #openstack-keystone | 17:32 | |
shewless | +henrynash: good idea.. I think we actually already have a "dumb" new user script that runs.. maybe it can just do these 2 things | 17:35 |
henrynash | shewless: ok | 17:36 |
*** JayF has joined #openstack-keystone | 17:37 | |
JayF | jamielennox: are you still actively working on https://review.openstack.org/#/c/245629 ? I'm working to implement better policy support for Ironic, and was looking for some kind of guideline, and this looks | 17:37 |
JayF | jamielennox: like it's on the right track | 17:37 |
*** itisha has quit IRC | 17:40 | |
*** wasmum has quit IRC | 17:41 | |
*** amrith is now known as _amrith_ | 17:44 | |
KevinE | Can anyone tell me why this does not pass endpoint_type? https://github.com/openstack/rally/blob/master/rally/osclients.py#L242-L251 | 17:49 |
*** roxanaghe has joined #openstack-keystone | 17:51 | |
*** Alexander has joined #openstack-keystone | 17:52 | |
*** Alexander is now known as Guest42740 | 17:52 | |
*** amakarov has quit IRC | 17:54 | |
*** Guest42740 is now known as amakarov | 17:54 | |
*** alexander__ has joined #openstack-keystone | 17:54 | |
*** daemontool__ has quit IRC | 17:54 | |
*** daemontool has joined #openstack-keystone | 17:55 | |
*** haneef has joined #openstack-keystone | 17:55 | |
*** jaugustine has quit IRC | 17:56 | |
openstackgerrit | henry-nash proposed openstack/keystone-specs: Support hierarchical project naming https://review.openstack.org/318605 | 17:57 |
*** jaugustine has joined #openstack-keystone | 17:58 | |
*** jbell8 has quit IRC | 17:58 | |
*** jbell8 has joined #openstack-keystone | 17:59 | |
*** nkinder has quit IRC | 18:01 | |
notmorgan | meeting time: ajayaa, amakarov, ayoung, breton, browne, crinkle, claudiub, davechen, david8hu, dolphm, dstanek, edmondsw, gyee, henrynash, hogepodge, htruta, jamielennox, joesavak, jorge_munoz, knikolla, lbragstad, lhcheng, marekd, MaxPC, morgan, nkinder, notmorgan, raildo, rodrigods, rderose, roxanaghe, samleon, samueldmq, shaleh, stevemar, tjcocozz, tsymanczyk, topol, vivekd, wanghong, xek | 18:01 |
*** gagehugo_ has joined #openstack-keystone | 18:02 | |
amakarov | agrebennikov: please join #openstack-meeting | 18:03 |
*** shaleh has joined #openstack-keystone | 18:05 | |
*** gagehugo_ has quit IRC | 18:06 | |
jlk | Question. Looking at the API ref for v3 users, it seems like I (as admin in the default domain) should be able to just list users, and get every user across every domain. I can _optionally_ filter by domain in my /v3/users request, which seems to indicate that I should get back every user. | 18:07 |
jlk | However I'm only getting users from the 'default' domain, the domain in which my admin user exists. What would prevent me from automatically seeing users in every domain? ( using the client I can list users of a specific domain and see them ) | 18:07 |
*** gagehugo_ has joined #openstack-keystone | 18:07 | |
rodrigods | jlk, is listing every user from every domain a desirable thing for you? It is currently restricted in the policy file | 18:09 |
rodrigods | you would need to change the rule | 18:09 |
jlk | rodrigods: maybe. | 18:09 |
*** jed56 has quit IRC | 18:09 | |
jlk | rodrigods: I'm really trying to understand how the API is structured though. This is for automation, I'm trying to determine if a user already exists. | 18:09 |
jlk | I need to at least be able to list hte users of a particular domain, and the API reference is confusing on that regard. | 18:10 |
lhcheng | the username is unique by Domain, I think you have to check in each Domain | 18:10 |
jlk | lhcheng: I would, yes. I'm working up to that point | 18:11 |
rodrigods | jlk, and the powers to list everything everywhere is from the cloud_admin: https://github.com/openstack/keystone/blob/master/etc/policy.v3cloudsample.json#L3 | 18:11 |
jlk | Trying to sort out what needs to change where, in keystoneclient code or otherwise. | 18:11 |
jlk | rodrigods: but what act is it? There are only two 'list_user' like acts in the policy file | 18:12 |
jlk | rodrigods: and in my policy file the user I'm using is already allowed both of those. | 18:12 |
amakarov | well, colleagues, I repeat my question: do anybody have objections on the bp/spec in question? | 18:13 |
*** flwang has joined #openstack-keystone | 18:13 | |
jlk | since, clearly, my user using the command line client is able to list users of a particular domain | 18:13 |
jlk | so I wonder why is the /v3/users API end point not giving me back every user when no filter is provided? | 18:13 |
*** flwang has quit IRC | 18:14 | |
jlk | ah, looks like the APi forces a list_users call to have a domain_id in the hints. | 18:15 |
jlk | *grumble* | 18:15 |
rodrigods | jlk, ah, yes | 18:15 |
rodrigods | that's the case | 18:15 |
rodrigods | it uses the domain_id from the context | 18:15 |
jlk | and so to list users of a specific domian, I have to use `domain_id` in the request parameter ? | 18:16 |
jlk | (this is not at all made clear in the API reference) | 18:16 |
*** wasmum has joined #openstack-keystone | 18:17 | |
*** gagehugo_ has quit IRC | 18:17 | |
rodrigods | jlk, yes... you could provide a patch to improve the API reference :) | 18:18 |
jlk | heh. | 18:18 |
rodrigods | jlk, i can help reviewing it | 18:18 |
jlk | so unfortunately it means domain specific knowledge querying needs to happen all the way down at the ansible module, calling shade, and shade level. | 18:19 |
*** doug-fish has quit IRC | 18:20 | |
*** diazjf has joined #openstack-keystone | 18:23 | |
kfox1111 | does the ldap plugin try and validate ldap groups with every validate? | 18:23 |
kfox1111 | or just logins? | 18:23 |
*** doug-fish has joined #openstack-keystone | 18:26 | |
*** gagehugo_ has joined #openstack-keystone | 18:28 | |
*** code-R_ has joined #openstack-keystone | 18:29 | |
*** code-R has quit IRC | 18:29 | |
kfox1111 | how frequently does it rescan ldap? it seems like fairly regularly? | 18:30 |
*** gagehugo_ has quit IRC | 18:30 | |
*** wasmum has quit IRC | 18:36 | |
*** jaugustine has quit IRC | 18:37 | |
*** nisha_ has quit IRC | 18:38 | |
*** doug-fish has quit IRC | 18:40 | |
*** doug-fish has joined #openstack-keystone | 18:40 | |
*** nisha_ has joined #openstack-keystone | 18:41 | |
shewless | would anyone be able to help me with single sign on via federation in keystone? I just got ldap working and now I want to try federation instead. one thing that might be missing is the user_default_project_id_attribute option. I see that in ldap section but not the saml2 section | 18:41 |
dolphm | agrebennikov: sorry, it really sounds like you're trying to solve a data-layer issue at the application layer. you'll probably get what you're looking for from the spec i'm going to put up, but i'd personally suggest fixing your specific problem in the database first | 18:41 |
agrebennikov | dolphm, everything in my world comes from production deployments. | 18:42 |
agrebennikov | first, you always have to avoid cross-dc activity if possible | 18:42 |
agrebennikov | second, you have to make sure that any kind of disconnection doesn't cause service interuption | 18:43 |
agrebennikov | as well as race conditions | 18:43 |
*** doug-fish has quit IRC | 18:43 | |
*** doug-fish has joined #openstack-keystone | 18:43 | |
rodrigods | agrebennikov, yeah... but as dolphm said, the proposal looks like a "hack" to keystone to make that work | 18:43 |
agrebennikov | and there is a third reason actually | 18:43 |
*** nisha__ has joined #openstack-keystone | 18:44 | |
openstackgerrit | Ron De Rose proposed openstack/keystone: WIP - Shadow LDAP and custom driver users https://review.openstack.org/305487 | 18:44 |
agrebennikov | the approach I'm trying to use allows to setup both DCs completely separately (which means any deployment tools in different DCs don't have to know about each other) | 18:45 |
agrebennikov | (since I'm mostly working with automation) | 18:45 |
agrebennikov | dolphm, rodrigods what I'm trying to realize and I cannot - what is the reason of declining this kind of super-simple changes? | 18:46 |
*** doug-fish has quit IRC | 18:46 | |
agrebennikov | it is not "do smtng" change | 18:46 |
rodrigods | agrebennikov, fair enough... did you try to do some testing with the change you are proposing? every time something like that happens really strange stuff happens | 18:46 |
*** doug-fish has joined #openstack-keystone | 18:46 | |
agrebennikov | rodrigods, what you mean? testing what | 18:46 |
*** nisha_ has quit IRC | 18:47 | |
rodrigods | agrebennikov, i mean... a change like that might have really unpredictable outcomes | 18:47 |
agrebennikov | rodrigods, in v2 case (where it works out of the box) we have a prod deployment with about 50 zones | 18:48 |
rodrigods | because everything on top of the v3 API was thought assuming that behavior | 18:48 |
amakarov | rodrigods: we didn't do it downstream so we can't provide such insight | 18:48 |
agrebennikov | where the projects are created automatically with same IDs | 18:48 |
shewless | this documentation looks quite old: http://docs.openstack.org/developer/keystone/federation/federated_identity.html .. tested on ubuntu 12.04.. does anyone know of a more up-to-date version? | 18:48 |
agrebennikov | rodrigods, what I could only do - take liberty and make a db hack to make the IDs of current projects the same | 18:48 |
rodrigods | agrebennikov, also have in mind that changing this, also changes domains | 18:49 |
openstackgerrit | Ron De Rose proposed openstack/keystone: WIP - Shadow LDAP and custom driver users https://review.openstack.org/305487 | 18:50 |
agrebennikov | rodrigods, this is correct, but when we have the same set of users | 18:50 |
*** doug-fis_ has joined #openstack-keystone | 18:50 | |
agrebennikov | it automatically means we have the same domain | 18:50 |
agrebennikov | rodrigods, or you are talkning about smtng else? | 18:51 |
*** doug-fish has quit IRC | 18:51 | |
rodrigods | agrebennikov, this is for your deployment... i'm wondering the effect it would have in different kinds of deployments | 18:52 |
rodrigods | (allowing to set the domain name) | 18:52 |
agrebennikov | rodrigods, name or id? | 18:52 |
rodrigods | id* | 18:52 |
rodrigods | agrebennikov, nvm, let's wait for dolphm spec :) | 18:52 |
agrebennikov | rodrigods, I didn't actually get what it is exactly about ;() | 18:53 |
agrebennikov | rodrigods, again some "lets use federation for everything" thing? | 18:53 |
rodrigods | agrebennikov, federation is usually the right answer for this problem | 18:54 |
rodrigods | keystone is not that good in authn | 18:54 |
KevinE | Whenever I try to run keystone testing against a public endpoint, I get an error that says "Failed to contact the endpoint at http://theAdminUrl:35357 for discovery". Why on earth? | 18:54 |
agrebennikov | KevinE, probably because the os var tells it to go to admin endpoint? | 18:55 |
agrebennikov | rodrigods, federation setup is usually supercomplicated and unclear)) this is the answer ;) | 18:56 |
KevinE | agrebennikov: OS_INTERFACE=public and OS_ENDPOINT_TYPE=publicURL | 18:56 |
agrebennikov | KevinE, how you call keystone? | 18:56 |
rodrigods | agrebennikov, don't say that :) you would hurt my feelings | 18:56 |
KevinE | agrebennikov: What do you mean? I'm doing the sample create_delete_user | 18:57 |
agrebennikov | rodrigods, it took about a year to realize "saml, keystone, shib, apache, sso, assertions" combination and roles)) | 18:58 |
agrebennikov | KevinE, but does it get a catalog properly with public url available? or it happens on the first step when it tries to get the catalog | 18:59 |
notmorgan | ok so-- keystone-coresec. we have a lot of people on the list. | 19:00 |
agrebennikov | KevinE, obviously on the first call | 19:00 |
*** diazjf has quit IRC | 19:00 | |
agrebennikov | but can you print the url it is calling to? | 19:00 |
notmorgan | who is legitimately available and comitting to be the first line of defence on triaging security bugs? | 19:00 |
*** nisha__ is now known as nisha_ | 19:00 | |
*** shaleh is now known as shaleh|away | 19:00 | |
notmorgan | i'd like to get us down to ~5 people on the list. | 19:01 |
gyee | notmorgan, sure | 19:01 |
KevinE | agrebennikov: http://pastebin.com/HM3qgaCt | 19:01 |
henrynash | notmorgan: I’ll step down from the list | 19:01 |
samueldmq | notmorgan: triaging bugs that are tagged as security issue ? | 19:01 |
lbragstad | jamielennox I was just waving good bye | 19:01 |
notmorgan | samueldmq: correct, these would be the private bugs. | 19:01 |
*** pushkaru has quit IRC | 19:01 | |
*** pumarani__ has joined #openstack-keystone | 19:01 | |
gyee | btw, betamax sound like a muscle building protein shake :-) | 19:02 |
KevinE | agrebennikov: let me know if that answers your question :) | 19:02 |
agrebennikov | KevinE, can you please show you cloud json | 19:02 |
notmorgan | so, stevemar is staying on it (PTL), | 19:02 |
samueldmq | notmorgan: I'd like to be part of the team; I have worked in a security bug in the past (when I wasn't core and you were ptl) | 19:02 |
samueldmq | notmorgan: if there is still available spots, of course | 19:02 |
notmorgan | ok so here is the way i'm going to do it. | 19:02 |
ayoung | jamielennox, ok...lets focus on a mechanism before tackling the whole service toke thing | 19:03 |
*** diazjf has joined #openstack-keystone | 19:03 | |
jamielennox | lbragstad: ah, i thought you were trying to do like a catch attention from the back with something to say | 19:03 |
notmorgan | i'm going to just ask the individuals who are on it. | 19:03 |
dstanek | notmorgan: do a lottery | 19:03 |
notmorgan | for now. | 19:03 |
ayoung | how does, say, nova know that an operation would be legal on , say Cinder? | 19:03 |
* samueldmq nods | 19:04 | |
notmorgan | dstanek: eh. i think most people don't look at the private bugs besides dolphm, me, and steve (primarily) | 19:04 |
rodrigods | notmorgan, 5 besides you and stevemar ? | 19:04 |
ayoung | we have two ways to check... | 19:04 |
KevinE | agrebennikov: http://pastebin.com/PXqMWmTK | 19:04 |
dstanek | notmorgan: and brant | 19:04 |
ayoung | 1. have some flag in the APi call which is "check but don't really do it" | 19:04 |
ayoung | and look at the response code | 19:04 |
ayoung | the other is to make the call with no permissions and get back "here are the roles you need once you authenticate" | 19:04 |
notmorgan | jamielennox: are you ok with stepping down from core-sec? | 19:05 |
jamielennox | notmorgan: i haven't done much sec stuff recently if you want to kick me, i've been following the bugs but not participating (as they're mostly not interesting atm) | 19:05 |
notmorgan | jamielennox: you'll probably be looped in anyway for client etc. | 19:05 |
ayoung | you can guess which I like better, and which I think you guys are going to go for. | 19:05 |
agrebennikov | KevinE, XXX is adminEndpoint? | 19:05 |
notmorgan | ok | 19:05 |
kfox1111 | is there a way to specify how frequently ldap should scan for changes? | 19:05 |
openstackgerrit | werner mendizabal proposed openstack/keystone-specs: Credential Encryption https://review.openstack.org/284950 | 19:05 |
agrebennikov | KevinE, seems to be a problem with rally workflow - by default in v2 keystone only allows to create tenant/users/assignments through 35357 | 19:06 |
notmorgan | bknudson, ayoung, gyee, dstanek, dolphm: are all of you still comitting to core-sec (security) reviews? | 19:06 |
jamielennox | ayoung: so i'll grant that policy is a huge problem here and i'm aware, but for now i'm really only trying to solve expiration | 19:06 |
agrebennikov | and it doesn't recognize that it should go through 5000 when it is v3 | 19:06 |
gsilvis | dtroyer: still getting that error on a freshly checked out stable/mitaka devstack | 19:06 |
KevinE | agrebennikov: That's what I've been trying to fix for 2.5 weeks now, with 2 rejected changes :/ | 19:06 |
bknudson | notmorgan: I can't commit to anything | 19:06 |
ayoung | jamielennox, the word "only" there scares me | 19:07 |
agrebennikov | KevinE, you'd better ask in #openstack-rally | 19:07 |
notmorgan | bknudson: :( | 19:07 |
KevinE | agrebennikov: no one can help me there, I post in both of these rooms every business day, it's been 2 weeks in the IRC so far :/ | 19:07 |
jamielennox | ayoung: so really i think that all APIs re-entering the public interface is a PITA and a bad design | 19:07 |
jamielennox | ayoung: but OMG the cross-project spec that we would need to fix that | 19:08 |
notmorgan | jamielennox: hehe right? | 19:08 |
jamielennox | ayoung: also did you see https://review.openstack.org/#/c/289405/ ? | 19:08 |
patchbot | jamielennox: patch 289405 - nova-specs - Adds Nova discoverable policy CLI spec | 19:08 |
dstanek | notmorgan: yes, i can commit to it | 19:09 |
jamielennox | i don't think i like it -but that's my first response to most things :p | 19:09 |
KevinE | agrebennikov: Do you have any hints I can use? I'm an extreme Openstack amateur and clearly my attempts at fixing this won't work haha | 19:09 |
notmorgan | dstanek: ok. | 19:09 |
jamielennox | ayoung: but i don't know what else to suggest in the mean time | 19:09 |
KevinE | jamielennox: Unless you can help me, you have me the -1 on my most recent attempt at resolving my issue :) | 19:09 |
agrebennikov | KevinE, what is your adminurl in the catalog? | 19:09 |
dolphm | notmorgan: yes | 19:09 |
notmorgan | i'll keep the team at 7 for now. if folks aren't active on the core-sec stuff i'll drop them in the next round. | 19:09 |
jamielennox | KevinE: sup? sorry wasn't looking at the meeting then people started talking again | 19:10 |
KevinE | agrebennikov: 35357 | 19:10 |
agrebennikov | KevinE, this is nothing about keystone | 19:10 |
notmorgan | there is an active core-sec bug, please go look at it. | 19:10 |
notmorgan | (private security) just make sure you're aware of the state of it | 19:10 |
agrebennikov | KevinE, but does your rally call to this exact url? | 19:10 |
ayoung | jamielennox, yeah, I liketheCLI spec, but I don't think it helps here | 19:11 |
ayoung | jamielennox, if Nova is going to approve for a user, it really should know that the approval is correct | 19:12 |
dstanek | KevinE: what is your issue? did you file a bug? | 19:12 |
ayoung | jamielennox, this is why I was pushing dynamic policy | 19:12 |
KevinE | jamielennox: I'm attempting to fix the fact that "v2 keystone only allows to create tenant/users/assignments through 35357". You shot down an attempt at me changing the service_catalog for understandable reason, but I was wondering if you had any other ideas? | 19:12 |
*** adu has joined #openstack-keystone | 19:12 | |
ayoung | We can't tell a user "hey that is OK" and then later say "We lied" | 19:12 |
ayoung | well, we can.. .we do | 19:12 |
ayoung | we treat users badly | 19:13 |
KevinE | dstanek: https://bugs.launchpad.net/keystone/+bug/1586434 I don't know how to file bugs so please ask for more details if you need them | 19:13 |
openstack | Launchpad bug 1586434 in OpenStack Identity (keystone) "Service Catalog ignores interface" [Undecided,New] | 19:13 |
notmorgan | ayoung: yes we do | 19:13 |
KevinE | agrebennikov: what do you mean does my rally call to that url? | 19:13 |
ayoung | notmorgan, so...lets say I was going to go along with your plan | 19:13 |
jamielennox | ayoung: right, agreed | 19:13 |
agrebennikov | KevinE, in the paste you sent | 19:13 |
dstanek | KevinE: why are you mucking with v2 changes at all? | 19:13 |
ayoung | how do we check that the permissions for glance are OK when we hit the border of Nova? | 19:13 |
agrebennikov | KevinE, http://adminEndpoint:35357 - is this the endpoint from your catalog? | 19:14 |
notmorgan | ayoung: mostly nova does this checking directly. if you look at the workflow. | 19:14 |
KevinE | agrebennikov: dstanek: wait a minute, no this is a v3 issue not v2 sorry | 19:14 |
bknudson | even if we check the permissions could change | 19:14 |
KevinE | agrebennikov: yes it is | 19:14 |
ayoung | notmorgan, but how would Nova know what project owns a volume? | 19:14 |
agrebennikov | KevinE, so seems it is hardcoded in rally to extract the adminurl | 19:14 |
jamielennox | KevinE: so if rally is passing endpoint_type i don't think keystoneclient will mess with it - regarless of api version | 19:14 |
notmorgan | ayoung: nova has to ask cinder "hey XXX volume, we good?" | 19:14 |
agrebennikov | just go ahead and change the db | 19:15 |
ayoung | notmorgan, and how does it do this? | 19:15 |
agrebennikov | KevinE, make it exactly the same as a publc url | 19:15 |
jamielennox | ayoung: i don't have an answer for any of this | 19:15 |
*** tqtran has joined #openstack-keystone | 19:15 | |
ayoung | it needs to know "I am got to do a write call in the future...will that succeed" | 19:15 |
notmorgan | ayoung: today it would use the scope of the user, my point is if nova asks cinder and gets an affirmative, we're good | 19:15 |
jamielennox | agrebennikov: there's a reason to have those two urls seperate, rally should definitely pass the interface it wants to use | 19:15 |
jamielennox | agrebennikov: and if keystoneclient is ignoring that it's a bug | 19:15 |
notmorgan | ayoung: the "check at the edge" is more of a when I ask to make a snapshot and we're given an OK | 19:16 |
jamielennox | notmorgan: that policy check chain then extends the entire length of the actual operation chain | 19:16 |
agrebennikov | jamielennox, I understand it, but in this case the external client seems cannot connect to admin endpoint | 19:16 |
notmorgan | ayoung: don't ask again mid way through | 19:16 |
ayoung | notmorgan, not really. You are thinking Nova to CInder. I am thinking Trove, Sahara, and other services. I don't want to build the CVE right in to the system. Service users should have permissions limited by default | 19:16 |
notmorgan | ayoung: most services can give you an affirmative on all the things they need to do before performing actions. | 19:17 |
agrebennikov | jamielennox, KevinE (rally is this external client) | 19:17 |
jamielennox | agrebennikov: that's generally the right way to deploy it for v2 | 19:17 |
agrebennikov | jamielennox, I know) | 19:17 |
jamielennox | KevinE: so what's going wrong when you tell rally to use public endpoint? | 19:17 |
agrebennikov | jamielennox, but when you want to create/delete users with rally.... | 19:17 |
jamielennox | KevinE: i guess it's optimistic to think that rally is using keystoneauth? | 19:17 |
KevinE | agrebennikov: jamielennox telling rally to use EVERYTHING public fails at contacting the admin endpoint lol | 19:17 |
notmorgan | ayoung: "client like" services are going to use explict delegations. what is trove asking nova for? | 19:17 |
ayoung | notmorgan, So...in general, I am with you on that. We don't want something to fail 8 hours from now that we said was OK right now | 19:18 |
ayoung | normal case | 19:18 |
KevinE | jamielennox: http://pastebin.com/HM3qgaCt | 19:18 |
agrebennikov | jamielennox, I have to ask boris-42 when he is available)) | 19:18 |
ayoung | but I don't want to say "cinder is going to trust any call it get fromNova" | 19:18 |
dstanek | KevinE: is the actually a bug in keystone or a bug in the thing using keystoneclient? | 19:18 |
notmorgan | ayoung: right, this is why i was saying we're mostly on the same page. | 19:18 |
jamielennox | KevinE: right - why is rally trying to contact the admin endopint when it was told not to? | 19:18 |
ayoung | because that will get extended to | 19:18 |
ayoung | "nova will trust any call it gets from *aaS" | 19:18 |
KevinE | Jesus I'm getting so confused lol | 19:18 |
notmorgan | ayoung: so lets look at what sahara asks nova for...or trove | 19:19 |
agrebennikov | jamielennox, it was Not told to contact public)) it contacts public to and gets the catalog, and then it wants to create users. Obviously through admin | 19:19 |
KevinE | dstanek: I don't think I know | 19:19 |
notmorgan | ayoung: lets assume nova/cinder/glance are an easy solve to be trusted... and see how the non-easy cases look | 19:19 |
notmorgan | ayoung: and i think that directs how we approach this. | 19:19 |
KevinE | jamielennox: >>my problem<< lol | 19:19 |
agrebennikov | KevinE, ^^ | 19:20 |
jamielennox | agrebennikov: the client defaults to admin because you needed that for user create in v2, but you can tell the client to do everything via public interface | 19:20 |
jamielennox | agrebennikov: user creation via public interface is fine in v3 | 19:20 |
*** _amrith_ is now known as amrith | 19:20 | |
agrebennikov | jamielennox, then it should be a specific option in rally | 19:20 |
agrebennikov | jamielennox, I know)) | 19:20 |
KevinE | oh sorry, yes agrebennikov is correct I believe | 19:20 |
jamielennox | agrebennikov: ++ | 19:20 |
agrebennikov | that is what I told KevinE | 19:20 |
KevinE | Okay now I'm getting lost sorry agrebennikov jamielennox | 19:21 |
*** roxanaghe has quit IRC | 19:21 | |
notmorgan | ayoung: i think we're getting to an explicit delegation for sahara, which would then be checked at the edge by nova | 19:21 |
agrebennikov | jamielennox, KevinE this is why I have to go poke boris-42 and tell them about it | 19:21 |
jamielennox | cool :) | 19:21 |
notmorgan | ayoung: or well at nova's api surface | 19:21 |
jamielennox | agrebennikov: it would be great if he could use keystoneauth in the process :) | 19:21 |
ayoung | notmorgan, I really want it to be an explicit delegation everywhere, but to make that simple, automatic, and robust | 19:21 |
agrebennikov | KevinE, this is what we usually did with our deployments - we temporarily changed adminurl to be public, tested, changed it back | 19:21 |
notmorgan | ayoung: so i think the core services are going to be a LOT harder to do that with. | 19:22 |
*** gagehugo_ has joined #openstack-keystone | 19:22 | |
ayoung | notmorgan, really? Cuz everything has been soooo easy thus far. | 19:22 |
agrebennikov | KevinE, since we just started v3 implementations | 19:22 |
*** rderose_ has quit IRC | 19:22 | |
notmorgan | ayoung: just because of the volume of interactions. but sahara/trove/etc tend to be more isolated patterns of usage (aka, known request sets) | 19:22 |
KevinE | agrebennikov: so we're saying that this is def a problem correct? | 19:22 |
notmorgan | ayoung: easier to trace. | 19:22 |
agrebennikov | KevinE, for v3/rally - it definitely is | 19:22 |
KevinE | agrebennikov: Currently we have a workaround with a hotfix in service_catalog.py, but my task was to fix it upstream :/ | 19:23 |
KevinE | agrebennikov: and I clearly know nothing | 19:23 |
ayoung | notmorgan, so, I fall back to the question of figuring out how a service user knows that an operation on a remote service is authorized. | 19:23 |
notmorgan | ayoung: but again, lets look at what the *aas things do. | 19:23 |
agrebennikov | KevinE, ping me about 2-3 hours later, I'll poke boris | 19:23 |
ayoung | The right thing would be to make policy enforced on URL, not some randmom majik unmappable string | 19:23 |
*** jbell8 has quit IRC | 19:24 | |
ayoung | and drop the part where it gets the project id, soi we can do it in middleware | 19:24 |
jamielennox | agrebennikov: thanks | 19:24 |
KevinE | agrebennikov: Here, let me send you my 2 proposed changes that do in fact solve the issue, one is just not in the correct way, and the other just fails Mirantis tests | 19:24 |
ayoung | and then make a query interface in to keystone, and stick all policy in keystone | 19:24 |
*** gagehugo_ has quit IRC | 19:24 | |
notmorgan | ayoung: wait what? scope check in the middleware? | 19:24 |
ayoung | notmorgan, no | 19:24 |
notmorgan | ayoung: ok phew | 19:24 |
ayoung | not scope echjeck | 19:24 |
ayoung | role check only | 19:24 |
notmorgan | was gonna call you crazy ;) | 19:24 |
KevinE | agrebennikov: https://review.openstack.org/#/c/320056/ https://review.openstack.org/#/c/321809/ | 19:25 |
notmorgan | ayoung: i think we already said that was a good idea. | 19:25 |
patchbot | KevinE: patch 320056 - rally - Tie endpoint_type to interface | 19:25 |
patchbot | KevinE: patch 321809 - python-keystoneclient - OS_INTERFACE ignored when determining endpoint_type | 19:25 |
ayoung | notmorgan, "drop the part..." | 19:25 |
nisha_ | hey all! | 19:25 |
*** amakarov has quit IRC | 19:25 | |
notmorgan | ayoung: url matching | 19:25 |
notmorgan | ayoung: and such | 19:25 |
ayoung | notmorgan, yep..the URL matching is the tricky part | 19:25 |
KevinE | agrebennikov: with that, I will get back to you in 2 hours, feel free to ping me whenever! | 19:25 |
*** sheel has quit IRC | 19:25 | |
notmorgan | ayoung: and i think everyone liked it. | 19:25 |
ayoung | notmorgan, and yet it died... | 19:25 |
ayoung | so...I thinkI have an anser to one part of that | 19:25 |
agrebennikov | KevinE, ok, sounds good | 19:26 |
notmorgan | ayoung: no, it just didn't get implemented in oslo.policy | 19:26 |
nisha_ | I have a doubt. I ran ./stack.sh and after completion it said there are two users admin and default with password nomoresecret | 19:26 |
ayoung | the "how do we get the right policy for an endpoiint" | 19:26 |
notmorgan | it didn't die so much as whithered. | 19:26 |
gyee | url matching, as in endpoint enforcement? | 19:26 |
notmorgan | ayoung: match the URI part first. | 19:26 |
notmorgan | not the endpoint part | 19:26 |
notmorgan | we can do this in steps. | 19:26 |
notmorgan | chop host/port off and match the request. | 19:26 |
notmorgan | those are "known" in all cases | 19:26 |
ayoung | notmorgan, so...the endpoints didn't know their own identity | 19:27 |
notmorgan | thye don't have to . | 19:27 |
notmorgan | not for this part. | 19:27 |
ayoung | there were a couple waysto resolve that | 19:27 |
jamielennox | nisha_: yep | 19:27 |
*** edtubill has quit IRC | 19:27 | |
nisha_ | jamielennox, I am learning how to use the v3 client API. When I try to authenticate using session, I use this command auth = v3.Password(auth_url='http://localhost:5000/v3', username='admin', user_domain_name='Default', password='nomoresecret', project_name='admin', project_domain_name='Default') | 19:28 |
*** edtubill has joined #openstack-keystone | 19:28 | |
nisha_ | and this works fine | 19:28 |
ayoung | jamielennox, to check the keystoneauth kerb thing..what should I do? | 19:28 |
ayoung | https://review.openstack.org/#/c/321814/ | 19:29 |
patchbot | ayoung: patch 321814 - keystoneauth - Make the kerberos plugin loadable | 19:29 |
nisha_ | jamielennox, I don't understand why i have to create admin user again by using this command here? | 19:29 |
jamielennox | nisha_: that doesn't do anything yet, it will auth when it first gets used - but yea that looks right | 19:29 |
nisha_ | jamielennox, after that i used the command sess = session.Session(auth=auth) | 19:29 |
nisha_ | ks = client.Client(session=sess) | 19:29 |
nisha_ | ks.users.list() | 19:29 |
jamielennox | ayoung: so the kerberos that is being implemented is the one with the type=kerberos in the request body | 19:29 |
ayoung | jamielennox, can I use a venv and openstack cli? | 19:29 |
nisha_ | jamielennox, and it shows the list of users. | 19:30 |
jamielennox | ayoung: so it would be setup IPA, [auth] type=kerberos=external | 19:30 |
ayoung | OS_AUTH_TYPE=kerberos or summat? | 19:30 |
jamielennox | ayoung: then yea, openstack --os-auth-type kerberos ... user list or something | 19:30 |
nisha_ | Is it necessary to create atleast one admin user through auth initialization, or can I use any other name too in place of admin for initializing. | 19:31 |
ayoung | jamielennox, but rippowam woiuld not work, becuase only the Fed URL is kerberized? | 19:31 |
jamielennox | ayoung: we need to resurrect the federated kerberos one as well because that should be the recommended way to do this | 19:31 |
ayoung | jamielennox, but this plugin is not federated? | 19:32 |
samueldmq | nisha_: that's just passing the information to authenticate | 19:32 |
jamielennox | ayoung: yea, this was the original kerberos attempt where we had like a whole another url for kerberos | 19:32 |
ayoung | ok, I can replicate that. Will take a little longer | 19:32 |
samueldmq | nisha_: operations you run in that keystoneclient instance will use that auth credentials to authenticate against keystone server | 19:32 |
jamielennox | samueldmq: thanks | 19:32 |
nisha_ | samueldmq, thanks for clearing it up | 19:33 |
jamielennox | ayoung: we need to get the fedkerb one up and running again, but i don't want to change the plugin names between keystoneclient and keystoneauth | 19:33 |
ayoung | jamielennox, I think the febkerb one is broken anyway...least on Fedora | 19:34 |
jamielennox | ayoung: i was kind of not implementing the kerberos loader because i was hoping noone was using it | 19:34 |
jamielennox | ayoung: why? | 19:34 |
*** jbell8 has joined #openstack-keystone | 19:35 | |
*** gyee has quit IRC | 19:35 | |
openstackgerrit | henry-nash proposed openstack/keystone-specs: Relax the project name uniqueness constraints https://review.openstack.org/310048 | 19:36 |
*** jbell8 has quit IRC | 19:36 | |
openstackgerrit | henry-nash proposed openstack/keystone-specs: Support hierarchical project naming https://review.openstack.org/318605 | 19:37 |
ayoung | jamielennox, I think it go yanked from kc? | 19:38 |
nisha_ | samueldmq, I was going through this to create a new user, http://docs.openstack.org/developer/python-keystoneclient/api/keystoneclient.v3.html#keystoneclient.v3.users.UserManager.create | 19:38 |
ayoung | jamielennox, I tried it on a rippowam system and it worked when I was ssh in remotely, but not from my laptop | 19:38 |
jamielennox | ayoung: in ksc it was in ksc-kerberos repo, in ksa we have it in extras | 19:38 |
ayoung | laptop is using the Fedora packages | 19:38 |
*** daemontool has quit IRC | 19:38 | |
nisha_ | samueldmq, there is this warning, The project argument is deprecated as of the 1.7.0 release in favor of default_project and may be removed in the 2.0.0 release. | 19:38 |
jamielennox | (i've no idea how fed will package extras) | 19:38 |
nisha_ | should I still use that command? | 19:39 |
openstackgerrit | henry-nash proposed openstack/keystone-specs: Support hierarchical project naming https://review.openstack.org/318605 | 19:39 |
openstackgerrit | henry-nash proposed openstack/keystone-specs: Relax the project name uniqueness constraints https://review.openstack.org/310048 | 19:39 |
ayoung | jamielennox, might just been that I didn't have it installed | 19:39 |
*** wasmum has joined #openstack-keystone | 19:40 | |
ayoung | anyway, I'll test that one later. Need to duplicate the Keystone setup...and I have to test ECP against it first before I break it again | 19:40 |
openstackgerrit | Lance Bragstad proposed openstack/keystone-specs: Add spec for fernet key store backends https://review.openstack.org/311268 | 19:41 |
henrynash | rodigods, samueldmq, ayoung: when you have a moment, take a look at the two alterantives for project name unqiuessness (https://review.openstack.org/310048 and https://review.openstack.org/318605). Now that we have microversions, I wonder whether just changing the uniqueness constaints is cleaner rather than return the full path | 19:41 |
jamielennox | ayoung: if you end up having to do this seperate to rippowam let me know - i'd be interested in having public ansible that could do all this for people | 19:42 |
*** mvk has joined #openstack-keystone | 19:42 | |
henrynash | rodigods, samueldmq, ayoung: I also worry about permissions if we make the name teh full path in the project entity…what happens if I don’t have a role on one of the parents…should I be able to see teh full path? | 19:42 |
samueldmq | nisha_: the warning in the docs (in the link you just sent) say you should use default_project instead | 19:42 |
samueldmq | nisha_: the argument default_project instead of project, the call is the same | 19:42 |
ayoung | henrynash, go by the Unix conventions. | 19:43 |
nisha_ | samueldmq, alright! | 19:43 |
ayoung | pwd works regardless of perms on the parent | 19:43 |
jamielennox | nisha_: ideally you shouldn't need to add a defualt_project to a user at all | 19:43 |
samueldmq | henrynash: sure, I will take a look | 19:43 |
samueldmq | jamielennox: ++ | 19:43 |
jamielennox | nisha_: a user is a member of a project if they have a role on that project - default_project is an older concept we haven't used as much recently | 19:43 |
jamielennox | nisha_: so if you create a user, then assign a role to that user on a project it should have the same practical effect | 19:44 |
nisha_ | jamielennox, thanks a lot, got it! | 19:44 |
*** sdake has joined #openstack-keystone | 19:45 | |
*** jbell8 has joined #openstack-keystone | 19:45 | |
*** adu has quit IRC | 19:46 | |
henrynash | ayoung: if we went by unix, then I shouldn’t be able to get a scoped token to a project which had a parent on which I had no roles | 19:46 |
henrynash | ayoung: since I can’t cd into a dir that has a parent in which I have no permisions | 19:46 |
ayoung | henrynash, difference between inode and dentry | 19:46 |
ayoung | only ls is forbidden | 19:47 |
*** itisha has joined #openstack-keystone | 19:47 | |
henrynash | ayoung: cd doesn’t work either | 19:47 |
*** gagehugo has quit IRC | 19:47 | |
henrynash | (henery never claiming to be a unix expert) | 19:47 |
ayoung | if you have perm on the dentry itself, you can open it, by full path, without doing an ls on the parent | 19:48 |
openstackgerrit | Corey Bryant proposed openstack/python-keystoneclient: import warnings in doc/source/conf.py https://review.openstack.org/323553 | 19:48 |
henrynash | ayoung: ah, think I get your gist | 19:48 |
*** sdake_ has joined #openstack-keystone | 19:49 | |
henrynash | ayoung: you sure? can’t make it work….should it work if Nobody has anyrights to a parent (I chmod a-rwx one of the parents) | 19:49 |
*** jbell8 has quit IRC | 19:50 | |
*** sdake has quit IRC | 19:51 | |
*** ayoung has quit IRC | 19:54 | |
henrynash | notmorgan: now that we have microversions, could you remove your -2 from https://review.openstack.org/#/c/310048/ - not asking you to necessarily support it, just no longer block it | 19:55 |
patchbot | henrynash: patch 310048 - keystone-specs - Relax the project name uniqueness constraints | 19:55 |
*** ayoung has joined #openstack-keystone | 19:55 | |
*** ChanServ sets mode: +v ayoung | 19:55 | |
notmorgan | henrynash: sure. | 19:56 |
henrynash | notmorgan: thx | 19:56 |
notmorgan | done, to a -1 instead. | 19:57 |
notmorgan | just because it needs some reworking to cover the microversion stuff. | 19:57 |
notmorgan | but not too much to have to deal with | 19:57 |
*** jbell8 has joined #openstack-keystone | 20:02 | |
*** diazjf has quit IRC | 20:04 | |
*** dmk0202 has joined #openstack-keystone | 20:05 | |
*** roxanaghe has joined #openstack-keystone | 20:05 | |
*** jbell8 has quit IRC | 20:08 | |
*** diazjf has joined #openstack-keystone | 20:09 | |
ayoung | henrynash, ok...let me confirm... | 20:10 |
ayoung | henrynash, hmm...you are right. let's see waht strace shows | 20:13 |
ayoung | open("/tmp/testay/1/2/3/hello", O_RDONLY) = -1 EACCES (Permission denied) | 20:14 |
*** daemontool has joined #openstack-keystone | 20:15 | |
ayoung | so it is not walking the tree in userland. Must fail in doing that inside the Kernel. | 20:15 |
nisha_ | jamielennox, I created a new user | 20:16 |
*** diazjf has quit IRC | 20:16 | |
*** nkinder has joined #openstack-keystone | 20:16 | |
ayoung | henrynash, which makes sense. What would not change is if you had a file open before hand, and then changed the perms on the parent, the open file would still be valid. But walking the tree fails due to, I think, the missing -x option | 20:17 |
*** dan_nguyen has quit IRC | 20:17 | |
nisha_ | jamielennox, I want to use the command, add_to_group , samueldmq suggested that I create new users for learning the commands instead of messing up with admin and default users. Should I create a new group too? Instead of messing up with existing data? | 20:18 |
*** gagehugo has joined #openstack-keystone | 20:23 | |
*** code-R_ has quit IRC | 20:23 | |
KevinE | agrebennikov: ping :) | 20:23 |
*** clenimar has quit IRC | 20:24 | |
*** rderose has joined #openstack-keystone | 20:25 | |
*** dan_nguyen has joined #openstack-keystone | 20:26 | |
*** ayoung has quit IRC | 20:27 | |
*** dmk0202 has quit IRC | 20:28 | |
*** diazjf has joined #openstack-keystone | 20:28 | |
*** diazjf has quit IRC | 20:29 | |
*** daemontool_ has joined #openstack-keystone | 20:31 | |
*** diazjf has joined #openstack-keystone | 20:32 | |
*** clenimar has joined #openstack-keystone | 20:32 | |
*** daemontool has quit IRC | 20:33 | |
*** julim has quit IRC | 20:38 | |
*** nisha__ has joined #openstack-keystone | 20:39 | |
*** nisha_ has quit IRC | 20:39 | |
*** nisha__ is now known as nisha_ | 20:44 | |
*** dmk0202 has joined #openstack-keystone | 20:44 | |
*** raildo is now known as raildo-afk | 20:47 | |
*** timcline_ has joined #openstack-keystone | 20:48 | |
*** gyee has joined #openstack-keystone | 20:48 | |
*** ChanServ sets mode: +v gyee | 20:48 | |
*** timcline has quit IRC | 20:50 | |
*** georgem1 has quit IRC | 20:57 | |
*** diazjf has quit IRC | 20:59 | |
*** daemontool_ has quit IRC | 21:02 | |
samueldmq | nisha_: yes create a new group too if you want | 21:03 |
samueldmq | nisha_: you can do whatever you want in devstack, if you mess things up, just ./unstack ./stack :) | 21:04 |
*** diazjf has joined #openstack-keystone | 21:04 | |
*** dan_nguyen has quit IRC | 21:08 | |
*** jbell8 has joined #openstack-keystone | 21:09 | |
*** pauloewerton has quit IRC | 21:10 | |
*** jbell8 has quit IRC | 21:11 | |
*** timcline_ has quit IRC | 21:14 | |
*** dan_nguyen has joined #openstack-keystone | 21:14 | |
*** timcline has joined #openstack-keystone | 21:15 | |
nisha_ | samueldmq, alright, will create a new group :) | 21:17 |
*** jbell8 has joined #openstack-keystone | 21:18 | |
*** ayoung has joined #openstack-keystone | 21:23 | |
*** ChanServ sets mode: +v ayoung | 21:23 | |
*** clenimar has quit IRC | 21:24 | |
*** gagehugo has quit IRC | 21:25 | |
*** edmondsw has quit IRC | 21:29 | |
openstackgerrit | Ron De Rose proposed openstack/keystone: WIP - Refactor shadow users and deprecate driver backend https://review.openstack.org/323596 | 21:35 |
*** dan_nguyen has quit IRC | 21:37 | |
nisha_ | samueldmq, I successfully ran some commands, http://paste.openstack.org/show/506657/ | 21:38 |
*** dmk0202 has quit IRC | 21:38 | |
openstackgerrit | Ron De Rose proposed openstack/keystone: Refactor shadow users and deprecate driver backend https://review.openstack.org/323596 | 21:42 |
jlk | So I have a question. | 21:42 |
jlk | or really an observation | 21:42 |
nisha_ | jamielennox, samueldmq thanks for help :) | 21:42 |
openstackgerrit | Ron De Rose proposed openstack/keystone: Refactor shadow users and deprecate driver backend https://review.openstack.org/323596 | 21:42 |
*** nisha_ has quit IRC | 21:43 | |
jlk | I'm seeing a pretty different behavior out of keystone depending on whether or not "domain_specific_drivers_enabled = True" is set | 21:44 |
jlk | like, whether or not keystone will hand back all users across domains or just a single domain | 21:44 |
jlk | is that expected? | 21:46 |
stevemar | jlk: are there actually additional backends or did you just flip the switch in the config file? | 21:48 |
jlk | just flipped the switch | 21:48 |
jlk | We've already had multiple domains, but only one backend | 21:49 |
jlk | and things like `openstack user list` went from returning all users across all domains (as admin) to just returning those that exist in the domain the admin exists in (or were asked for with --domain) | 21:49 |
jlk | seems like an odd thing to base behavior on. | 21:50 |
*** dan_nguyen has joined #openstack-keystone | 21:51 | |
jlk | ah | 21:52 |
jlk | This task: https://github.com/openstack/keystone/blob/stable/mitaka/keystone/identity/controllers.py#L225-L230 | 21:53 |
jlk | hits this function https://github.com/openstack/keystone/blob/stable/mitaka/keystone/common/controller.py#L713-L736 | 21:53 |
stevemar | jlk: ahhh | 21:55 |
jlk | this explains why our automation worked, and why other tools worked before | 21:55 |
jlk | but break down when we start down the path of multiple backends. | 21:55 |
*** edtubill has quit IRC | 21:56 | |
stevemar | jlk: i guess if that switch is flipped then it's assumed you have >1 domain and can't safely assume you want the default domain | 21:56 |
*** diazjf has quit IRC | 21:57 | |
jlk | yeah, that I don't get, because it's not a good indicator. | 21:57 |
jlk | if you have HEat, you've got more than one domain | 21:57 |
stevemar | yeah, there should be a smarter way to evaluate that | 21:57 |
jlk | well before you go down the road of multiple backends | 21:57 |
stevemar | jlk: want to file a bug? | 21:57 |
jlk | maybe it's the thought of "more than one backend makes listing every user expensive, don't do that" | 21:57 |
openstackgerrit | Ron De Rose proposed openstack/keystone: WIP - Shadow LDAP and custom driver users https://review.openstack.org/323602 | 21:57 |
jlk | stevemar: I think the outcome of any such investigation will lead to just "always require specific domain" regardless of config. | 21:58 |
jlk | which is going to probably break a lot of things. | 21:58 |
bknudson | even if you only have 1 domain listing all users can be expensive. | 21:59 |
jlk | true | 22:00 |
bknudson | why would anyone need to list all users anyways? | 22:00 |
jlk | but would it be acceptable to always list all the users, unless the API caller provided a filter? | 22:00 |
bknudson | keystone also has result limiting so if you attempt to list all users you might not get them all back anyways | 22:01 |
jlk | isn't that handled by pagination? | 22:01 |
jlk | or do you just get a middlefinger? | 22:01 |
bknudson | we don't have pagination in keystone as far as I know | 22:01 |
bknudson | who's going to flip through 10,000 pages? | 22:02 |
jlk | Horizon.... :D | 22:02 |
jlk | so, I guess I just don't know what the intent here was | 22:02 |
jlk | teh API doc is unclear, the behavior is unclear | 22:03 |
jlk | IMHO Keystone should always return all users unless told to limit, or it should never return all users and only return those of the domain provided (or the domain from user's context). | 22:03 |
jlk | it shouldn't change from one to the other due to a tangentially related config entry. | 22:04 |
*** tonytan4ever has quit IRC | 22:05 | |
openstackgerrit | Ron De Rose proposed openstack/keystone: WIP - Shadow LDAP and custom driver users https://review.openstack.org/323602 | 22:06 |
*** darosale has quit IRC | 22:06 | |
jlk | bknudson: it also seems to come into play when doing some cli tasks, and passing around domain and user names instead of IDs | 22:07 |
bknudson | jlk: you may be finding that the user IDs are mapped when you have domain-specific backends? | 22:08 |
openstackgerrit | Ron De Rose proposed openstack/keystone: Shadow LDAP and custom driver users https://review.openstack.org/323602 | 22:08 |
bknudson | as in, an ID that worked without this setting now doesn't work with this setting because the IDs were mapped and so are different. | 22:08 |
jlk | bknudson: no, what I'm seeing is that doing things by name works until we flip that config bit, and then suddenly names are no longer found. | 22:09 |
jlk | it's client code likely trying to translate a name into an ID, doing a listing, failing to find, giving up. | 22:09 |
bknudson | jlk: from the CLI? CLI might be trying to list all the users and finding the entry for the user | 22:09 |
jlk | right, from the CLI | 22:10 |
jlk | the API only takes in IDs IIRC, never names | 22:10 |
openstackgerrit | Merged openstack/python-keystoneclient: import warnings in doc/source/conf.py https://review.openstack.org/323553 | 22:10 |
openstackgerrit | Ron De Rose proposed openstack/keystone: Refactor shadow users and deprecate driver backend https://review.openstack.org/323596 | 22:10 |
*** sdake has joined #openstack-keystone | 22:10 | |
notmorgan | stevemar: there is already a bug for that fyi | 22:11 |
notmorgan | cc jlk | 22:11 |
*** sdake_ has quit IRC | 22:12 | |
notmorgan | dunno the id | 22:12 |
*** jbell8 has quit IRC | 22:13 | |
*** tonytan4ever has joined #openstack-keystone | 22:14 | |
*** ametts has quit IRC | 22:14 | |
openstackgerrit | Ron De Rose proposed openstack/keystone: Refactor shadow users and deprecate driver backend https://review.openstack.org/323596 | 22:15 |
openstackgerrit | Ron De Rose proposed openstack/keystone: Shadow LDAP and custom driver users https://review.openstack.org/323602 | 22:15 |
jlk | https://bugs.launchpad.net/keystone/+bug/1555629 | 22:21 |
openstack | Launchpad bug 1555629 in OpenStack Identity (keystone) "v3/users reports all users in all domains excepts when domain_specific_drivers_enabled is set to true." [Undecided,New] | 22:21 |
*** clenimar has joined #openstack-keystone | 22:22 | |
*** henrynash has quit IRC | 22:22 | |
openstackgerrit | Andrew Laski proposed openstack/oslo.policy: Add equality operator to policy.RuleDefault https://review.openstack.org/321242 | 22:22 |
openstackgerrit | Andrew Laski proposed openstack/oslo.policy: Add helper scripts for generating policy info https://review.openstack.org/321243 | 22:22 |
openstackgerrit | Andrew Laski proposed openstack/oslo.policy: Add sample file generation script and helper methods https://review.openstack.org/314244 | 22:22 |
*** timcline has quit IRC | 22:22 | |
*** timcline has joined #openstack-keystone | 22:23 | |
jlk | notmorgan: stevemar: so it appears that this quirk is documented in keystone's in-tree configuration docs, but it isn't referenced at http://docs.openstack.org/mitaka/config-reference/identity/options.html#domain-specific-configuration | 22:23 |
*** code-R has joined #openstack-keystone | 22:24 | |
jlk | where are teh in-tree keystone docs published? | 22:24 |
jlk | ah http://docs.openstack.org/developer/keystone/configuration.html | 22:25 |
*** doug-fish has joined #openstack-keystone | 22:27 | |
*** timcline has quit IRC | 22:27 | |
*** code-R has quit IRC | 22:29 | |
*** doug-fis_ has quit IRC | 22:30 | |
jlk | still seems like an odd decision. How is an end user supposed to know how keystone is configured? What can they possibly do to know that they should pass the domain along? | 22:34 |
*** dan_nguyen has quit IRC | 22:41 | |
*** KevinE has quit IRC | 22:42 | |
*** wasmum has quit IRC | 22:46 | |
*** doug-fish has quit IRC | 22:49 | |
*** pumarani__ has quit IRC | 22:53 | |
*** roxanaghe has quit IRC | 22:53 | |
*** pushkaru has joined #openstack-keystone | 22:54 | |
*** pumarani__ has joined #openstack-keystone | 22:56 | |
*** pushkaru has quit IRC | 22:56 | |
*** julim has joined #openstack-keystone | 22:56 | |
*** henrynash has joined #openstack-keystone | 22:58 | |
*** ChanServ sets mode: +v henrynash | 22:58 | |
*** shaleh|away has quit IRC | 22:58 | |
*** julim has quit IRC | 22:59 | |
*** dan_nguyen has joined #openstack-keystone | 23:02 | |
*** darrenc is now known as darrenc_afk | 23:03 | |
*** pumarani__ has quit IRC | 23:05 | |
*** doug-fish has joined #openstack-keystone | 23:06 | |
*** doug-fish has quit IRC | 23:11 | |
jlk | Is the _member_ role a default role that exists, or do I have to explicitly create it? | 23:12 |
*** gordc has quit IRC | 23:22 | |
*** darrenc_afk is now known as darrenc | 23:23 | |
*** clenimar has quit IRC | 23:27 | |
openstackgerrit | henry-nash proposed openstack/keystone-specs: Relax the project name uniqueness constraints https://review.openstack.org/310048 | 23:35 |
*** furface has quit IRC | 23:43 | |
openstackgerrit | henry-nash proposed openstack/keystone-specs: Support hierarchical project naming https://review.openstack.org/318605 | 23:45 |
*** chlong has quit IRC | 23:53 |
Generated by irclog2html.py 2.14.0 by Marius Gedminas - find it at mg.pov.lt!