Tuesday, 2016-05-31

*** code-R has quit IRC00:01
*** knikolla has quit IRC00:06
*** knikolla has joined #openstack-keystone00:09
openstackgerritSamuel de Medeiros Queiroz proposed openstack/keystonemiddleware: Make sure audit can handle API requests which does not require a token  https://review.openstack.org/32072500:16
*** jamielennox|away is now known as jamielennox00:20
*** darosale has joined #openstack-keystone00:34
openstackgerritSamuel de Medeiros Queiroz proposed openstack/keystone: Invalidate token cache after token delete  https://review.openstack.org/31699100:43
*** rdo has quit IRC00:43
*** rdo has joined #openstack-keystone00:46
*** dan_nguyen has joined #openstack-keystone00:47
*** lhcheng has joined #openstack-keystone00:53
*** ChanServ sets mode: +v lhcheng00:53
*** lhcheng has quit IRC00:57
*** georgem1 has joined #openstack-keystone01:21
*** EinstCrazy has joined #openstack-keystone01:25
*** iurygregory_ has quit IRC01:28
*** flwang2 has joined #openstack-keystone01:43
*** julim has quit IRC01:44
*** flwang has quit IRC01:44
*** markvoelker has joined #openstack-keystone01:51
*** markvoelker has quit IRC01:55
*** code-R has joined #openstack-keystone01:57
*** julim has joined #openstack-keystone02:00
*** code-R has quit IRC02:02
*** julim has quit IRC02:04
*** tangchen has joined #openstack-keystone02:31
*** sdake_ has joined #openstack-keystone02:46
*** sheel has joined #openstack-keystone02:47
*** sdake has quit IRC02:50
*** eszxy has joined #openstack-keystone02:52
*** diazjf has joined #openstack-keystone02:52
*** diazjf has quit IRC02:52
*** EinstCrazy has quit IRC03:00
*** edmondsw has joined #openstack-keystone03:02
openstackgerritOpenStack Proposal Bot proposed openstack/python-keystoneclient: Updated from global requirements  https://review.openstack.org/32308403:06
*** sdake_ has quit IRC03:07
*** dan_nguyen has quit IRC03:30
*** EinstCrazy has joined #openstack-keystone03:30
*** darosale has quit IRC03:33
openstackgerritChangBo Guo(gcb) proposed openstack/keystonemiddleware: Use method split_path from oslo.utils  https://review.openstack.org/32310103:34
*** georgem1 has quit IRC03:45
*** rcernin has joined #openstack-keystone03:49
*** links has joined #openstack-keystone03:50
*** markvoelker has joined #openstack-keystone03:52
*** neophy has joined #openstack-keystone03:54
*** markvoelker has quit IRC03:56
*** code-R has joined #openstack-keystone03:58
*** code-R has quit IRC04:03
*** pgbridge has joined #openstack-keystone04:12
*** itisha has quit IRC04:20
*** jaosorior has joined #openstack-keystone04:39
stevemarjamielennox: notmorgan i opened https://bugs.launchpad.net/keystone/+bug/158723904:48
openstackLaunchpad bug 1587239 in OpenStack Identity (keystone) "cover job is failing too frequently" [High,New]04:48
notmorganstevemar: joy04:52
notmorganideas on cause?04:52
*** gcb has joined #openstack-keystone04:52
*** rcernin has quit IRC04:52
*** chlong has quit IRC04:54
*** flwang2 has quit IRC05:02
stevemarnotmorgan: probably cause the tox target doesn't follow upper-constraints05:03
*** pgbridge has quit IRC05:04
notmorganoh shoukd fix that05:05
openstackgerritMerged openstack/keystoneauth: Updated from global requirements  https://review.openstack.org/32306805:12
*** chlong has joined #openstack-keystone05:12
openstackgerritMerged openstack/oslo.policy: Updated from global requirements  https://review.openstack.org/32308005:14
openstackgerritMerged openstack/keystonemiddleware: Updated from global requirements  https://review.openstack.org/32306905:17
*** jamielennox is now known as jamielennox|away05:24
openstackgerritMerged openstack/python-keystoneclient: Updated from global requirements  https://review.openstack.org/32308405:27
*** jamielennox|away is now known as jamielennox05:28
*** d34dh0r53 has quit IRC05:33
*** d34dh0r53 has joined #openstack-keystone05:36
jamielennoxnotmorgan: here?05:45
*** neophy has quit IRC05:46
*** GB21 has joined #openstack-keystone05:50
*** markvoelker has joined #openstack-keystone05:52
*** markvoelker has quit IRC05:57
*** code-R has joined #openstack-keystone05:59
*** code-R has quit IRC06:04
*** jamielennox is now known as jamielennox|away06:15
notmorganjamielennox|away: ?06:22
notmorganits 2322 here  whats up?06:22
*** GB21 has quit IRC06:34
*** belmoreira has joined #openstack-keystone06:46
*** neophy has joined #openstack-keystone06:53
*** GB21 has joined #openstack-keystone06:54
*** tesseract has joined #openstack-keystone06:57
*** rcernin has joined #openstack-keystone07:02
*** neophy has quit IRC07:04
*** yolanda has quit IRC07:05
*** yolanda has joined #openstack-keystone07:05
*** dimonv has joined #openstack-keystone07:05
*** jamielennox|away is now known as jamielennox07:18
jamielennoxnotmorgan: yea - but that doesn't mean you're not here07:19
jamielennoxnotmorgan: i wanted to ask about https://github.com/openstack-dev/devstack/blob/master/lib/keystone#L251-L25207:19
jamielennoxthe bug mentioned is marked as fixed, but it's a bit past my oslo.cache knowledge07:20
jamielennoxis it safe to remove from devstack?07:20
*** code-R has joined #openstack-keystone07:22
*** code-R_ has joined #openstack-keystone07:25
*** code-R has quit IRC07:28
*** sdake has joined #openstack-keystone07:34
alogajamielennox: around? probably you have a hint regarding https://bugs.launchpad.net/nova/+bug/155504507:50
openstackLaunchpad 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-keystone07:53
*** yolanda has quit IRC07:54
*** yolanda has joined #openstack-keystone07:55
*** yolanda has quit IRC07:56
*** yolanda_ has joined #openstack-keystone07:56
*** markvoelker has quit IRC07:58
*** zzzeek has quit IRC08:00
*** TxGVNN has joined #openstack-keystone08:00
*** zzzeek has joined #openstack-keystone08:01
openstackgerritDavanum Srinivas (dims) proposed openstack/keystone: [WIP] Testing latest u-c  https://review.openstack.org/31843508:10
*** jaosorior has quit IRC08:11
*** jaosorior has joined #openstack-keystone08:12
*** woodster_ has quit IRC08:18
*** mkrcmari__ has quit IRC08:22
*** dmk0202 has joined #openstack-keystone08:26
*** tangchen has quit IRC08:26
*** sdake_ has joined #openstack-keystone08:32
*** sdake has quit IRC08:35
*** jaosorior is now known as jaosorior_lunch08:39
*** TxGVNN has quit IRC08:39
*** code-R_ has quit IRC08:42
*** code-R has joined #openstack-keystone08:49
*** henrynash has joined #openstack-keystone08:51
*** ChanServ sets mode: +v henrynash08:51
*** mkrcmari__ has joined #openstack-keystone08:54
openstackgerritRudolf Vriend proposed openstack/keystone: Allow domain admins to list users in groups with v3 policy  https://review.openstack.org/32112808:56
*** flwang has joined #openstack-keystone08:57
*** nisha has joined #openstack-keystone08:58
*** nisha has quit IRC08:58
*** permalac has quit IRC09:16
*** daemontool has joined #openstack-keystone09:22
*** jbell8 has joined #openstack-keystone09:23
*** chlong has quit IRC09:29
*** srushti has quit IRC09:29
*** nisha has joined #openstack-keystone09:34
jamielennoxaloga: 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 service09:41
jamielennoxaloga: you either need to turn off the ?no_catalog flag to whatever is validating tokens, or have some other way of passing an endpoint in09:41
alogajamielennox: I don't get it09:41
alogajamielennox: this is something done by nova09:42
alogajamielennox: I am not doing anything :-)09:42
*** mkrcmari__ has quit IRC09:43
*** flwang has quit IRC09:43
alogajamielennox: if I am not wrong, the catalog is coming from this class https://github.com/openstack/nova/blob/master/nova/context.py#L3909:44
jamielennoxaloga: have you got include_service_catalog = False in your nova keystone_authtoken config?09:44
alogajamielennox: no09:44
jamielennoxaloga: what service is it trying to contact?09:44
alogajamielennox: cinder09:45
alogabut this is a delayed task09:45
alogajamielennox: so it is usin an admin context09:45
alogathis is the volume cleanup task09:45
alogaif the cleanup is done as a delayed task it fails09:46
*** chlong has joined #openstack-keystone09:47
alogaif the cleanup is done straight away (i.e. no reclaim interval) it works09:47
*** mvk has joined #openstack-keystone09:47
alogaso my guess is that, since the delayed task is using an admin context, it does not contain the service catalog09:47
jamielennoxaloga: yea, that makes sense09:48
jamielennoxget_admin_context doesn't have any catalog: https://github.com/openstack/nova/blob/master/nova/context.py#L22509:49
jamielennoxso how is nova supposed to know how to talk to cinder ?09:49
alogaindeed09:49
jamielennoxwhat token is it using?09:50
jamielennoxthe nova service user?09:50
*** agireud has quit IRC09:50
alogajamielennox: you mean in the delayed task?09:52
alogajamielennox: I think that the nova service user should be used09:52
jamielennoxright, something has to make the request09:52
alogajamielennox: but this then requires that the nova service user has permissions in cinder as well09:52
jamielennoxthere's something in neutron that requires admin so i think the nova user is already pretty powerful09:53
jamielennoxbut there's a scoping issue - the nova user won't be in the project that it wants to delete resource for09:53
jamielennoxaloga: is this a new feature?09:53
jamielennoxhas it worked in the past?09:53
alogajamielennox: no, it does not work in the past09:53
alogajamielennox: this has been an issue in our cloud for a while09:54
aloga(we're in Liberty right now and we see the error)09:54
*** markvoelker has joined #openstack-keystone09:54
alogas/does/did/09:55
*** sdake_ is now known as sdake09:57
*** markvoelker has quit IRC09:58
alogayou 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 works09:58
nishaHey all :)10:01
nishaI 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.html10:02
nishaI 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
jamielennoxaloga: but that's just your cloud right? it is a feature that has worked10:05
jamielennoxoh, so most people override the cinder endpoint?10:05
jamielennoxnisha: what sort of connectionerror?10:05
henrynashmorning10:05
nishattp://paste.openstack.org/show/506535/10:05
jamielennoxwhat's the message10:05
*** jaosorior_lunch is now known as jaosorior10:06
nishahi jamielennox the above http://paste.openstack.org/show/506535/10:06
nisharaise exceptions.ConnectFailure(msg)10:07
nishakeystoneauth1.exceptions.connection.ConnectFailure: Unable to establish connection to https://my.keystone.com:5000/v3/auth/tokens10:07
jamielennoxnisha: hmm, unfortunately that doesn't help much - it's fairly generic10:07
jamielennoxdoes like wget  https://my.keystone.com:5000/v3/ return anything?10:07
nishajamielennox,  I have been trying since yesterday, i can't open the link  https://my.keystone.com:5000/v3/  in my browser10:09
jamielennoxnisha: so it sounds like an actual connection error, as in you can't connect to the server10:09
jamielennoxif you can't connect in a browser then maybe the server isn't exposed, maybe firewall issues,10:10
jamielennoxthere's a lot of things there that could be a thing10:10
*** agireud has joined #openstack-keystone10:11
*** pcaruana has joined #openstack-keystone10:11
nishajamielennox, 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
alogajamielennox: I don't know for other clouds, but if you see the bug report this is something that happens to others10:12
alogajamielennox: and it is reproducible with devstack, if you configure an instance reclaim interval10:12
alogajamielennox: so I guess this is something generalized10:12
jamielennoxnisha: 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 all10:12
alogajamielennox: either people override the endpoint, or they do not have set a reclaim interval10:13
jamielennoxaloga: yep, ok - can you point me to where the code for this is? where it's getting its auth from?10:13
jamielennoxnisha: 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 up10:14
alogajamielennox: sure, https://github.com/openstack/nova/blob/master/nova/compute/manager.py#L217510:14
*** chlong has quit IRC10:15
nishajamielennox, thanks for help10:17
jamielennoxnisha: no worries, sorry i couldn't be more useful10:17
jamielennoxaloga: do you know what calls that?10:17
jamielennoxaloga: or like a traceback to that point? i want to know where the context is created i think10:18
alogajamielennox: 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 IRC10:18
alogathat is being execued as a periodic task (https://github.com/openstack/nova/blob/master/nova/service.py#L251)10:19
alogaso, the original context is obtained in https://github.com/openstack/nova/blob/master/nova/service.py#L25110:20
*** jbell8 has joined #openstack-keystone10:20
*** henrynash_ has joined #openstack-keystone10:21
*** zerda2 has joined #openstack-keystone10:22
*** nisha_ has joined #openstack-keystone10:22
*** henrynash has quit IRC10:22
*** henrynash has joined #openstack-keystone10:23
*** ChanServ sets mode: +v henrynash10:23
zerda2Hello. 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 time10:24
*** nisha has quit IRC10:26
*** yolanda has joined #openstack-keystone10:27
*** nisha_ is now known as nisha10:27
*** yolanda_ has quit IRC10:27
*** chlong has joined #openstack-keystone10:27
jamielennoxaloga: so i'm fairly confused how this works10:31
jamielennoxaloga: so here is where the context ends up https://github.com/openstack/nova/blob/master/nova/volume/cinder.py#L7810:31
jamielennoxso from the highlight i can see the difference as to why it works when you set endpoint_template, it sets endpoint_override and works10:32
alogajamielennox: yes10:32
*** EinstCrazy has quit IRC10:32
jamielennoxaloga: 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
jamielennoxhttps://github.com/openstack/nova/blob/master/nova/context.py#L225 doesn't handle it at all10:33
alogajamielennox: I am not following you10:34
aloga:-?10:34
alogathe problem is here: https://github.com/openstack/nova/blob/master/nova/volume/cinder.py#L7010:34
alogaauth = context.get_auth_plugin()10:34
alogathen in line https://github.com/openstack/nova/blob/master/nova/volume/cinder.py#L8210:35
alogait tries to get the endpoint, and it fails, as there is no catalog10:35
*** code-R has quit IRC10:35
alogaif you go through the other branch of the if https://github.com/openstack/nova/blob/master/nova/volume/cinder.py#L7810:35
alogabecause you have a template set, it will work10:36
jamielennoxaloga: yep, but that seems to get started from here: https://github.com/openstack/nova/blob/master/nova/service.py#L251-L25410:36
alogayes10:36
jamielennoxok, so assume from that you have endpoint_template set - where is auth_token coming from?10:36
*** jbell8 has quit IRC10:36
*** henrynash has quit IRC10:37
alogajamielennox: ahhh, sorry10:37
jamielennoxi mean you ahve to call cinder with some sort of token10:37
alogajamielennox: I misunderstood you10:37
alogajamielennox: yes, you are right10:37
alogajamielennox: we never set the endpoint template, so to be honest I do not know if this worked before10:38
alogajamielennox: I can test it quickly though10:38
jamielennoxaloga: if you could because it must work for people10:39
jamielennoxand we'd get the service catalog from the same place we get the token from10:39
jamielennox(wherever that is)10:39
*** agireud has quit IRC10:39
jamielennoxaloga: are we sure the request is being made from nova api rather than nova scheduler?10:42
alogajamielennox: yes, the scheduler is not involved here10:46
openstackgerritChangBo Guo(gcb) proposed openstack/keystonemiddleware: Use method split_path from oslo.utils  https://review.openstack.org/32310110:47
*** nisha_ has joined #openstack-keystone10:47
*** permalac has joined #openstack-keystone10:48
*** code-R has joined #openstack-keystone10:49
*** nisha has quit IRC10:50
*** mou has joined #openstack-keystone10:51
alogajamielennox: it works10:54
alogaah, no, sorry10:54
alogajamielennox: you were right, it fails:  Ignoring unknown exception for volume 4a8940a5-1d42-4f34-86e1-d949630d94fd: No valid authentication is available11:00
jamielennoxaloga: in that case i have absolutely no idea how it should work :)11:01
jamielennoxthat's my reading of the code. there is no token available for making requests11:01
jamielennoxso i'm not sure how it ever worked11:01
alogajamielennox: I would say: "I'm not sure if it ever worked" :)11:01
jamielennoxaloga: yep - i'd agree11:02
jamielennoxwhich i always find amazing11:02
alogajamielennox: well, it works if there is not a reclaim interval11:02
alogajamielennox: that is, if the attachment is cleaned straight away when the user does a delete11:03
jamielennoxaloga: 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_context11:03
jamielennoxif there's a plugin in there things should just work11:04
*** nisha_ is now known as nisha11:04
samueldmqnisha: morning11:04
alogajamielennox: so the operation will be done with a token issued for the service user, right?11:05
nishasamueldmq, hey, morning11:05
jamielennoxaloga: that would be the outcome yes11:05
jamielennoxaloga: i can only assume that's the intention11:05
alogajamielennox: great, many thanks11:05
alogajamielennox: I will check if I can handle this...11:06
jamielennoxaloga: no worries - hope it helped11:06
*** code-R has quit IRC11:06
*** dmk0202 has quit IRC11:07
*** raildo-afk is now known as raildo11:13
samueldmqjamielennox: hi11:24
samueldmqjamielennox: who usually release keystoneauth ? is it you or stevemar ?11:25
jamielennoxsamueldmq: normally stevemar but i can probably do it in case of emergency - what's up?11:33
samueldmqjamielennox: yolanda did some updates for keystoneauth fixture she needs to consume in shade11:34
samueldmqjamielennox: she's been asking for a release lately; are there any specific requirements to make a cut ?11:34
jamielennoxsamueldmq: not specific requirements no, normally either we really need something elsewhere, have urgent bug or it's just been a while11:35
jamielennoxthere's been a few things merged since last release11:36
jamielennoxsamueldmq: so i would like to get https://review.openstack.org/#/c/321814/ merged before a release11:36
patchbotjamielennox: patch 321814 - keystoneauth - Make the kerberos plugin loadable11:36
jamielennoxsamueldmq: which requires ayoung (or someone) to actually spin up a full kerberos environment and make sure it's all working11:37
jamielennoxbut that's the only open review at the moment close to merging that should be included11:37
samueldmqjamielennox: nice, so we work on merging that and we should be good to make a cut11:38
jamielennoxif you bug him about +A-ing that then we should be able to do a release11:38
samueldmqjamielennox: I assume setting up a full kerberos env requires a lot of work11:38
samueldmqjamielennox: specially for someone who have never done it11:38
jamielennoxstevemar will likely be lurking at the meeting tomorrow - but i'm guessing that would be ok with him11:39
jamielennoxsamueldmq: it's a bit specific if you're not used to working with kerberos11:39
jamielennoxmaybe even if you are11:39
*** agireud has joined #openstack-keystone11:39
yolandajamielennox, samueldmq, thx11:40
jamielennoxespecially that method is a bit older, from before federation so I can't remember all the details11:40
jamielennoxbut you're welcome/encouraged to try :)11:40
jamielennoxit's one i would love to have running as a functional test11:40
samueldmqyolanda: you're welcome; I will work with other cores to get that merged so we can make a cut11:40
jamielennoxbut realistically requires freeipa11:41
samueldmqjamielennox: k, I hope ayoung will be able to set that env up and test it11:41
samueldmqjamielennox: otherwise I will give it a try in order to make things move11:42
*** dmk0202 has joined #openstack-keystone11:42
jamielennoxsounds good, i'll be around for the meeting tomorrow so we can talk to him them11:43
jamielennoxthen11:43
*** dimonv has quit IRC11:45
*** dimonv has joined #openstack-keystone11:46
samueldmqjamielennox: nice, thanks11:47
*** woodster_ has joined #openstack-keystone11:52
*** jbell8 has joined #openstack-keystone11:54
*** markvoelker has joined #openstack-keystone11:55
*** rodrigods has quit IRC11:56
*** code-R has joined #openstack-keystone11:56
*** rodrigods has joined #openstack-keystone11:56
*** markvoelker has quit IRC11:57
*** markvoelker has joined #openstack-keystone11:57
*** henrynash has joined #openstack-keystone11:57
*** ChanServ sets mode: +v henrynash11:57
*** itisha has joined #openstack-keystone12:04
*** zerda2 has quit IRC12:05
openstackgerritChangBo Guo(gcb) proposed openstack/keystonemiddleware: Use method split_path from oslo.utils  https://review.openstack.org/32310112:07
*** code-R_ has joined #openstack-keystone12:14
*** code-R has quit IRC12:17
openstackgerritRudolf Vriend proposed openstack/keystone: Allow domain admins to list users in groups with v3 policy  https://review.openstack.org/32112812:17
*** GB21 has quit IRC12:24
*** dave-mccowan has joined #openstack-keystone12:25
*** sdake has quit IRC12:27
*** gordc has joined #openstack-keystone12:32
*** nisha has quit IRC12:34
*** nisha has joined #openstack-keystone12:48
*** julim has joined #openstack-keystone12:53
*** georgem1 has joined #openstack-keystone12:54
*** georgem1 has quit IRC13:04
*** georgem1 has joined #openstack-keystone13:04
*** pauloewerton has joined #openstack-keystone13:11
openstackgerritRodrigo Duarte proposed openstack/keystone: Fix credentials_factory method call  https://review.openstack.org/32336013:13
rodrigods^ if anyone could review/+A that13:17
rodrigodsit is currently breaking keystone's functional tests13:17
*** ayoung has joined #openstack-keystone13:22
*** ChanServ sets mode: +v ayoung13:22
*** shewless has joined #openstack-keystone13:28
shewlessHello. 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 website13:29
*** nisha_ has joined #openstack-keystone13:39
lbragstadhenrynash does role assignment inheritance span groups?13:39
*** nkinder has joined #openstack-keystone13:40
raildolbragstad: only if you grant the inherited role on the group13:41
lbragstadraildo so - should this work? https://bugs.launchpad.net/keystone/+bug/158314213:41
openstackLaunchpad bug 1583142 in OpenStack Identity (keystone) "Roles inheritance for groups is not visible in user's role assignments" [Undecided,New]13:41
henrynashlbragstad: how do you mean “span groups”?13:42
lbragstadhenrynash https://bugs.launchpad.net/keystone/+bug/158314213:42
openstackLaunchpad 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 IRC13:42
*** yolanda_ has joined #openstack-keystone13:43
lbragstadhenrynash i could be using "span" in the wrong context here13:43
henrynashlbragstad: let me read up on the bug….13:43
raildolbragstad: I think this bug is invalid, a group role shouldn't be listed in the role assignment for users13:43
*** yolanda has quit IRC13:44
lbragstadhenrynash raildo - thanks. I got a few pings about that bug over the weekend and I wanted to talk to the experts13:44
henrynashlbragstad, raildo: agreed, it is invalid13:44
lbragstadhenrynash do you want to update it with a comment?13:45
henrynashlbragdstad: will do13:45
lbragstadhenrynash raildo thanks guys!13:45
raildolbragstad: yw13:45
*** jbell8 has quit IRC13:49
shewlessHi 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.html13:51
henrynashlbragstad: done13:52
shewlessDo 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-keystone13:53
*** tonytan4ever has joined #openstack-keystone13:54
henrynashshewless: 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
henrynashshewless: so your roles and projects are in SQL I assume13:55
*** ametts has joined #openstack-keystone13:56
*** edtubill has joined #openstack-keystone13:56
*** richm has joined #openstack-keystone13: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
henrynashshewless: 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
henrynashshewless: no, not policy.json….13:59
henrynashshawless: is there a group that these uses are a member of13:59
henrynashshawless:?13:59
shewless+henrynash: from an active directory perspective.. no14:00
henrynashshewless: hmm, that’s a shame14: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
henrynashshewless: 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-keystone14:02
henrynashshewless: you could even assign an inherited role to the domain, so that they had a role on ALL projects if that’s what you wanted14:02
*** jaosorior has quit IRC14:03
rodrigodsdo we know the issue with keystone-coverage-db?14:03
*** eszxy has quit IRC14: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
rodrigodsraildo, did you investigate further yesterday ^ ?14:04
henrynashshewless: so there isn’t a way of auto creating such proejcts….I think you are starting to talk about an orchestrator type functionality14:05
henrynashshawless: I should be around here.14:05
*** rderose has joined #openstack-keystone14:08
raildorodrigods: no :(14:12
*** d0ugal has quit IRC14:15
*** d0ugal has joined #openstack-keystone14:16
*** phalmos has joined #openstack-keystone14:19
*** EinstCrazy has joined #openstack-keystone14:19
*** phalmos_ has joined #openstack-keystone14:22
*** pushkaru has joined #openstack-keystone14:23
*** phalmos has quit IRC14:26
*** darosale has joined #openstack-keystone14:28
*** nisha_ has quit IRC14:29
*** tonytan4ever has quit IRC14:30
openstackgerritRon De Rose proposed openstack/keystone: PCI-DSS Change password requirements  https://review.openstack.org/32015614:32
openstackgerritRon De Rose proposed openstack/keystone: Add password table columns to meet PCI-DSS change password requirements  https://review.openstack.org/31428414:38
openstackgerritRon De Rose proposed openstack/keystone: PCI-DSS Change password requirements  https://review.openstack.org/32015614:38
*** jaugustine has joined #openstack-keystone14:41
*** raddaoui has joined #openstack-keystone14:42
*** gagehugo has joined #openstack-keystone14:44
*** henrynash has quit IRC14:45
rodrigodsraildo, found it: https://review.openstack.org/#/c/321704/514:49
patchbotrodrigods: patch 321704 - oslo.messaging - Updated from global requirements14:49
raildorodrigods: \o/14:49
*** ayoung has quit IRC14:51
openstackgerritRon De Rose proposed openstack/keystone: WIP - PCI-DSS Password strength requirements  https://review.openstack.org/32058614:51
openstackgerritRon De Rose proposed openstack/keystone: WIP - PCI-DSS Password strength requirements  https://review.openstack.org/32058614:51
*** wasmum has quit IRC14:52
*** doug-fish has joined #openstack-keystone14:55
openstackgerritRon De Rose proposed openstack/keystone: WIP - PCI-DSS Password strength requirements  https://review.openstack.org/32058614:55
*** timcline has joined #openstack-keystone14:55
*** code-R_ has quit IRC14:59
openstackgerritRon De Rose proposed openstack/keystone: PCI-DSS Change password requirements  https://review.openstack.org/32015614: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
openstackgerritRon De Rose proposed openstack/keystone: WIP - PCI-DSS Password strength requirements  https://review.openstack.org/32058614:59
*** code-R has joined #openstack-keystone15:02
stevemarrodrigods: https://bugs.launchpad.net/keystone/+bug/1587239 and https://bugs.launchpad.net/nova/+bug/1586979 are a good start15:04
openstackLaunchpad bug 1587239 in OpenStack Identity (keystone) "cover job is failing too frequently" [High,New]15:04
openstackLaunchpad bug 1586979 in OpenStack Compute (nova) "AMQP 2.0 prevents services from starting" [Undecided,New]15:04
openstackgerritRon De Rose proposed openstack/keystone: Config settings to support PCI-DSS  https://review.openstack.org/31467915:06
openstackgerritRon De Rose proposed openstack/keystone: Add password table columns to meet PCI-DSS change password requirements  https://review.openstack.org/31428415:06
openstackgerritRon De Rose proposed openstack/keystone: PCI-DSS Change password requirements  https://review.openstack.org/32015615:06
openstackgerritRon De Rose proposed openstack/keystone: WIP - PCI-DSS Password strength requirements  https://review.openstack.org/32058615:06
*** rcernin has quit IRC15:07
shewlesshenrynash_: 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
openstackgerritAlexander Makarov proposed openstack/keystone: Add password table columns to meet PCI-DSS failed  https://review.openstack.org/32296115:08
*** daemontool_ has joined #openstack-keystone15:08
*** daemontool has quit IRC15:10
*** daemontool_ has quit IRC15:11
*** daemontool__ has joined #openstack-keystone15:11
shewlessI see there is this option in the ldap config section: #user_default_project_id_attribute15:12
shewlessI guess I could create a project in my ldap domain and then fill in this value as a start15:12
amakarovrderose, hi! Why have you extracted logic to Authenticator?15:13
*** links has quit IRC15:15
*** code-R has quit IRC15:16
*** TxGVNN has quit IRC15:16
rderoseamakarov: 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
amakarovrderose, is it a place I should put my changes to?15:17
amakarovI mead, related to auth attempts?15:17
amakarovs/mead/mean/15:17
rderoseamakarov: no, because would only be for sql driver15:17
rderoseamakarov: lock out is at a higher level15:18
amakarovrderose, I need to store the attempts history somewhere15:18
amakarovdo you have any suggestion?15:18
amakarovI thought Password table is a good place for that15:18
*** dtroyer has joined #openstack-keystone15:19
rderoseamakarov: hmm... Password table to keep track of auth attempts?15:19
amakarovrderose, failed attempts15:19
dolphmdstanek: have your saml work in review somewhere?15:20
rderoseamakarov: I don't that would belong in the Password table15:20
rderoseamakarov: seems like a new backend to me15:20
rderoseamakarov: * I don't think failed auth attempts belongs in the Password table15:21
amakarovrderose, why&15:21
amakarov?15:21
*** belmoreira has quit IRC15:22
*** amrith is now known as _amrith_15:22
*** _amrith_ is now known as amrith15:23
rderoseamakarov: 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
amakarovrderose, not a count - a log. timestamps15:25
amakarovrderose, so that it it can be tracked15:25
stevemardolphm: i just realized you were on superuser tv https://www.youtube.com/watch?v=s3JxnnuBBe415:25
stevemardolphm: so famous!15:25
rderoseamakarov: right, so I don't see how this fits with the password table, e.g. user has 2 passwords saved and have 5 failed attempts15:27
dolphmstevemar: there's no way i'm watching that15:27
rderoseamakarov: how many rows are in the password table?15:27
stevemardolphm: i shall watch it15:27
dolphmstevemar: that was after 2 or 3 days of super minimal sleep. i had a terrible headache :(15:27
*** EinstCrazy has quit IRC15:28
*** EinstCrazy has joined #openstack-keystone15:29
*** EinstCrazy has quit IRC15:29
rderoseamakarov: it seems like a new table to me, failed_auth_history or something (user_id, timestamp, msg...)15:29
*** spzala has joined #openstack-keystone15:29
amakarovrderose, well, I haven't seen it from this point: thought it's only 1 password per user15:29
amakarovrderose, I agree about a new table then15:30
rderoseamakarov: local_user to password is 1 to many15:30
rderoseamakarov: cool15:30
*** openstackgerrit has quit IRC15:33
*** openstackgerrit has joined #openstack-keystone15:33
lbragstadstevemar dolphm I love tim's plug at the end to upgrade to keystone v315:34
dolphmlol15:35
*** code-R has joined #openstack-keystone15:35
*** wasmum has joined #openstack-keystone15:38
*** phalmos_ has quit IRC15:40
*** TxGVNN has joined #openstack-keystone15:40
*** phalmos has joined #openstack-keystone15:40
*** KevinE has joined #openstack-keystone15:41
*** dmk0202 has quit IRC15:42
shewlesshi 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 user15:43
shewlessI 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-keystone15:45
*** ChanServ sets mode: +v ayoung15:45
KevinEhttps://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 wrong15:50
patchbotKevinE: patch 321809 - python-keystoneclient - OS_INTERFACE ignored when determining endpoint_type15:50
*** tesseract has quit IRC15:54
*** tonytan4ever has joined #openstack-keystone15:54
*** nisha_ has joined #openstack-keystone15:56
amakarovrderose, it looks like I have to add that backend directly to auth rather than identity if I want it independent from the identity driver15:56
amakarovrderose, is there a spec CR about PCI or it already merged?15:57
*** pcaruana has quit IRC15:59
*** dan_nguyen has joined #openstack-keystone15:59
*** nisha_ has quit IRC15:59
*** henrynash has joined #openstack-keystone16:00
*** ChanServ sets mode: +v henrynash16:00
*** gyee has joined #openstack-keystone16:00
*** ChanServ sets mode: +v gyee16:00
henrynashshewless: hi16:01
*** dimonv has quit IRC16:01
*** nisha_ has joined #openstack-keystone16:02
*** gokrokve has joined #openstack-keystone16:04
*** lhcheng has joined #openstack-keystone16:07
*** ChanServ sets mode: +v lhcheng16:07
rderoseamakarov: 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 IRC16:11
rderoseamakarov: and not federation for example16:11
rderoseamakarov: PCI specs: #link https://github.com/openstack/keystone-specs/blob/master/specs/keystone/newton/pci-dss.rst16:11
amakarovrderose, thank you16:15
rderoseamakarov: np16:15
*** pushkaru has quit IRC16:17
dstanekdolphm: no, but i'm working on keystone again today so i can start pushing16:21
*** nisha_ has quit IRC16:22
dstanekrderose: 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 sufficient16:24
*** ayoung has quit IRC16:25
*** mugsie_ has joined #openstack-keystone16:25
*** nisha_ has joined #openstack-keystone16:25
rderosedstanek: to me on-the-fly (authentication) is sufficient, but do you have a concern16:26
samueldmqrderose: just a minor comment in patch 31467916:28
patchbotsamueldmq: https://review.openstack.org/#/c/314679/ - keystone - Config settings to support PCI-DSS16:28
samueldmqrderose: otherwise looks good16:28
rderosesamueldmq: makes sense, thanks16:28
openstackgerritRon De Rose proposed openstack/keystone: Config settings to support PCI-DSS  https://review.openstack.org/31467916:30
KevinEactually new idea, can someone check this out when you have a free second? https://review.openstack.org/#/c/320056/16:30
patchbotKevinE: patch 320056 - rally - Tie endpoint_type to interface16:30
KevinEI know it's a rally change, but it's really a keystone issue16:31
*** pushkaru has joined #openstack-keystone16:31
samueldmqrderose: thanks16:32
rderosesamueldmq: thank you :)16:33
dstanekrderose: no, no concern. just trying to figure out if i should be16:33
samueldmqis it just on my patches, or keystone-coverage-db is so broken that no patch pass jenkins jobs ?16:33
rderosedstanek: cool.  yeah, the only reason I think to do a migration is if were changing the user ID16:34
rderosesamueldmq: it's failing my patches as well16:35
*** jbell8 has quit IRC16:35
*** arunkant has joined #openstack-keystone16:36
nisha_samueldmq, I am trying to follow this guide http://docs.openstack.org/developer/python-keystoneclient/api/keystoneclient.v3.html#module-keystoneclient.v3.groups16:36
nisha_samueldmq, there is an example using >>> user = keystone.users.get(USER_ID)16:37
nisha_>>> user.delete()16:37
samueldmqnisha_: nice, that describes the group operation in the client16:38
nisha_samueldmq, what should I use in place of USER_ID?16:38
samueldmqnisha_: the ID of an existing user in keystone server16:39
samueldmqnisha_: to see what users exist, you can list them all with keystone.users.get()16:39
samueldmqnisha_: doing keystone.users.get(USER_ID) will return the user object (from keystone server) that matches the provided ID, it it exists16: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-keystone16:42
*** ChanServ sets mode: +v ayoung16:42
*** nisha_ has quit IRC16:42
openstackgerritMerged openstack/keystone-specs: Microversions  https://review.openstack.org/31518016:42
*** permalac has quit IRC16:42
*** rderose has quit IRC16:44
*** TxGVNN has quit IRC16:45
*** tonytan4ever has quit IRC16:46
*** diazjf has joined #openstack-keystone16:47
*** nisha_ has joined #openstack-keystone16:49
openstackgerritMerged openstack/keystonemiddleware: Use method split_path from oslo.utils  https://review.openstack.org/32310116:50
*** diazjf has quit IRC16:50
*** nisha_ has quit IRC16:50
openstackgerritAlexander Makarov proposed openstack/keystone-specs: Allow admin to specify project id on creation  https://review.openstack.org/32349916:51
*** mvk has quit IRC16:51
*** spandhe has joined #openstack-keystone16:53
*** nisha_ has joined #openstack-keystone16:59
*** nisha_ has quit IRC17:00
*** sigmavirus24 is now known as sigmavirus24_awa17:00
*** links has joined #openstack-keystone17:00
*** clenimar has joined #openstack-keystone17:00
*** woodburn has joined #openstack-keystone17:00
*** alex_xu has quit IRC17:00
*** mugsie_ is now known as mugsie17:01
*** rcernin has joined #openstack-keystone17:01
*** phalmos has joined #openstack-keystone17:02
*** alex_xu has joined #openstack-keystone17:02
*** nisha_ has joined #openstack-keystone17:04
*** gokrokve has quit IRC17:06
*** amrith is now known as _amrith_17:09
*** rderose has joined #openstack-keystone17:10
*** links has quit IRC17:11
*** jbell8 has joined #openstack-keystone17:12
openstackgerritguang-yee proposed openstack/keystonemiddleware: Support local config options  https://review.openstack.org/32188217:12
nisha_samueldmq, I have been trying to add a user to a group using  add_to_group(user, group)17:13
samueldmqnisha_: nice, for that you will need to provide both a valid user ID and group ID17:13
nisha_samueldmq, yeah, I did that, but it says NameError: name 'add_to_group' is not defined17:14
samueldmqnisha_: again, you can create them; or simply list what's available with client.users.list() and client.groups.list()17:14
samueldmqnisha_: keystone.users.add_to_group(...) ?17:15
samueldmqnisha_: notice it's in users module http://docs.openstack.org/developer/python-keystoneclient/api/keystoneclient.v3.html#keystoneclient.v3.users.UserManager.add_to_group17:15
*** tonytan4ever has joined #openstack-keystone17:16
shewless+henrynash: hi17:17
henrynashshewless: hi17:17
*** rderose_ has joined #openstack-keystone17: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
samueldmqnisha_: 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
henrynashshawless: ok17: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 defined17:19
henrynashshawless: although it won’t create such a project17:19
shewless+henrynash: but I need to manually create the project17:19
samueldmqnisha_: client.users.delete(user)17:20
nisha_samueldmq, when I do user.delete() then it deletes17:20
henrynashshewless: 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
samueldmqnisha_: see http://docs.openstack.org/developer/python-keystoneclient/api/keystoneclient.v3.html#keystoneclient.v3.users.UserManager.delete17:20
shewless+henrynash: I'm not sure what you mean by that..17:20
samueldmqnisha_: all the operations are documented there17:20
henrynashshewless: so we often have this debate about how much “automaction” keystone should do in these kinds of situations17:20
*** rderose has quit IRC17:21
*** tonytan4ever has quit IRC17:21
samueldmqnisha_: if it's users module, then keystone.users.<operation>; for groups: keystone.groups.<operation>, etc17:21
nisha_samueldmq, yes, I am trying to follow it17:21
samueldmqnisha_: the operations are described there, by module17: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 :D17:21
henrynashshewless: 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 keystone17:21
*** _amrith_ is now known as amrith17:21
shewless+henrynash: okay: do you know what service I would use for orchestration?17:22
samueldmqnisha_: so you don't call delete(user), you always need to call the keystoneclient instance17:22
shewless..and would I experience this same challenge if I used "federation"?17:22
samueldmqnisha_: so in your case: keystone.users.delete(x), where x is a user object or a user ID17:22
*** nisha_ has quit IRC17:22
henrynashshewless: yes, if you really want to auto-create a project per user, then federation doesn’t help you17:23
henrynashshewless: the groups don’t either, that would be for a different use case17:24
shewless+henrynash: so when you say "orchestration" I think "heat" -- but that's not what you're talking about here right?17:24
henrynashshewless: in theory the openstack mistral project should be the thing to use17:24
henrynashshewless: or at least that would be the pure openstack solution…I  have never used it17:25
*** tonytan4ever has joined #openstack-keystone17:25
shewless+henrynash: thanks for your help17:26
*** nisha_ has joined #openstack-keystone17:26
henrynashshewless: 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 assigned17:26
henrynashshewless: not vrey nice, since polling all users from ldap is not a nice thing to do….but you get teh concept17:27
*** nisha_ has quit IRC17:31
*** agrebennikov has joined #openstack-keystone17:31
*** nisha_ has joined #openstack-keystone17: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 things17:35
henrynashshewless: ok17:36
*** JayF has joined #openstack-keystone17:37
JayFjamielennox: 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 looks17:37
JayFjamielennox: like it's on the right track17:37
*** itisha has quit IRC17:40
*** wasmum has quit IRC17:41
*** amrith is now known as _amrith_17:44
KevinECan anyone tell me why this does not pass endpoint_type? https://github.com/openstack/rally/blob/master/rally/osclients.py#L242-L25117:49
*** roxanaghe has joined #openstack-keystone17:51
*** Alexander has joined #openstack-keystone17:52
*** Alexander is now known as Guest4274017:52
*** amakarov has quit IRC17:54
*** Guest42740 is now known as amakarov17:54
*** alexander__ has joined #openstack-keystone17:54
*** daemontool__ has quit IRC17:54
*** daemontool has joined #openstack-keystone17:55
*** haneef has joined #openstack-keystone17:55
*** jaugustine has quit IRC17:56
openstackgerrithenry-nash proposed openstack/keystone-specs: Support hierarchical project naming  https://review.openstack.org/31860517:57
*** jaugustine has joined #openstack-keystone17:58
*** jbell8 has quit IRC17:58
*** jbell8 has joined #openstack-keystone17:59
*** nkinder has quit IRC18:01
notmorganmeeting 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, xek18:01
*** gagehugo_ has joined #openstack-keystone18:02
amakarovagrebennikov: please join #openstack-meeting18:03
*** shaleh has joined #openstack-keystone18:05
*** gagehugo_ has quit IRC18:06
jlkQuestion.  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
jlkHowever 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-keystone18:07
rodrigodsjlk, is listing every user from every domain a desirable thing for you? It is currently restricted in the policy file18:09
rodrigodsyou would need to change the rule18:09
jlkrodrigods: maybe.18:09
*** jed56 has quit IRC18:09
jlkrodrigods: 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
jlkI 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
lhchengthe username is unique by Domain, I think you have to check in each Domain18:10
jlklhcheng: I would, yes. I'm working up to that point18:11
rodrigodsjlk, and the powers to list everything everywhere is from the cloud_admin: https://github.com/openstack/keystone/blob/master/etc/policy.v3cloudsample.json#L318:11
jlkTrying to sort out what needs to change where, in keystoneclient code or otherwise.18:11
jlkrodrigods: but what act is it?  There are only two 'list_user' like acts in the policy file18:12
jlkrodrigods: and in my policy file the user I'm using is already allowed both of those.18:12
amakarovwell, colleagues, I repeat my question: do anybody have objections on the bp/spec in question?18:13
*** flwang has joined #openstack-keystone18:13
jlksince, clearly, my user using the command line client is able to list users of a particular domain18:13
jlkso 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 IRC18:14
jlkah, looks like the APi forces a list_users call to have a domain_id in the hints.18:15
jlk*grumble*18:15
rodrigodsjlk, ah, yes18:15
rodrigodsthat's the case18:15
rodrigodsit uses the domain_id from the context18:15
jlkand 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-keystone18:17
*** gagehugo_ has quit IRC18:17
rodrigodsjlk, yes... you could provide a patch to improve the API reference :)18:18
jlkheh.18:18
rodrigodsjlk, i can help reviewing it18:18
jlkso 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 IRC18:20
*** diazjf has joined #openstack-keystone18:23
kfox1111does the ldap plugin try and validate ldap groups with every validate?18:23
kfox1111or just logins?18:23
*** doug-fish has joined #openstack-keystone18:26
*** gagehugo_ has joined #openstack-keystone18:28
*** code-R_ has joined #openstack-keystone18:29
*** code-R has quit IRC18:29
kfox1111how frequently does it rescan ldap? it seems like fairly regularly?18:30
*** gagehugo_ has quit IRC18:30
*** wasmum has quit IRC18:36
*** jaugustine has quit IRC18:37
*** nisha_ has quit IRC18:38
*** doug-fish has quit IRC18:40
*** doug-fish has joined #openstack-keystone18:40
*** nisha_ has joined #openstack-keystone18:41
shewlesswould 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 section18:41
dolphmagrebennikov: 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 first18:41
agrebennikovdolphm, everything in my world comes from production deployments.18:42
agrebennikovfirst, you always have to avoid cross-dc activity if possible18:42
agrebennikovsecond, you have to make sure that any kind of disconnection doesn't cause service interuption18:43
agrebennikovas well as race conditions18:43
*** doug-fish has quit IRC18:43
*** doug-fish has joined #openstack-keystone18:43
rodrigodsagrebennikov, yeah... but as dolphm said, the proposal looks like a "hack" to keystone to make that work18:43
agrebennikovand there is a third reason actually18:43
*** nisha__ has joined #openstack-keystone18:44
openstackgerritRon De Rose proposed openstack/keystone: WIP - Shadow LDAP and custom driver users  https://review.openstack.org/30548718:44
agrebennikovthe 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
agrebennikovdolphm, 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 IRC18:46
agrebennikovit is not "do smtng" change18:46
rodrigodsagrebennikov, fair enough... did you try to do some testing with the change you are proposing? every time something like that happens really strange stuff happens18:46
*** doug-fish has joined #openstack-keystone18:46
agrebennikovrodrigods, what you mean? testing what18:46
*** nisha_ has quit IRC18:47
rodrigodsagrebennikov, i mean... a change like that might have really unpredictable outcomes18:47
agrebennikovrodrigods, in v2 case (where it works out of the box) we have a prod deployment with about 50 zones18:48
rodrigodsbecause everything on top of the v3 API was thought assuming that behavior18:48
amakarovrodrigods: we didn't do it downstream so we can't provide such insight18:48
agrebennikovwhere the projects are created automatically with same IDs18:48
shewlessthis 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
agrebennikovrodrigods, what I could only do - take liberty and make a db hack to make the IDs of current projects the same18:48
rodrigodsagrebennikov, also have in mind that changing this, also changes domains18:49
openstackgerritRon De Rose proposed openstack/keystone: WIP - Shadow LDAP and custom driver users  https://review.openstack.org/30548718:50
agrebennikovrodrigods, this is correct, but when we have the same set of users18:50
*** doug-fis_ has joined #openstack-keystone18:50
agrebennikovit automatically means we have the same domain18:50
agrebennikovrodrigods, or you are talkning about smtng else?18:51
*** doug-fish has quit IRC18:51
rodrigodsagrebennikov, this is for your deployment... i'm wondering the effect it would have in different kinds of deployments18:52
rodrigods(allowing to set the domain name)18:52
agrebennikovrodrigods, name or id?18:52
rodrigodsid*18:52
rodrigodsagrebennikov, nvm, let's wait for dolphm spec :)18:52
agrebennikovrodrigods, I didn't actually get what it is exactly about ;()18:53
agrebennikovrodrigods, again some "lets use federation for everything" thing?18:53
rodrigodsagrebennikov, federation is usually the right answer for this problem18:54
rodrigodskeystone is not that good in authn18:54
KevinEWhenever 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
agrebennikovKevinE, probably because the os var tells it to go to admin endpoint?18:55
agrebennikovrodrigods, federation setup is usually supercomplicated and unclear)) this is the answer ;)18:56
KevinEagrebennikov: OS_INTERFACE=public and OS_ENDPOINT_TYPE=publicURL18:56
agrebennikovKevinE, how you call keystone?18:56
rodrigodsagrebennikov, don't say that :) you would hurt my feelings18:56
KevinEagrebennikov: What do you mean? I'm doing the sample create_delete_user18:57
agrebennikovrodrigods, it took about a year to realize "saml, keystone, shib, apache, sso, assertions" combination and roles))18:58
agrebennikovKevinE, but does it get a catalog properly with public url available? or it happens on the first step when it tries to get the catalog18:59
notmorganok so-- keystone-coresec. we have a lot of people on the list.19:00
agrebennikovKevinE, obviously on the first call19:00
*** diazjf has quit IRC19:00
agrebennikovbut can you print the url it is calling to?19:00
notmorganwho 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|away19:00
notmorgani'd like to get us down to ~5 people on the list.19:01
gyeenotmorgan, sure19:01
KevinEagrebennikov: http://pastebin.com/HM3qgaCt19:01
henrynashnotmorgan: I’ll step down from the list19:01
samueldmqnotmorgan: triaging bugs that are tagged as security issue ?19:01
lbragstadjamielennox I was just waving good bye19:01
notmorgansamueldmq: correct, these would be the private bugs.19:01
*** pushkaru has quit IRC19:01
*** pumarani__ has joined #openstack-keystone19:01
gyeebtw, betamax sound like a muscle building protein shake :-)19:02
KevinEagrebennikov: let me know if that answers your question :)19:02
agrebennikovKevinE, can you please show you cloud json19:02
notmorganso, stevemar is staying on it (PTL),19:02
samueldmqnotmorgan: 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
samueldmqnotmorgan: if there is still available spots, of course19:02
notmorganok so here is the way i'm going to do it.19:02
ayoungjamielennox, ok...lets focus on a mechanism before tackling the whole service toke thing19:03
*** diazjf has joined #openstack-keystone19:03
jamielennoxlbragstad: ah, i thought you were trying to do like a catch attention from the back with something to say19:03
notmorgani'm going to just ask the individuals who are on it.19:03
dstaneknotmorgan: do a lottery19:03
notmorganfor now.19:03
ayounghow does, say, nova know that an operation would be legal on , say Cinder?19:03
* samueldmq nods19:04
notmorgandstanek: eh. i think most people don't look at the private bugs besides dolphm, me, and steve (primarily)19:04
rodrigodsnotmorgan, 5 besides you and stevemar ?19:04
ayoungwe have two ways to check...19:04
KevinEagrebennikov: http://pastebin.com/PXqMWmTK19:04
dstaneknotmorgan: and brant19:04
ayoung1.  have some flag in the APi call which is "check but don't really do it"19:04
ayoungand look at the response code19:04
ayoungthe other is to make the call with no permissions and get back "here are the roles you need once you authenticate"19:04
notmorganjamielennox: are you ok with stepping down from core-sec?19:05
jamielennoxnotmorgan: 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
notmorganjamielennox: you'll probably be looped in anyway for client etc.19:05
ayoungyou can guess which I like better, and which I think you guys are going to go for.19:05
agrebennikovKevinE, XXX is adminEndpoint?19:05
notmorganok19:05
kfox1111is there a way to specify how frequently ldap should scan for changes?19:05
openstackgerritwerner mendizabal proposed openstack/keystone-specs: Credential Encryption  https://review.openstack.org/28495019:05
agrebennikovKevinE, seems to be a problem with rally workflow - by default in v2 keystone only allows to create tenant/users/assignments through 3535719:06
notmorganbknudson, ayoung, gyee, dstanek, dolphm: are all of you still comitting to core-sec (security) reviews?19:06
jamielennoxayoung: 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 expiration19:06
agrebennikovand it doesn't recognize that it should go through 5000 when it is v319:06
gsilvisdtroyer: still getting that error on a freshly checked out stable/mitaka devstack19:06
KevinEagrebennikov: That's what I've been trying to fix for 2.5 weeks now, with 2 rejected changes :/19:06
bknudsonnotmorgan: I can't commit to anything19:06
ayoungjamielennox, the word "only" there scares me19:07
agrebennikovKevinE, you'd better ask in #openstack-rally19:07
notmorganbknudson: :(19:07
KevinEagrebennikov: 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
jamielennoxayoung: so really i think that all APIs re-entering the public interface is a PITA and a bad design19:07
jamielennoxayoung: but OMG the cross-project spec that we would need to fix that19:08
notmorganjamielennox: hehe right?19:08
jamielennoxayoung: also did you see https://review.openstack.org/#/c/289405/ ?19:08
patchbotjamielennox: patch 289405 - nova-specs - Adds Nova discoverable policy CLI spec19:08
dstaneknotmorgan: yes, i can commit to it19:09
jamielennoxi don't think i like it -but that's my first response to most things :p19:09
KevinEagrebennikov: Do you have any hints I can use? I'm an extreme Openstack amateur and clearly my attempts at fixing this won't work haha19:09
notmorgandstanek: ok.19:09
jamielennoxayoung: but i don't know what else to suggest in the mean time19:09
KevinEjamielennox: Unless you can help me, you have me the -1 on my most recent attempt at resolving my issue :)19:09
agrebennikovKevinE, what is your adminurl in the catalog?19:09
dolphmnotmorgan: yes19:09
notmorgani'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
jamielennoxKevinE: sup? sorry wasn't looking at the meeting then people started talking again19:10
KevinEagrebennikov: 3535719:10
agrebennikovKevinE, this is nothing about keystone19:10
notmorganthere 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 it19:10
agrebennikovKevinE, but does your rally call to this exact url?19:10
ayoungjamielennox, yeah, I liketheCLI spec, but I don't think it helps here19:11
ayoungjamielennox, if Nova is going to approve for a user, it really should know that the approval is correct19:12
dstanekKevinE: what is your issue? did you file a bug?19:12
ayoungjamielennox, this is why I was pushing dynamic policy19:12
KevinEjamielennox: 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-keystone19:12
ayoungWe can't tell a user "hey that is OK" and then later say "We lied"19:12
ayoungwell, we can.. .we do19:12
ayoungwe treat users badly19:13
KevinEdstanek: https://bugs.launchpad.net/keystone/+bug/1586434 I don't know how to file bugs so please ask for more details if you need them19:13
openstackLaunchpad bug 1586434 in OpenStack Identity (keystone) "Service Catalog ignores interface" [Undecided,New]19:13
notmorganayoung: yes we do19:13
KevinEagrebennikov: what do you mean does my rally call to that url?19:13
ayoungnotmorgan, so...lets say I was going to go along with your plan19:13
jamielennoxayoung: right, agreed19:13
agrebennikovKevinE, in the paste you sent19:13
dstanekKevinE: why are you mucking with v2 changes at all?19:13
ayounghow do we check that the permissions for glance are OK when we hit the border of Nova?19:13
agrebennikovKevinE, http://adminEndpoint:35357 - is this the endpoint from your catalog?19:14
notmorganayoung: mostly nova does this checking directly. if you look at the workflow.19:14
KevinEagrebennikov: dstanek: wait a minute, no this is a v3 issue not v2 sorry19:14
bknudsoneven if we check the permissions could change19:14
KevinEagrebennikov: yes it is19:14
ayoungnotmorgan, but how would Nova know what project owns a volume?19:14
agrebennikovKevinE, so seems it is hardcoded in rally to extract the adminurl19:14
jamielennoxKevinE: so if rally is passing endpoint_type i don't think keystoneclient will mess with it - regarless of api version19:14
notmorganayoung: nova has to ask cinder "hey XXX volume, we good?"19:14
agrebennikovjust go ahead and change the db19:15
ayoungnotmorgan, and how does it do this?19:15
agrebennikovKevinE, make it exactly the same as a publc url19:15
jamielennoxayoung: i don't have an answer for any of this19:15
*** tqtran has joined #openstack-keystone19:15
ayoungit needs to know "I am got to do a write call in the future...will that succeed"19:15
notmorganayoung: today it would use the scope of the user, my point is if nova asks cinder and gets an affirmative, we're good19:15
jamielennoxagrebennikov: there's a reason to have those two urls seperate, rally should definitely pass the interface it wants to use19:15
jamielennoxagrebennikov: and if keystoneclient is ignoring that it's a bug19:15
notmorganayoung: the "check at the edge" is more of a when I ask to make a snapshot and we're given an OK19:16
jamielennoxnotmorgan: that policy check chain then extends the entire length of the actual operation chain19:16
agrebennikovjamielennox, I understand it, but in this case the external client seems cannot connect to admin endpoint19:16
notmorganayoung: don't ask again mid way through19:16
ayoungnotmorgan, 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 default19:16
notmorganayoung: most services can give you an affirmative on all the things they need to do before performing actions.19:17
agrebennikovjamielennox, KevinE (rally is this external client)19:17
jamielennoxagrebennikov: that's generally the right way to deploy it for v219:17
agrebennikovjamielennox, I know)19:17
jamielennoxKevinE: so what's going wrong when you tell rally to use public endpoint?19:17
agrebennikovjamielennox, but when you want to create/delete users with rally....19:17
jamielennoxKevinE: i guess it's optimistic to think that rally is using keystoneauth?19:17
KevinEagrebennikov: jamielennox telling rally to use EVERYTHING public fails at contacting the admin endpoint lol19:17
notmorganayoung: "client like" services are going to use explict delegations. what is trove asking nova for?19:17
ayoungnotmorgan, 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 now19:18
ayoungnormal case19:18
KevinEjamielennox: http://pastebin.com/HM3qgaCt19:18
agrebennikovjamielennox, I have to ask boris-42 when he is available))19:18
ayoungbut I don't want to say "cinder is going to trust any call it get fromNova"19:18
dstanekKevinE: is the actually a bug in keystone or a bug in the thing using keystoneclient?19:18
notmorganayoung: right, this is why i was saying we're mostly on the same page.19:18
jamielennoxKevinE: right - why is rally trying to contact the admin endopint when it was told not to?19:18
ayoungbecause that will get extended to19:18
ayoung"nova will trust any call it gets from *aaS"19:18
KevinEJesus I'm getting so confused lol19:18
notmorganayoung: so lets look at what sahara asks nova for...or trove19:19
agrebennikovjamielennox, it was Not told to contact public)) it contacts public to and gets the catalog, and then it wants to create users. Obviously through admin19:19
KevinEdstanek: I don't think I know19:19
notmorganayoung: lets assume nova/cinder/glance are an easy solve to be trusted... and see how the non-easy cases look19:19
notmorganayoung: and i think that directs how we approach this.19:19
KevinEjamielennox: >>my problem<< lol19:19
agrebennikovKevinE, ^^19:20
jamielennoxagrebennikov: 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 interface19:20
jamielennoxagrebennikov: user creation via public interface is fine in v319:20
*** _amrith_ is now known as amrith19:20
agrebennikovjamielennox, then it should be a specific option in rally19:20
agrebennikovjamielennox, I know))19:20
KevinEoh sorry, yes agrebennikov is correct I believe19:20
jamielennoxagrebennikov: ++19:20
agrebennikovthat is what I told KevinE19:20
KevinEOkay now I'm getting lost sorry agrebennikov jamielennox19:21
*** roxanaghe has quit IRC19:21
notmorganayoung: i think we're getting to an explicit delegation for sahara, which would then be checked at the edge by nova19:21
agrebennikovjamielennox, KevinE this is why I have to go poke boris-42 and tell them about it19:21
jamielennoxcool :)19:21
notmorganayoung: or well at nova's api surface19:21
jamielennoxagrebennikov: it would be great if he could use keystoneauth in the process :)19:21
ayoungnotmorgan, I really want it to be an explicit delegation everywhere, but to make that simple, automatic, and robust19:21
agrebennikovKevinE, this is what we usually did with our deployments - we temporarily changed adminurl to be public, tested, changed it back19:21
notmorganayoung: so i think the core services are going to be a LOT harder to do that with.19:22
*** gagehugo_ has joined #openstack-keystone19:22
ayoungnotmorgan, really?  Cuz everything has  been soooo easy thus far.19:22
agrebennikovKevinE, since we just started v3 implementations19:22
*** rderose_ has quit IRC19:22
notmorganayoung: 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
KevinEagrebennikov: so we're saying that this is def a problem correct?19:22
notmorganayoung: easier to trace.19:22
agrebennikovKevinE, for v3/rally - it definitely is19:22
KevinEagrebennikov: Currently we have a workaround with a hotfix in service_catalog.py, but my task was to fix it upstream :/19:23
KevinEagrebennikov: and I clearly know nothing19:23
ayoungnotmorgan, 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
notmorganayoung: but again, lets look at what the *aas things do.19:23
agrebennikovKevinE, ping me about 2-3 hours later, I'll poke boris19:23
ayoungThe right thing would be to make policy enforced on URL, not some randmom majik unmappable string19:23
*** jbell8 has quit IRC19:24
ayoungand drop the part where it gets the project id, soi we can do it in middleware19:24
jamielennoxagrebennikov: thanks19:24
KevinEagrebennikov: 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 tests19:24
ayoungand then make a query interface in to keystone, and stick all policy in keystone19:24
*** gagehugo_ has quit IRC19:24
notmorganayoung: wait what? scope check in the middleware?19:24
ayoungnotmorgan, no19:24
notmorganayoung: ok phew19:24
ayoungnot scope echjeck19:24
ayoungrole check only19:24
notmorganwas gonna call you crazy ;)19:24
KevinEagrebennikov: https://review.openstack.org/#/c/320056/ https://review.openstack.org/#/c/321809/19:25
notmorganayoung: i think we already said that was a good idea.19:25
patchbotKevinE: patch 320056 - rally - Tie endpoint_type to interface19:25
patchbotKevinE: patch 321809 - python-keystoneclient - OS_INTERFACE ignored when determining endpoint_type19:25
ayoungnotmorgan, "drop the part..."19:25
nisha_hey all!19:25
*** amakarov has quit IRC19:25
notmorganayoung: url matching19:25
notmorganayoung: and such19:25
ayoungnotmorgan, yep..the URL matching is the tricky part19:25
KevinEagrebennikov: with that, I will get back to you in 2 hours, feel free to ping me whenever!19:25
*** sheel has quit IRC19:25
notmorganayoung: and i think everyone liked it.19:25
ayoungnotmorgan, and yet it died...19:25
ayoungso...I thinkI have an anser to one part of that19:25
agrebennikovKevinE, ok, sounds good19:26
notmorganayoung: no, it just didn't get implemented in oslo.policy19:26
nisha_I have a doubt. I ran ./stack.sh and after completion it said there are two users admin and default with password nomoresecret19:26
ayoungthe "how do we get the right policy for an endpoiint"19:26
notmorganit didn't die so much as whithered.19:26
gyeeurl matching, as in endpoint enforcement?19:26
notmorganayoung: match the URI part first.19:26
notmorgannot the endpoint part19:26
notmorganwe can do this in steps.19:26
notmorganchop host/port off and match the request.19:26
notmorganthose are "known" in all cases19:26
ayoungnotmorgan, so...the endpoints didn't know their own identity19:27
notmorganthye don't have to .19:27
notmorgannot for this part.19:27
ayoungthere were a couple waysto resolve that19:27
jamielennoxnisha_: yep19:27
*** edtubill has quit IRC19: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-keystone19:28
nisha_and this works fine19:28
ayoungjamielennox, to check the keystoneauth kerb thing..what should I do?19:28
ayounghttps://review.openstack.org/#/c/321814/19:29
patchbotayoung: patch 321814 - keystoneauth - Make the kerberos plugin loadable19:29
nisha_jamielennox, I don't understand why i have to create admin user again by using this command here?19:29
jamielennoxnisha_: that doesn't do anything yet, it will auth when it first gets used - but yea that looks right19: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
jamielennoxayoung: so the kerberos that is being implemented is the one with the type=kerberos in the request body19:29
ayoungjamielennox, can I use a venv and openstack cli?19:29
nisha_jamielennox, and it shows the list of users.19:30
jamielennoxayoung: so it would be setup IPA, [auth] type=kerberos=external19:30
ayoungOS_AUTH_TYPE=kerberos or summat?19:30
jamielennoxayoung:  then yea, openstack --os-auth-type kerberos ... user list or something19: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
ayoungjamielennox, but rippowam woiuld not work, becuase only the Fed URL is kerberized?19:31
jamielennoxayoung: we need to resurrect the federated kerberos one as well because that should be the recommended way to do this19:31
ayoungjamielennox, but this plugin is not federated?19:32
samueldmqnisha_: that's just passing the information to authenticate19:32
jamielennoxayoung: yea, this was the original kerberos attempt where we had like a whole another url for kerberos19:32
ayoungok, I can replicate that.  Will take a little longer19:32
samueldmqnisha_: operations you run in that keystoneclient instance will use that auth credentials to authenticate against keystone server19:32
jamielennoxsamueldmq: thanks19:32
nisha_samueldmq, thanks for clearing it up19:33
jamielennoxayoung: we need to get the fedkerb one up and running again, but i don't want to change the plugin names between keystoneclient and keystoneauth19:33
ayoungjamielennox, I think the febkerb one is broken anyway...least on Fedora19:34
jamielennoxayoung: i was kind of not implementing the kerberos loader because i was hoping noone was using it19:34
jamielennoxayoung: why?19:34
*** jbell8 has joined #openstack-keystone19:35
*** gyee has quit IRC19:35
openstackgerrithenry-nash proposed openstack/keystone-specs: Relax the project name uniqueness constraints  https://review.openstack.org/31004819:36
*** jbell8 has quit IRC19:36
openstackgerrithenry-nash proposed openstack/keystone-specs: Support hierarchical project naming  https://review.openstack.org/31860519:37
ayoungjamielennox, 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.create19:38
ayoungjamielennox, I tried it on a rippowam system and it worked when I was ssh in remotely, but not from my laptop19:38
jamielennoxayoung: in ksc it was in ksc-kerberos repo, in ksa we have it in extras19:38
ayounglaptop is using the Fedora packages19:38
*** daemontool has quit IRC19: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
openstackgerrithenry-nash proposed openstack/keystone-specs: Support hierarchical project naming  https://review.openstack.org/31860519:39
openstackgerrithenry-nash proposed openstack/keystone-specs: Relax the project name uniqueness constraints  https://review.openstack.org/31004819:39
ayoungjamielennox, might just been that I didn't have it installed19:39
*** wasmum has joined #openstack-keystone19:40
ayounganyway, 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 again19:40
openstackgerritLance Bragstad proposed openstack/keystone-specs: Add spec for fernet key store backends  https://review.openstack.org/31126819:41
henrynashrodigods, 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 path19:41
jamielennoxayoung: 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 people19:42
*** mvk has joined #openstack-keystone19:42
henrynashrodigods, 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
samueldmqnisha_: the warning in the docs (in the link you just sent) say you should use default_project instead19:42
samueldmqnisha_: the argument default_project instead of project, the call is the same19:42
ayounghenrynash, go by the Unix conventions.19:43
nisha_samueldmq, alright!19:43
ayoungpwd works regardless of perms on the parent19:43
jamielennoxnisha_: ideally you shouldn't need to add a defualt_project to a user at all19:43
samueldmqhenrynash: sure, I will take a look19:43
samueldmqjamielennox: ++19:43
jamielennoxnisha_: 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 recently19:43
jamielennoxnisha_: so if you create a user, then assign a role to that user on a project it should have the same practical effect19:44
nisha_jamielennox, thanks a lot, got it!19:44
*** sdake has joined #openstack-keystone19:45
*** jbell8 has joined #openstack-keystone19:45
*** adu has quit IRC19:46
henrynashayoung: 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 roles19:46
henrynashayoung: since I can’t cd into a dir that has a parent in which I have no permisions19:46
ayounghenrynash, difference between inode and dentry19:46
ayoungonly ls is forbidden19:47
*** itisha has joined #openstack-keystone19:47
henrynashayoung: cd doesn’t work either19:47
*** gagehugo has quit IRC19:47
henrynash(henery never claiming to be a unix expert)19:47
ayoungif you have perm on the dentry itself, you can open it, by full path, without doing an ls on the parent19:48
openstackgerritCorey Bryant proposed openstack/python-keystoneclient: import warnings in doc/source/conf.py  https://review.openstack.org/32355319:48
henrynashayoung: ah, think I get your gist19:48
*** sdake_ has joined #openstack-keystone19:49
henrynashayoung: 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 IRC19:50
*** sdake has quit IRC19:51
*** ayoung has quit IRC19:54
henrynashnotmorgan: 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 it19:55
patchbothenrynash: patch 310048 - keystone-specs - Relax the project name uniqueness constraints19:55
*** ayoung has joined #openstack-keystone19:55
*** ChanServ sets mode: +v ayoung19:55
notmorganhenrynash: sure.19:56
henrynashnotmorgan: thx19:56
notmorgandone, to a -1 instead.19:57
notmorganjust because it needs some reworking to cover the microversion stuff.19:57
notmorganbut not too much to have to deal with19:57
*** jbell8 has joined #openstack-keystone20:02
*** diazjf has quit IRC20:04
*** dmk0202 has joined #openstack-keystone20:05
*** roxanaghe has joined #openstack-keystone20:05
*** jbell8 has quit IRC20:08
*** diazjf has joined #openstack-keystone20:09
ayounghenrynash, ok...let me confirm...20:10
ayounghenrynash, hmm...you are right.  let's see waht strace shows20:13
ayoungopen("/tmp/testay/1/2/3/hello", O_RDONLY) = -1 EACCES (Permission denied)20:14
*** daemontool has joined #openstack-keystone20:15
ayoungso it is not walking the tree in userland.  Must fail in doing that inside the Kernel.20:15
nisha_jamielennox, I created a new user20:16
*** diazjf has quit IRC20:16
*** nkinder has joined #openstack-keystone20:16
ayounghenrynash, 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 option20:17
*** dan_nguyen has quit IRC20: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-keystone20:23
*** code-R_ has quit IRC20:23
KevinEagrebennikov: ping :)20:23
*** clenimar has quit IRC20:24
*** rderose has joined #openstack-keystone20:25
*** dan_nguyen has joined #openstack-keystone20:26
*** ayoung has quit IRC20:27
*** dmk0202 has quit IRC20:28
*** diazjf has joined #openstack-keystone20:28
*** diazjf has quit IRC20:29
*** daemontool_ has joined #openstack-keystone20:31
*** diazjf has joined #openstack-keystone20:32
*** clenimar has joined #openstack-keystone20:32
*** daemontool has quit IRC20:33
*** julim has quit IRC20:38
*** nisha__ has joined #openstack-keystone20:39
*** nisha_ has quit IRC20:39
*** nisha__ is now known as nisha_20:44
*** dmk0202 has joined #openstack-keystone20:44
*** raildo is now known as raildo-afk20:47
*** timcline_ has joined #openstack-keystone20:48
*** gyee has joined #openstack-keystone20:48
*** ChanServ sets mode: +v gyee20:48
*** timcline has quit IRC20:50
*** georgem1 has quit IRC20:57
*** diazjf has quit IRC20:59
*** daemontool_ has quit IRC21:02
samueldmqnisha_: yes create a new group too if you want21:03
samueldmqnisha_: you can do whatever you want in devstack, if you mess things up, just ./unstack ./stack :)21:04
*** diazjf has joined #openstack-keystone21:04
*** dan_nguyen has quit IRC21:08
*** jbell8 has joined #openstack-keystone21:09
*** pauloewerton has quit IRC21:10
*** jbell8 has quit IRC21:11
*** timcline_ has quit IRC21:14
*** dan_nguyen has joined #openstack-keystone21:14
*** timcline has joined #openstack-keystone21:15
nisha_samueldmq, alright, will create a new group :)21:17
*** jbell8 has joined #openstack-keystone21:18
*** ayoung has joined #openstack-keystone21:23
*** ChanServ sets mode: +v ayoung21:23
*** clenimar has quit IRC21:24
*** gagehugo has quit IRC21:25
*** edmondsw has quit IRC21:29
openstackgerritRon De Rose proposed openstack/keystone: WIP - Refactor shadow users and deprecate driver backend  https://review.openstack.org/32359621:35
*** dan_nguyen has quit IRC21:37
nisha_samueldmq, I successfully ran some commands, http://paste.openstack.org/show/506657/21:38
*** dmk0202 has quit IRC21:38
openstackgerritRon De Rose proposed openstack/keystone: Refactor shadow users and deprecate driver backend  https://review.openstack.org/32359621:42
jlkSo I have a question.21:42
jlkor really an observation21:42
nisha_jamielennox, samueldmq thanks for help :)21:42
openstackgerritRon De Rose proposed openstack/keystone: Refactor shadow users and deprecate driver backend  https://review.openstack.org/32359621:42
*** nisha_ has quit IRC21:43
jlkI'm seeing a pretty different behavior out of keystone depending on whether or not "domain_specific_drivers_enabled = True" is set21:44
jlklike, whether or not keystone will hand back all users across domains or just a single domain21:44
jlkis that expected?21:46
stevemarjlk: are there actually additional backends or did you just flip the switch in the config file?21:48
jlkjust flipped the switch21:48
jlkWe've already had multiple domains, but only one backend21:49
jlkand 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
jlkseems like an odd thing to base behavior on.21:50
*** dan_nguyen has joined #openstack-keystone21:51
jlkah21:52
jlkThis task: https://github.com/openstack/keystone/blob/stable/mitaka/keystone/identity/controllers.py#L225-L23021:53
jlkhits this function https://github.com/openstack/keystone/blob/stable/mitaka/keystone/common/controller.py#L713-L73621:53
stevemarjlk: ahhh21:55
jlkthis explains why our automation worked, and why other tools worked before21:55
jlkbut break down when we start down the path of multiple backends.21:55
*** edtubill has quit IRC21:56
stevemarjlk: i guess if that switch is flipped then it's assumed you have >1 domain and can't safely assume you want the default domain21:56
*** diazjf has quit IRC21:57
jlkyeah, that I don't get, because it's not a good indicator.21:57
jlkif you have HEat, you've got more than one domain21:57
stevemaryeah, there should be a smarter way to evaluate that21:57
jlkwell before you go down the road of multiple backends21:57
stevemarjlk: want to file a bug?21:57
jlkmaybe it's the thought of "more than one backend makes listing every user expensive, don't do that"21:57
openstackgerritRon De Rose proposed openstack/keystone: WIP - Shadow LDAP and custom driver users  https://review.openstack.org/32360221:57
jlkstevemar: I think the outcome of any such investigation will lead to just "always require specific domain" regardless of config.21:58
jlkwhich is going to probably break a lot of things.21:58
bknudsoneven if you only have 1 domain listing all users can be expensive.21:59
jlktrue22:00
bknudsonwhy would anyone need to list all users anyways?22:00
jlkbut would it be acceptable to always list all the users, unless the API caller provided a filter?22:00
bknudsonkeystone also has result limiting so if you attempt to list all users you might not get them all back anyways22:01
jlkisn't that handled by pagination?22:01
jlkor do you just get a middlefinger?22:01
bknudsonwe don't have pagination in keystone as far as I know22:01
bknudsonwho's going to flip through 10,000 pages?22:02
jlkHorizon....   :D22:02
jlkso, I guess I just don't know what the intent here was22:02
jlkteh API doc is unclear, the behavior is unclear22:03
jlkIMHO 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
jlkit shouldn't change from one to the other due to a tangentially related config entry.22:04
*** tonytan4ever has quit IRC22:05
openstackgerritRon De Rose proposed openstack/keystone: WIP - Shadow LDAP and custom driver users  https://review.openstack.org/32360222:06
*** darosale has quit IRC22:06
jlkbknudson: it also seems to come into play when doing some cli tasks, and passing around domain and user names instead of IDs22:07
bknudsonjlk: you may be finding that the user IDs are mapped when you have domain-specific backends?22:08
openstackgerritRon De Rose proposed openstack/keystone: Shadow LDAP and custom driver users  https://review.openstack.org/32360222:08
bknudsonas 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
jlkbknudson: 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
jlkit's client code likely trying to translate a name into an ID, doing a listing, failing to find, giving up.22:09
bknudsonjlk: from the CLI? CLI might be trying to list all the users and finding the entry for the user22:09
jlkright, from the CLI22:10
jlkthe API only takes in IDs IIRC, never names22:10
openstackgerritMerged openstack/python-keystoneclient: import warnings in doc/source/conf.py  https://review.openstack.org/32355322:10
openstackgerritRon De Rose proposed openstack/keystone: Refactor shadow users and deprecate driver backend  https://review.openstack.org/32359622:10
*** sdake has joined #openstack-keystone22:10
notmorganstevemar: there is already a bug for that fyi22:11
notmorgancc jlk22:11
*** sdake_ has quit IRC22:12
notmorgandunno the id22:12
*** jbell8 has quit IRC22:13
*** tonytan4ever has joined #openstack-keystone22:14
*** ametts has quit IRC22:14
openstackgerritRon De Rose proposed openstack/keystone: Refactor shadow users and deprecate driver backend  https://review.openstack.org/32359622:15
openstackgerritRon De Rose proposed openstack/keystone: Shadow LDAP and custom driver users  https://review.openstack.org/32360222:15
jlkhttps://bugs.launchpad.net/keystone/+bug/155562922:21
openstackLaunchpad 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-keystone22:22
*** henrynash has quit IRC22:22
openstackgerritAndrew Laski proposed openstack/oslo.policy: Add equality operator to policy.RuleDefault  https://review.openstack.org/32124222:22
openstackgerritAndrew Laski proposed openstack/oslo.policy: Add helper scripts for generating policy info  https://review.openstack.org/32124322:22
openstackgerritAndrew Laski proposed openstack/oslo.policy: Add sample file generation script and helper methods  https://review.openstack.org/31424422:22
*** timcline has quit IRC22:22
*** timcline has joined #openstack-keystone22:23
jlknotmorgan: 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-configuration22:23
*** code-R has joined #openstack-keystone22:24
jlkwhere are teh in-tree keystone docs published?22:24
jlkah http://docs.openstack.org/developer/keystone/configuration.html22:25
*** doug-fish has joined #openstack-keystone22:27
*** timcline has quit IRC22:27
*** code-R has quit IRC22:29
*** doug-fis_ has quit IRC22:30
jlkstill 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 IRC22:41
*** KevinE has quit IRC22:42
*** wasmum has quit IRC22:46
*** doug-fish has quit IRC22:49
*** pumarani__ has quit IRC22:53
*** roxanaghe has quit IRC22:53
*** pushkaru has joined #openstack-keystone22:54
*** pumarani__ has joined #openstack-keystone22:56
*** pushkaru has quit IRC22:56
*** julim has joined #openstack-keystone22:56
*** henrynash has joined #openstack-keystone22:58
*** ChanServ sets mode: +v henrynash22:58
*** shaleh|away has quit IRC22:58
*** julim has quit IRC22:59
*** dan_nguyen has joined #openstack-keystone23:02
*** darrenc is now known as darrenc_afk23:03
*** pumarani__ has quit IRC23:05
*** doug-fish has joined #openstack-keystone23:06
*** doug-fish has quit IRC23:11
jlkIs the _member_ role a default role that exists, or do I have to explicitly create it?23:12
*** gordc has quit IRC23:22
*** darrenc_afk is now known as darrenc23:23
*** clenimar has quit IRC23:27
openstackgerrithenry-nash proposed openstack/keystone-specs: Relax the project name uniqueness constraints  https://review.openstack.org/31004823:35
*** furface has quit IRC23:43
openstackgerrithenry-nash proposed openstack/keystone-specs: Support hierarchical project naming  https://review.openstack.org/31860523:45
*** chlong has quit IRC23:53

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