Friday, 2014-07-25

jamielennoxi have the whole acaedmic paper on role delegation printed out from the guy we met at summit, i really need to read that cause i think it will nail that problem of role scoping00:00
gyeerole scoping is essential00:00
gyeeright now role definition is global and flat00:01
jamielennoxyep, i was going to wait for the hierarchical projects to happen before diving into that00:01
gyeehierarchical project needs role scoping00:02
* jamielennox seems keen to do anything to get back to server side00:02
jamielennoxso i guess the question is like this, if we were to split keystone such that the token authentication process was different to the CRUD process, which side would listing projects for a token fall on00:04
jamielennoxgiven it's current URL /users/{id}/projects i would say CRUD00:04
jamielennoxgiven my other blueprint of /auth/projects - i could go either way00:04
*** ncoghlan is now known as ncoghlan_afk00:05
jamielennoxif you say that the route is purely auth, then it makes sense to use the auth_url to get that data00:05
jamielennoxif you say that the route is CRUD related, then you should be using the service catalog to figure out which keystone endpoint to query that data from00:06
*** henrynash has quit IRC00:06
jamielennoxand given that the unscoped token should contain a catalog so that it can find that endpoint00:06
*** hrybacki_ has joined #openstack-keystone00:09
*** ncoghlan_afk is now known as ncoghlan00:10
gyeejamielennox, yeah, I don't have a good answer right now00:10
gyeestill thinking it through00:10
jamielennoxgyee: that's fine, no particular rush i think00:11
*** hrybacki has quit IRC00:12
gyeetoo many moving parts need to put together00:16
* gyee is drawing circles and squares on his board00:18
*** zzzeek has quit IRC00:18
*** gokrokve has quit IRC00:23
*** nkinder has joined #openstack-keystone00:24
*** gokrokve has joined #openstack-keystone00:25
*** gokrokve has quit IRC00:26
*** dims_ has joined #openstack-keystone00:27
*** hrybacki_ has quit IRC00:27
openstackgerritA change was merged to openstack/keystonemiddleware: Clean up openstack-common.conf  https://review.openstack.org/10400000:31
*** xianghuihui has joined #openstack-keystone00:34
*** xianghuihuihui has quit IRC00:34
stevemarjamielennox, i like your reply, 'muck around in the database, orrrr... use this much simple alternative'00:36
jamielennoxstevemar: :)00:36
openstackgerritBrant Knudson proposed a change to openstack/keystone: Fix revoking a scoped token from an unscoped token  https://review.openstack.org/10938900:37
openstackgerritBrant Knudson proposed a change to openstack/keystone: Add a test for revoking a scoped token from an unscoped  https://review.openstack.org/10912500:37
morganfainbergstevemar, 'this one weird alternative'00:38
morganfainbergstevemar, 'discovered by a stay-at-home mom'00:40
morganfainbergstevemar, no? :P00:40
stevemarmorganfainberg, 'doctors hate her!'00:43
jamielennoxergh, i thought all that revoked token model stuff in client was still in review,00:44
openstackgerritMorgan Fainberg proposed a change to openstack/keystone: Remove trust dependency on token_api  https://review.openstack.org/10946200:44
morganfainbergjamielennox, isn't it?00:46
morganfainbergjamielennox, *doesn't think he approved it*00:46
morganfainbergjamielennox, https://review.openstack.org/#/c/81166/00:46
morganfainberg?00:46
jamielennoxi was holding up the token model stuff because i didn't want another token abstraction format00:46
jamielennoxhttps://github.com/openstack/python-keystoneclient/blob/master/keystoneclient/contrib/revoke/model.py00:47
morganfainbergjamielennox, phsaw, it's not being used00:47
morganfainberg*yet*00:47
morganfainbergfix it :)00:47
jamielennoxi bet it was in that 0.10 release though00:48
morganfainbergmake it use accessinfo or something.00:48
morganfainbergjamielennox, meh,00:48
jamielennoxi had that patch00:48
morganfainbergjamielennox, quick get it fixed before 1.1100:48
dstanekmorganfainberg: i tried to read the token coversation, but i got lost. then i got bored00:48
morganfainbergdstanek, i don't think you're missing much at the moment, but there is a spec up that sortof outlines what ayoung-food wants00:49
*** cjellick_ has joined #openstack-keystone00:49
dstanekmorganfainberg: other than the cookie one?00:49
morganfainbergdstanek, that was the bulk of the convo00:50
morganfainbergdstanek, the other token convo from this morning was related but not directly00:50
jamielennoxi think the spec is kind of misleading00:50
morganfainbergdstanek, it was just a "what does an id-only token really look like, and how big is it"00:50
jamielennoxit mentions a whole lot of web stuff that is not relevant to us00:50
jamielennoxi think the whole spec can be summed up as "treat a scoped token like a SAML assertion, a service verifies the token, caches it, and issues a UUID to reference it. Further communications with that service use the UUID for auth"00:52
*** cjellick has quit IRC00:52
jamielennoxwhen you say that and stop talking about session cookies i think there is merit in it00:53
morganfainbergjamielennox, maybe00:53
morganfainbergjamielennox, i'm not really convinced though. i think it doesn't *Really* solve the issue that people are complaining about, it solves it... sortof, kindof, but probably wont convince people that it is better than uuid tokens00:54
jamielennox_if_ there is as much concern over token size as ayoung-food thinks00:54
*** cjellick_ has quit IRC00:54
morganfainbergjamielennox, because UUID tokens are small and still work, why would i fight with them.00:54
morganfainbergerm fight with PKI tokens ever00:54
morganfainbergand k2k is going to use SAML (cc stevemar ) if i remember correctly00:55
jamielennoxreally? interesting00:55
morganfainbergand then just issue a new token for the remote deployment00:55
* morganfainberg needs to go, gym time.00:55
stevemarmorganfainberg, thats the plan, we issue a *very* basic SAML token00:57
jamielennoxstevemar: why go SAML?00:57
dstaneki guess i just don't understand why the proposal is better than uuid tokens00:57
jamielennoxdstanek: i'm not backing it yet, but two things00:57
jamielennox1. uuid tokens are scoped to a service00:58
morganfainbergdstanek, thats kind of where i am at. we could make UUID tokens a lot better behind the scenes (there is some security things that could be done with cookies..but i think that is something a bit different and *not* really the conversation)00:58
stevemarjamiec, because it's standard, and we already have the other side of the equation done (the service provider side)00:58
stevemarjamielennox, ^00:58
stevemarjamiec, oops, ignore that00:58
jamielennox2. you aren't talking to keystone to do uuid validation. that cache is maintained per service, you still get the benefit of PKI for the setup00:58
jamielennoxgiven that auth_token caches UUID tokens i don't know how much of a benefit 2 is00:59
dstanekjamielennox: why can't uuid tokens grow those features? it just seems like we'll add another way to do the same thing...again00:59
jamielennoxdstanek: no idea, i've known about this for about an hour and i'm trying to reason it out through a hangover - just saying i think the spec confused more than helped01:01
dstanekjamielennox: definitely01:01
morganfainbergjamielennox, ah the good old hangover + programming01:01
dstanekjamielennox: should we be extra cautious with anything you push today?01:02
jamielennoxstevemar: so is it purely so that it can be pushed through mod_shib or similar because it seems like the best format for k2k would be our existing token structure01:02
jamielennoxopenstack 4th birthday party last night, the tab went further than expected01:02
jamielennoxeven my parties are work related :(01:02
stevemarjamielennox, at least at those parties it's someone else picking up the tab :D01:03
morganfainbergjamielennox, i haven't ended up hungover from a work party in many jobs01:03
morganfainbergjamielennox, and many years ago.01:03
* morganfainberg drinks a lot less these days (not that I drank a ton before)01:04
*** ncoghlan is now known as ncoghlan_afk01:08
dstaneki hate it when the mistake is so stupid and obvious that you don't see it01:10
*** ayoung-food is now known as ayoung01:11
ayoungmorganfainberg, if you replaced the random number key with a hash of the token in that spec, you'd basically have what we have now.01:12
ayoungI only went with the random number to guard against attacks.01:12
ayoungIf each service salted the tokens to make a hash differently, the tokens would not be replayable, but...that breaks down pretty quickly01:12
*** marcoemorais has quit IRC01:12
dstanekayoung: can't you just replay the random number?01:13
ayoungdstanek, yeah, but that is not what I meant by replayable01:14
ayoungI mean that if a user hands a token to nova, and then to glance, glance couldn't turn around and hand the token back to nova again01:14
dstanekayoung: what prevents that from working?01:18
ayoungdstanek, morganfainberg do you know if you can put something into memcached and refer to it with multiple keys, or do you end up having to duplicated it?01:22
openstackgerritBrant Knudson proposed a change to openstack/keystone: Fix revoking a scoped token from an unscoped token  https://review.openstack.org/10938901:25
openstackgerritBrant Knudson proposed a change to openstack/keystone: Add a test for revoking a scoped token from an unscoped  https://review.openstack.org/10912501:25
dstanekayoung: you will duplicate it01:29
ayoungdstanek, dang01:29
ayoungdstanek, it would be cool if the hash version and the "lets giveyou a randome number" version could both point at the same data01:30
*** gyee has quit IRC01:31
dstanekmemcached is an odd beast01:31
dstaneki've often wondered if we have a high eviction rate in a real environment01:32
ayoungdstanek, I guess we could continue to use the hash as the Session Cookie value.01:33
openstackgerritSteve Martinelli proposed a change to openstack/python-keystoneclient: Add an example of using v3 client with sessions  https://review.openstack.org/10883901:34
dstanekis there any trust between services? when we get a token from a user we want to make sure it's from them, but if the token comes from another service does that matter?01:35
ayoungdstanek, I'm trying to be able to make the answer to that "No."01:38
ayoungAs in "No trust between services"01:38
ayoungdstanek, Ideally, the user would determine what they want the remote service to do and say "you can do only this"  and that information would be encoded in the token01:39
dstanekayoung: why not? i don't think you are wrong, i'm just trying to understanc01:39
ayoungdstanek, there is a use case out there from the MOC (Massachussets Open Cloud) where they are trying to  create an exchange01:40
dstanekayoung: and have a well known set of workflows?01:40
ayoungso a user may decide to build a system where different parts come from different vendors01:40
ayoungand user keystone to authorizer it01:40
ayoungauthrize01:40
ayoungYeah, well known workflows, plus parsing the policy files01:41
dstanekayoung: for examle, we'd have a 'snapshot' workflow where nova gets a token that says 'you can make snapshots with this'01:41
dstanekand that in turn allows nova to use that token against glance because that is a part of the snapshot workflow01:41
dstanek...at least that's the way i've been trying to conceptualize this01:42
ayoungdstanek, that is what I meant when I wrote http://adam.younglogic.com/2013/07/a-vision-for-keystone/01:42
ayoungdstanek, in theory, if a user could look at the policy file, they could get a token which says which operations can be performed01:42
ayoungso they send it to nova, and nova sends it to glance.  Glance will only allow the operations that are in the token to be performed01:43
dstanekayoung: i don't think the policy file is the right place for that01:44
openstackgerritSteve Martinelli proposed a change to openstack/python-keystoneclient: Use oslosphinx to generate doc theme  https://review.openstack.org/10947001:44
stevemardstanek, ^01:44
ayoungdstanek, its necessary.  How else can you map from roles to operations?01:44
dstaneki wouldn't want the user to know how any of the operations are actually carried out - they would just know what they want01:44
*** topol has joined #openstack-keystone01:45
*** mberlin1 has joined #openstack-keystone01:45
dstanekayoung: i think the user knows they want a snapshot and somewhere in openstack the operator has confugured that to mean something01:46
*** mberlin has quit IRC01:46
ayoungdstanek, with the policy file it is unambiguous.  Anything else will be another system to be kept in sync01:46
dstanekayoung: but a policy file doesn't define what it means to create a snapshot01:47
ayoungdstanek, you may need more information, but with the policy file, if you know the operation, you know the roles you need to specify in the token to prove you have access to the operation01:48
ayoungdstanek, you may need more information, but I think you need the policy file at least01:49
*** xianghuihui has quit IRC01:52
*** xianghuihuihui has joined #openstack-keystone01:52
*** ncoghlan_afk is now known as ncoghlan01:56
openstackgerritSteve Martinelli proposed a change to openstack/keystone: remove static files from docs  https://review.openstack.org/10947201:57
*** amerine has quit IRC02:02
*** lcheng has quit IRC02:03
*** amerine has joined #openstack-keystone02:04
*** alex_xu has joined #openstack-keystone02:07
bknudsonapparently revocation events are also totally broken with v2 tokens also02:09
*** dolphm changes topic to "{"feature_proposal_freeze": "august 21", "feature_freeze": "september 4"}"02:09
dolphmbknudson: on the client side?02:10
bknudsondolphm: no, it's the server... and I guess the client would be broken too02:10
bknudsonif it was trying to compare against revocation events.02:10
dolphmbknudson: what about hte server is broken?02:11
bknudsonpp token['expires'] -> datetime.datetime(2014, 7, 25, 3, 8, 28, 521819)02:11
bknudsonpp token['expires'] -> datetime.datetime(2014, 7, 25, 3, 9, 58)02:11
bknudsonv2 tokens only have the expiration to the nearest second02:11
bknudsonI must be wrong about this because otherwise there'd have to be failures all over the place.02:13
dolphmbknudson: so assume worst case when you're enforcing (?)02:13
bknudsondolphm: I added a test here https://review.openstack.org/#/c/109125/4/keystone/tests/test_v3_auth.py02:13
bknudsonsee line 133802:13
bknudsonit does a DELETE of the token and then HEAD and the HEAD returns 200 rather than 40402:14
* dolphm is reading...02:14
bknudsondolphm: I think I can try the worst case... maybe the model could truncate the timestamp02:14
bknudsonand v3 could truncate the timestamp02:16
dolphmbknudson: are we marking pki tokens invalid in the backend still?02:17
bknudsondolphm: y, I think the default is to mark pki tokens invalid in the backend.02:17
bknudsonI think there's a switch for it.02:17
dolphmbknudson: i suspect that's why you're getting 4xx in the first test instead of 200s02:18
bknudsonnot just pki tokens but all tokens02:18
dolphmmaybe02:18
dolphmbknudson: right02:18
bknudsondolphm: these tests set that switch in their config_overrides()02:18
bknudsondolphm: well, I've got a fix for the issues with v3 tokens02:19
bknudsonand it's in the models.02:19
bknudsonso I've got that working02:19
bknudsondolphm: https://review.openstack.org/#/c/109389/02:20
*** gabriel-bezerra has quit IRC02:20
bknudsonI've just added a test for v2 tokens and that didn't work as expected either02:20
*** bobt has quit IRC02:20
*** gabriel-bezerra has joined #openstack-keystone02:21
dolphmbknudson: do we really need to differentiate between revoking a "domain_scope_id" and a "domain_id"?02:23
bknudsondolphm: the case that fails if you don't differentiate is if you revoke a domain-scoped token that was gotten from an unscoped token02:24
bknudsonand the domain-scoped token is in the user's scope02:25
bknudsonI was thinking this might be ok to not handle but then a horizon developer was in here saying that they plan to do exactly that... use domain-scoped tokens from unscoped tokens02:26
dolphm"use domain-scoped tokens from unscoped tokens" that sounds fair02:26
dolphmbknudson: but i don't follow "the domain-scoped token is in the user's scope"02:26
bknudsonoh, sorry, I should have said the domain-scoped token is in the user's domain.02:27
bknudsoni.e., the domain is scoped to the same domain as the user name02:27
bknudsonahh.02:27
bknudsonthe token is scoped to the same domain as the user name02:28
bknudsonwhich is what test_revoke_token_from_token does in https://review.openstack.org/#/c/109125/4/keystone/tests/test_v3_auth.py02:28
dolphmbknudson: what does the revocation event look like if you delete a domain-scoped token right now?02:30
dolphmbknudson: and what will it look like after your change?02:31
bknudsondolphm: if you take a look at https://review.openstack.org/#/c/109389/3/keystone/tests/test_revoke.py02:32
*** zzzeek has joined #openstack-keystone02:32
bknudsona domain-scoped token would have 'domain_scope_id=<domain_id>'02:32
bknudsondolphm: currently, a domain-scoped token revocation event doesn't mention the domain02:32
bknudsondolphm: sample with a project-scoped token02:32
dolphmsame*?02:33
bknudsondolphm: see this change: https://review.openstack.org/#/c/109389/3/keystone/contrib/revoke/core.py02:33
bknudsonin the original code, all it has is use_id and expires_at02:33
bknudsonit doesn't have the scope02:33
dolphmbknudson: a domain-scoped token not mentioning the domain is a serious bug02:33
dolphmthe revocation event for *02:33
dolphmbknudson: i'm still not convinced we need a new field in the model / event for the domain scope. deleting a domain won't have an expires_at, so lots of tokens will be nuked. deleting a domain-scoped token will have an expires_at and SHOULD have a domain_id and a user_id, so the effect is very narrow.02:35
dolphmbknudson: am i missing some corner case that makes overloading the field too ambiguous?02:35
bknudsondolphm: a token that you get from another token has the same expires_at02:36
*** harlowja is now known as harlowja_away02:37
bknudsonand the domain_id can match the user's domain02:37
dolphmif the client gets a project-scoped token, where the project's domain is A, expires at is B, and user is C... i'm sort of okay with that token being denied in response to a domain-scoped token being a deleted where the scope was A, expires at is B, and user is C.02:37
dolphmbknudson: so the unscoped token remains valid, but we might nuke too many "leafs" from that "tree" of tokens (the leafs being scoped tokens)02:38
bknudsondolphm: y, it might not be worth it to change the model02:38
bknudsonI think then we'd have to do assignment_domain_id only in the alternatives in https://review.openstack.org/#/c/109389/3/keystone/contrib/revoke/model.py02:39
bknudsonif there's an expiration time...02:39
bknudsonthis code is complicated02:39
jamielennoxdolphm: (not too interupt, but as you're here) between https://bugs.launchpad.net/python-keystoneclient/+bug/1347957 and https://review.openstack.org/#/c/101792/ we might need to do another client release02:40
uvirtbotLaunchpad bug 1347957 in python-keystoneclient "self-signed cert validation from env variable fails in 0.10" [High,Fix committed]02:40
dolphmjamielennox: sounds like 0.10.102:42
jamielennoxdolphm: yea, that's fine02:42
dolphmjamielennox: i'll do that right now02:43
ayoungdstanek, I'm being dumb.  Of course we use the hash of the token as the key, not a random number.  If you can guess that hash, you could have guessed the original token.  I'll update the spec with that,and it should make the implementation much friendlier02:44
jamielennoxdolphm: are you around to talk about the AUTH_INTERFACE thing? this is fairly late for you to be on irc02:45
dolphmjamielennox: yeah this is late :P i haven't read your email yet though :(02:45
jamielennoxdolphm: it got more rambling than i expected :) it was more because our IRC times generally only overlap on meeting days and i got called away last time02:47
dolphmjamielennox: https://launchpad.net/python-keystoneclient/+milestone/0.10.102:47
jamielennoxdolphm: thanks02:47
dolphmjamielennox: the push to pypi in queued in zuul02:47
dolphmjamielennox: no worries, let me read the email first02:48
*** dims_ has quit IRC02:48
dstanekayoung: that makes more sense to me02:49
dolphmjamielennox: so you have an example of session.get() in your email... if you were making a session-based call to the auth_url, what would that look like?02:50
*** zzzeek has quit IRC02:50
jamielennoxsession.get('/path/to', endpoint_type={'service_type': 'service', 'interface': keystoneclient.auth.AUTH_INTERFACE})02:51
jamielennoxi agree with bknudson that we shouldn't use a special 'auth' string there02:51
dolphmjamielennox: so a real call might be session.post('/auth/tokens', endpoint_type={'service_type': 'service', 'interface': keystoneclient.auth.AUTH_INTERFACE}) ?02:52
*** ncoghlan is now known as ncoghlan_afk02:53
jamielennoxcalling from within the auth plugin like that is a little bit meta - i'm not sure if that would work, but yes the concept is right02:53
dolphmjamielennox: well, the circular dependency between session and plugin is super odd to me02:54
dolphmjamielennox: why do plugins need to use the session again?02:55
jamielennoxprobably .get('/tenants', endpoint_filter={'service': 'identity', 'interface' keystoneclient.auth.AUTH_INTERFACE, 'version': 2}) is more appropriate02:55
jamielennoxdolphm: they need to actually talk to the server to do the auth exchange02:55
jamielennoxthey also do version discovery02:55
dolphmjamielennox: but version discovery is separate right?02:56
dolphmit's not built directly into the session object02:56
jamielennoxit's built into the plugin02:56
dolphmjamielennox: well then a plugin doesn't need the session to do discovery..?02:56
jamielennoxprocessing is built into the plugin via the discovery class, it still needs the session to do the actual fetch of the data02:57
*** xianghuihui has joined #openstack-keystone02:57
dolphmwhy does the discovery class need a session object?02:57
jamielennoxsession should be the only way to do HTTP calls, everything that talks over the network is provided the session object02:58
*** xianghuihuihui has quit IRC02:58
dolphma mantra is not a reason02:58
dolphmwhat is session providing that httplib2 can't provide?02:58
jamielennoxpicking up CA certs etc and transport details02:59
jamielennoxthey're generally provided once via CLI args or CONF or whatever and attached to the session02:59
openstackgerritwanghong proposed a change to openstack/keystone: add internal delete notification for endpoint  https://review.openstack.org/10832903:00
dolphmjamielennox: the only way this makes sense to me is if an auth plugin IS a session03:00
jamielennoxi'm not seeing how that would help03:02
dolphmjamielennox: it helps my mental model to avoid the circular dependency and maintain the session.get(path, endpoint_filter) API03:04
jamielennoxso there's not an actual dependency there, session is provided to the plugin as an argument03:04
dolphmjamielennox: can you explain why this would be an insufficient substitute? .get('/tenants', endpoint_filter={'service_type': 'identity', 'interface': 'public', 'version': 2})03:05
dolphmjamielennox: yeah, that's hiding a circular dependency03:05
jamielennoxbecause we don't have a catalog to provide a 'public' interface in an unscoped token03:06
jamielennoxif you look at this review: https://review.openstack.org/#/c/104771/10 which is the dependent of the AUTH_INTERFACE one03:07
jamielennoxthe main reason i need the AUTH_INTERFACE is not because i ever actually want to have the plugin look itself up03:08
jamielennoxit's because in situations where you have an unscoped token i have to send requests to the auth_url03:08
dolphmjamielennox: why can't your magic just be "hey, i don't have a catalog, but i know that the auth_url is a public identity endpoint, so i'll just return that"03:09
openstackgerritwanghong proposed a change to openstack/keystone: add --rebuild option for ssl/pki_setup  https://review.openstack.org/8820703:09
jamielennoxhave the plugin return auth_url for 'public' in the case of an unscoped token - sure that would work for this, but take the other functions who want to send requests to a 'public' interface, how do they know if they are really using public or they have an unscoped token and the plugin is faking it for them03:11
jamielennoxeg i issue a request for GET /users against the public interface, i should get an error if i am using an unscoped token - if the plugin faked it for me it would mostly work03:12
dolphmjamielennox: why does the caller need to care? it wants a public identity endpoint and shouldnt' have to know the internal state of the plugin03:13
dolphmif i called GET /users and i got a 401, that's my fault, not the plugin's fault03:14
jamielennoxa scoped vs unscoped token is something you always have to care about because a lot of things just don't work with unscoped tokens03:14
dolphmjamielennox: correct - and it's MY fault, not the plugins fault in that scenario03:14
dolphmjamielennox: so allow me to shoot myself in the foot03:15
jamielennoxthe number of calls that are allowed to go to the auth_url is really small and limited to within keystoneclient, exposing that public hack seems like it would cause problems when we could just handle it in the few places where we do actually deal with unscoped tokens03:15
dolphmjamielennox: what problems?03:16
jamielennoxwell as an example i would need to match that interface == public and that endpoint_type == 'identity' there's nothing to say that the deployment may be using a different endpoint_type name03:17
jamielennox(weak argument recognized)03:17
dolphmjamielennox: especially when service='identity', interface='public' is primarily for authentication03:18
dolphmjamielennox: if i wanted GET /users i should be asking for interface='admin', technically03:18
jamielennoxi don't know, it seems more appropriate that if an endpoint is not available (in the case of public) that we should just tell people that there's nothing to send to rather than make a call that's guaranteed to fail03:18
jamielennoxonly in the v2 API, for the v3 API i'd really like to make the public interface the standard03:19
dolphmjamielennox: then the URLs should be the same; the client should still ask for the appropriate endpoint03:19
dolphmjamielennox: i'd also be happy if the client returned the public endpoint for something if the user asked for an admin endpoint and none was available03:20
dolphmbut that's another discussion03:20
jamielennoxright, but in the current situation where you would try to do a v3 operation with an unscoped token the client can stop you, if we return the auth_url then everything would be attempted against taht url03:21
dolphmjamielennox: why would the client suppose to know what the remote policy looks like?03:23
dolphmjamielennox: my policy in my personal cloud might be "is_admin": "user_id=1" or whatever03:24
jamielennoxpoint, but then you've made keystoneclient different to all the other clients03:25
openstackgerritayoung proposed a change to openstack/keystone-specs: Cookie for tokens  https://review.openstack.org/10929503:25
dolphmthe other clients should behave the same way03:25
dolphm*let me shoot myself in the foot*03:25
ayoungmorganfainberg, take a look at the updated version.  I think it will make more sense.  Thanks for the feedback.03:25
jamielennoxbut if you want to go down that route what if in my deployment i've called the keystone server type 'users' or something, returning auth_url if interface=='public' and service_type == 'identity' wont work03:26
jamielennoxis that the something else you can configure?03:26
jamielennoxi'm not sure here if you really care about the distinction or are feeling out the idea03:27
*** alex_xu has quit IRC03:30
*** slogan has joined #openstack-keystone03:31
dolphmjamielennox: the service types should be well known constants03:34
openstackgerritA change was merged to openstack/keystone: Move token persistence classes to token.persistence module  https://review.openstack.org/10756103:35
morganfainbergdolphm, ^ yay03:36
morganfainbergdolphm, that one was kind of annoying to rebase03:37
*** ajayaa has quit IRC03:38
dolphmmorganfainberg: the token model one is basically what's in the client? except one object03:38
dolphmone class*03:38
morganfainbergdolphm, yeah, it's a stop-gap to get the code in03:38
*** slogan has quit IRC03:38
morganfainbergdolphm, once we get things solidified i expect to circle back and work with jamielennox to make both ksc and keystone use the same model03:38
morganfainbergdolphm, and make it better™, i just was worried i wouldn't get the non-persistent stuff done without the start of a model, and so i cribbed most of the work from ksc03:39
morganfainbergand it's simple enough to not make me worry about introducing something crazy / broken03:39
dolphmmorganfainberg: i have a -1 on that so far, but still reviewing03:40
morganfainbergdolphm, sure, i'm fine with it needing some work.03:40
morganfainbergdolphm, i actually expect it to need some work during review, but it is a workable first pass.03:40
morganfainberg(e.g. unblocked me so i could get the other work moving)03:41
jamielennoxdolphm: i'm not convinced that the inconsistency here is worth it to protect the 3 calls that actually use the auth_url (outside of actually authenticating)03:41
jamielennoxdolphm: however i'm hungry and so if you want to override let me know and i'll do it that way03:42
jamielennoxs/override/if you prefer03:42
dolphmjamielennox: the UX looks terrible to me03:42
jamielennoxit's a very specific case where it matters03:43
jamielennoxand hopefully we'll get a catalog in an unscoped token soon - so even then it'll never get called03:43
dolphmjamielennox: and sort of core for keystone03:43
jamielennoxi would never expect to see it used outside of keystoneclient03:44
jamielennoxanyway going for lunch, it's nearly 2 already03:46
*** alex_xu has joined #openstack-keystone03:46
morganfainbergayoung, the spec is a bit clearer in proposal now. i'm still not convinced, but we can keep discussing this.03:52
ayoungmorganfainberg, I was being overly paranoid with the UUID approach03:53
ayoungthis at least lets the service set the hash algorithm, which solves the MD5 issue03:53
morganfainbergayoung, sure.03:53
*** alex_xu has quit IRC03:53
ayoungBut, as I said, it was more to get it recorded and discussed than anything I'm planning on implementing yet03:54
*** ayoung has left #openstack-keystone03:54
morganfainbergayoung, ++ and i think there is still a good amount to discuss, but i have a *clearer* idea now.03:54
morganfainbergannnnnnnd he's gone03:54
stevemarjamielennox, thx for reviewing dtroyer's osc patch03:55
morganfainbergdolphm, self.get('project', {}).get('domain', {}).get('name') how does that get us a empty dict instead of a string or a None?03:56
morganfainbergdolphm, /me is likely just missing it03:57
dolphmmorganfainberg: that was .project_domain_id?03:57
morganfainbergproject_domain_name03:57
dolphmmorganfainberg: oh; it will return None. nevermind on that one!03:57
dolphmmorganfainberg: hmm03:58
dolphmmorganfainberg: what was the review link03:58
morganfainbergdolphm, ok just making sure i wasn't missing something super obvious, cause... it's been known to happen from time to time :)03:58
morganfainberghttps://review.openstack.org/#/c/106917/9/keystone/models/token_model.py03:58
dolphmmorganfainberg: that was the reason for my -1; changed to a +1... i'd still prefer it to be much less defensive04:01
morganfainbergsome of that defensive is because the token could be project scoped04:01
morganfainbergor domain scoped, or not scoped04:02
morganfainbergshould we always check .project_scoped before looking at project_id? (i'm ok with that)04:02
dolphmmorganfainberg: i'd like the explicitness of that04:02
morganfainbergsure. done in next patch.04:02
dolphmmorganfainberg: and if it was domain scoped, and some expected attribute wasn' there, that deserves a 50004:02
morganfainbergworks for me :)04:03
morganfainbergand the auth_context is going to be replaced, i just want to make damn sure i'm not breaking something first.04:03
dolphmalso note that wasn' is totally a word04:03
morganfainbergdolphm, dude, wasn' sounds like something from texas, i read it as a word!04:04
dolphmmorganfainberg: as a member of texas, i can confirm04:04
dolphmmorganfainberg: fyi, right before you got on, i released https://launchpad.net/python-keystoneclient/+milestone/0.10.104:05
morganfainbergso i figure the steps are: get everything using .validate_token, then fix "auth_context" to use the token_model, and migrate away from .validate_token as appropriate.04:05
* morganfainberg is being super paranoid mucking with token stuff.04:06
morganfainbergif you think it's better to fix auth_context first... i can try and do that.04:06
*** alex_xu has joined #openstack-keystone04:06
* morganfainberg isn't being picky, just paranoid :)04:07
morganfainbergdolphm, ++ woot on password logging fix!04:07
dolphmmorganfainberg: the auth_context change is just a nice to have04:08
dolphmthe patch would probably be too big if you did that at once04:08
morganfainbergdolphm, oh it would need to be a follow-on.04:08
morganfainbergdolphm, for sure04:08
dolphmmorganfainberg: i just read the "and then i hacked the DB and the JSON response was not as expected" bug. nice work!04:13
morganfainbergLOL04:14
morganfainbergdolphm, which bug is that?04:14
dolphmmorganfainberg: i don't want to point fingers. extra={"key": "value"} but only "key": "value" appeared in JSON04:14
morganfainbergoh hahaha04:15
morganfainberg*snicker*04:15
* dolphm sleep04:16
*** ncoghlan_afk is now known as ncoghlan04:19
openstackgerritSteve Martinelli proposed a change to openstack/keystone: Add a URL field to region table  https://review.openstack.org/10693504:19
morganfainbergstevemar, i shall bug you tomorrow about tokens.04:20
morganfainbergstevemar, and federation... and special case tokens04:20
morganfainbergstevemar, have a related bug report to the special case tokens: https://bugs.launchpad.net/keystonemiddleware/+bug/134682004:20
stevemarmorganfainberg, coolio04:20
uvirtbotLaunchpad bug 1346820 in keystonemiddleware "Middeware auth_token fails with scoped federated saml token" [Undecided,New]04:20
stevemarbah humbug04:21
morganfainbergstevemar, it's related to the fact federated tokens aren't "really" the same as tokens. they are missing some important data.. like... domain04:21
openstackgerritSteve Martinelli proposed a change to openstack/keystone: Add a URL field to region table  https://review.openstack.org/10693504:21
stevemarmorganfainberg, correct04:21
stevemarthe scope part should be the same, domain and project04:21
stevemarmorganfainberg, but i guess you are talking about user portion?04:22
morganfainbergstevemar, that means 3 things: breaks auth_token, breaks revocation events, is standing in the way of non-persistent tokens04:22
jamielennoxwhy doesn't it have a domain name?04:22
morganfainbergstevemar, it has *no* domain in the user section04:22
morganfainbergyeah04:22
jamielennoxoh user section04:22
stevemarjamielennox, because the user doesn't exist in keystone04:22
morganfainbergstevemar, anyway we shall need to discuss how to solve this tomorrow :)04:22
stevemaralrighty04:22
morganfainbergstevemar, i'm sure we can figure something out04:22
stevemari'll be here!04:23
dstanekwow..late night chatter!04:34
dstaneki didn't see any examples of print error messages when using the bin/keystone-* scripts - is there some guidance there?04:34
*** jamielennox is now known as jamielennox|away04:35
dstanekspecifically my comment about the print here: https://review.openstack.org/#/c/88207/5/keystone/common/openssl.py04:35
*** slogan has joined #openstack-keystone04:46
*** ajayaa has joined #openstack-keystone05:02
*** slogan has quit IRC05:04
*** ncoghlan is now known as ncoghlan_afk05:09
*** topol has quit IRC05:16
*** ncoghlan has joined #openstack-keystone05:23
*** jamielennox|away has quit IRC05:23
*** ncoghlan_ has joined #openstack-keystone05:23
*** jamielennox|away has joined #openstack-keystone05:24
*** stevemar has quit IRC05:26
*** ncoghlan has quit IRC05:27
*** ncoghlan_afk has quit IRC05:27
*** vb-awe has joined #openstack-keystone05:34
*** vb-awe has left #openstack-keystone05:34
*** vb-awe has joined #openstack-keystone05:35
*** vb-awe has left #openstack-keystone05:35
*** mberlin1 has quit IRC05:45
*** k4n0 has joined #openstack-keystone05:56
*** chandankumar has joined #openstack-keystone05:57
openstackgerritOpenStack Proposal Bot proposed a change to openstack/keystone: Imported Translations from Transifex  https://review.openstack.org/10693906:06
*** ukalifon has joined #openstack-keystone06:06
*** tomoiaga has joined #openstack-keystone06:09
*** slogan has joined #openstack-keystone06:34
tomoiagahey, finally the session object is in nova, now on to refactoring code, thanks jamielennox !06:43
*** xianghuihui has quit IRC06:45
*** xianghuihui has joined #openstack-keystone06:48
openstackgerritwanghong proposed a change to openstack/keystone: Clean up EP-Filter after delete project/endpoint  https://review.openstack.org/10950706:54
*** ukalifon has quit IRC06:56
openstackgerritAlexey Miroshkin proposed a change to openstack/keystone: Check url is in the 'self' link in list responses  https://review.openstack.org/10929007:04
*** ajayaa has quit IRC07:07
*** jamielennox|away has quit IRC07:16
*** ajayaa has joined #openstack-keystone07:20
*** gabriel-bezerra has quit IRC07:20
*** gabriel-bezerra has joined #openstack-keystone07:21
*** ncoghlan_ has quit IRC07:30
*** vysakh has joined #openstack-keystone07:57
vysakhhi.. any one to help me here?07:57
vysakhI have raised a question here (https://ask.openstack.org/en/users/7069/vysakhv90/?sort=inbox&section=forum)07:58
*** henrynash has joined #openstack-keystone07:59
*** gabriel-bezerra has quit IRC08:27
*** gabriel-bezerra has joined #openstack-keystone08:28
tomoiagavysakh: the link to the question is a link to your messages inbox08:30
*** ajayaa has quit IRC08:31
*** alex_xu has quit IRC08:34
*** mberlin has joined #openstack-keystone08:35
*** ajayaa has joined #openstack-keystone08:44
*** slogan has quit IRC08:46
*** oomichi has quit IRC08:49
vysakhsorry ..08:53
vysakhhttps://ask.openstack.org/en/question/43523/dashboard-not-displaying-network-and-object-store/08:53
openstackgerritAlexey Miroshkin proposed a change to openstack/keystone: Check url is in the 'self' link in list responses  https://review.openstack.org/10929009:02
tomoiagavysakh: can you confirm that the services are actually running ? (do you have the endpoints in keystone endpoint-list). I don't remember exactly if Horizon has a mechanism to auto discover neutron for example, if not, you should probably enable it in local_settings (assuming neutron is actually seen in the endpoint lists and is running)09:03
*** xianghuihui has quit IRC09:04
vysakhIf the services are running how it can show? Any example?09:05
tomoiagavysakh: can you run: neutron net-list for example ?09:05
*** ajayaa has quit IRC09:06
vysakhpublicURL endpoint for network service not found !!!09:06
tomoiagavysakh: you also need to add the endpoints for it. However, did you install neutron, or just ran devstack and you assume it installed neutron for you ?09:08
vysakhI have installed devstack first and then did "keystone service-create \--name=neutron \--type=network \--description="Network Service""09:09
*** xianghuihui has joined #openstack-keystone09:10
tomoiagavysakh: the keystone service-create only adds a record (just a buch of text) to a database (the one you see in service-list), it doesn't actually install neutron. For example you can service-create —name=whatever —type=nothing —description="some description" and it will work since all it does is to add some records to the database09:11
tomoiagavysakh: look at https://github.com/openstack-dev/devstack/blob/master/README.md (look for Neutron and ML2 if you want to enable that extension)09:13
tomoiagavysakh: most likely the same for the other service you mentioned09:13
tomoiagavysakh: devstack needs to know you want to install neutron in order to install the requires packages and start the daemons on your server09:13
tomoiagavysakh: devstack will also create the services and endpoints for you, so there is no need to run service-create separately09:14
*** mberlin has quit IRC09:15
*** mberlin has joined #openstack-keystone09:15
*** ajayaa has joined #openstack-keystone09:17
vysakhOkay.. Thanks tomoiaga.. Let me check...09:20
*** ajayaa has quit IRC09:28
*** ajayaa has joined #openstack-keystone09:29
openstackgerritwanghong proposed a change to openstack/keystone: Clean up EP-Filter after delete project/endpoint  https://review.openstack.org/10950709:46
*** bvandenh has joined #openstack-keystone09:55
openstackgerritMarcos Fermín Lobo proposed a change to openstack/keystone: Group related methods for LDAP backend  https://review.openstack.org/10224410:05
*** xianghuihuihui has joined #openstack-keystone10:08
*** xianghuihui has quit IRC10:09
*** Dafna is now known as Dafna_away10:13
openstackgerritAlexey Miroshkin proposed a change to openstack/keystone: Check url is in the 'self' link in list responses  https://review.openstack.org/10929010:20
openstackgerritA change was merged to openstack/keystone: add internal delete notification for endpoint  https://review.openstack.org/10832910:23
*** dims has joined #openstack-keystone10:24
*** amerine has quit IRC10:48
*** xianghuihuihui has quit IRC10:48
*** slogan has joined #openstack-keystone10:53
*** amerine has joined #openstack-keystone10:55
*** ajayaa has quit IRC10:57
*** topol has joined #openstack-keystone10:57
*** Dafna_away is now known as Dafna11:03
*** fish_ has quit IRC11:07
*** fish_ has joined #openstack-keystone11:07
*** xianghui has joined #openstack-keystone11:08
*** slogan has quit IRC11:09
*** ajayaa has joined #openstack-keystone11:10
*** cjellick has joined #openstack-keystone11:15
*** cjellick has quit IRC11:16
*** cjellick has joined #openstack-keystone11:17
openstackgerritAlexey Miroshkin proposed a change to openstack/keystone: Check url is in the 'self' link in list responses  https://review.openstack.org/10929011:23
*** xianghuihui has joined #openstack-keystone11:37
*** xianghui has quit IRC11:37
*** k4n0 has quit IRC11:38
*** diegows has quit IRC11:54
*** chandan_kumar has joined #openstack-keystone12:09
*** chandan_kumar has quit IRC12:09
*** diegows has joined #openstack-keystone12:20
*** miqui has joined #openstack-keystone12:22
*** dims has quit IRC12:23
*** dims has joined #openstack-keystone12:25
*** ajayaa has quit IRC12:33
*** bvandenh has quit IRC12:33
*** vysakh has quit IRC12:36
raildohenrynash: ping12:44
*** bknudson has quit IRC12:49
henrynashrailod: hi12:50
*** russellb is now known as rustlebee12:50
henrynashraildo: hi12:51
*** rwsu has joined #openstack-keystone12:56
*** joesavak has joined #openstack-keystone12:58
*** stevemar has joined #openstack-keystone12:59
*** ayoung has joined #openstack-keystone13:03
raildohenrynash:  ayoung answered your questions in the spec https://review.openstack.org/#/c/101017/13:05
*** bvandenh has joined #openstack-keystone13:06
henrynashraildo: ok, will look in a bit, thanks13:06
*** bknudson has joined #openstack-keystone13:07
*** zzzeek has joined #openstack-keystone13:11
*** radez_g0n3 is now known as radez13:12
*** lbragstad has joined #openstack-keystone13:18
openstackgerritMarcos Fermín Lobo proposed a change to openstack/python-keystoneclient: Initial kerberos plugin implementation.  https://review.openstack.org/7497413:27
ayoungraildo, I'd like to see my comment (cleaned up) included into the body of the spec, to clarify that point13:30
raildoayoung: OK, I'll replace the section that I speak about users for your comments. Thank you :)13:32
openstackgerritA change was merged to openstack/python-keystoneclient: Calculate a suitable column width for positional arguments  https://review.openstack.org/9787313:37
openstackgerritMarek Denis proposed a change to openstack/python-keystoneclient: Overwrite get_endpoint in Saml2UnscopedToken.  https://review.openstack.org/10957513:42
*** bvandenh has quit IRC13:43
*** Chicago has joined #openstack-keystone13:49
openstackgerritMarek Denis proposed a change to openstack/python-keystoneclient: Overwrite get_endpoint in Saml2UnscopedToken.  https://review.openstack.org/10957513:50
openstackgerritMarek Denis proposed a change to openstack/python-keystoneclient: List federated projects and domains  https://review.openstack.org/10739313:50
openstackgerritMarek Denis proposed a change to openstack/python-keystoneclient: Add the 'auth' interface type  https://review.openstack.org/10473413:50
*** ukalifon1 has joined #openstack-keystone13:51
*** gokrokve has joined #openstack-keystone14:01
*** jasondotstar has joined #openstack-keystone14:02
openstackgerritMarek Denis proposed a change to openstack/python-keystoneclient: Overwrite get_endpoint in Saml2UnscopedToken.  https://review.openstack.org/10957514:03
openstackgerritMarcos Fermín Lobo proposed a change to openstack/keystone: Basic-Auth middleware  https://review.openstack.org/9213714:04
*** chandan_kumar has joined #openstack-keystone14:07
openstackgerritMarek Denis proposed a change to openstack/python-keystoneclient: List federated projects and domains  https://review.openstack.org/10739314:08
*** chandan_kumar has quit IRC14:10
*** bvandenh has joined #openstack-keystone14:10
openstackgerritBrant Knudson proposed a change to openstack/keystone: Add test for revoking a scoped v2 token  https://review.openstack.org/10960214:15
*** bvandenh has quit IRC14:15
*** david-lyle has joined #openstack-keystone14:18
*** chandankumar has quit IRC14:21
*** hrybacki has joined #openstack-keystone14:32
*** tomoiaga has quit IRC14:33
ayoungbknudson, you are making a lot of changes to the revocation events code, but we really need them to happen in the client, not server, versions of model.py14:35
bknudsonayoung: it's easier for me to make them in the server for now14:35
ayoungbknudson, but it will lead to regressions in the client14:35
ayoungwhen the server uses the client code14:36
ayoungwithout that, the revocation events are useless14:36
bknudsonI'll transfer the changes to the client14:36
ayoungas the remote machines cannot  use them14:36
ayoungbknudson, thanks, and lets get the client review moving14:36
ayoungits been malingering for 4 months now14:36
ayounghttps://review.openstack.org/#/c/81166/14:36
bknudsonas far as I can tell revocation events are broken as is14:37
ayoungbknudson, so lets fix them in once place14:37
ayoungand thatplace needs to be the client code14:38
bknudsonif it requires changes to the model and how they're stored in the database then that will need to be in the server14:38
ayoungwe can make the server use the client code and only deal with it in one location, but trying to keep the fixes straight is going to make things really hard14:38
bknudsonthe server can't use the client code for its database model14:39
ayoungI wish we could have done the work in the client in the first place, but there really was no way to do it without the server side recording14:39
ayoungits a tough problem14:39
ayoungI don't think, though, that we need to change the database for anything I've seen yet.14:39
bknudsonwell, I really don't understand this issue with revoking a v2 scoped token... there's a test with a v2 unscoped token that works fine14:40
openstackgerritMarcos Fermín Lobo proposed a change to openstack/keystone: Initial kerberos plugin implementation.  https://review.openstack.org/7431714:40
bknudsonI also think you're right that the database table doesn't have to change... it was just easier to do that than figure out how to build the tree differently14:40
marekdBug for keystone/doc/* should be filed under Keystone or some other project?14:43
bknudsonmarekd: I think people are wondering what keystone/doc/* is?14:46
marekdbknudson: https://github.com/openstack/keystone/tree/master/doc14:46
marekddocs for keystone.14:47
bknudsonmarekd: y, that would be filed in keystone14:47
marekdbknudson: thank you.14:47
bknudsonp "%s > %s == %s" % (leaf['issued_before'], token_data['issued_at'], leaf['issued_before'] > token_data['issued_at'])14:49
bknudsonunscoped: '2014-07-25 14:18:42.918527 > 2014-07-25 14:18:41.311999 == True'14:49
bknudsonscoped: '2014-07-25 14:27:12.459644 > 2014-07-25 14:27:17.077212 == False'14:49
bknudsonI don't get it.14:49
*** lbragstad has quit IRC14:52
openstackgerritMarek Denis proposed a change to openstack/keystone: Add X-Auth-Token header in federation examples  https://review.openstack.org/10961414:53
*** lbragstad has joined #openstack-keystone14:55
*** david-ly_ has joined #openstack-keystone14:58
bknudsonhmmm.. if the token is checked before it's revoked then things work... wonder why that would make a difference?14:59
bknudsoncaching?14:59
*** david-lyle has quit IRC14:59
openstackgerritRaildo Mascena de Sousa Filho proposed a change to openstack/keystone-specs: Hierarchical Multitenacy  https://review.openstack.org/10101715:04
*** thedodd has joined #openstack-keystone15:05
*** doddstack has joined #openstack-keystone15:07
*** thedodd has quit IRC15:10
*** topol has quit IRC15:12
*** gokrokve_ has joined #openstack-keystone15:12
*** gokrokve has quit IRC15:14
dolphmayoung: keystoneclient.common.cms needs to be refactored and documented. badly.15:18
ayoungdolphm, in what ways does it need to be refactored?15:20
dolphmayoung: it's incomprehensible undocumented mess of spaghetti, so basically in every way that you can use the term "refactor"15:20
*** chandankumar has joined #openstack-keystone15:21
ayoungdolphm, refactor implies not changing the external interfaces.  A lot of the functions there are things that I want to go away, but had to leave because they are external:  called by both the keystone and keystonclient code15:22
dolphmayoung: you can't even tell what the external interfaces ARE15:22
*** hrybacki has quit IRC15:22
ayoungdolphm, there is very little in there that is not called externally15:23
ayoungmost of it is called from auth_token middleware15:23
ayoungonly the signing code is called from Keystone server15:23
dolphmayoung: well very much of it should be documented as such15:23
*** radez is now known as radez_g0n315:23
stevemarlbragstad, ping15:26
ayoungdolphm, probably a good start would be grouping together the functions that are for the old, pki/asn1 format that I would like to deprecate.15:26
ayoungdef token_to_cms(signed_text):  and def cms_to_token(cms_text):15:27
ayoungand there was some ugliness added by the py33 requirenments to deal with the differences of string handling15:28
lbragstadstevemar: 64 bytes from ord08s12-in-f18.1e100.net (74.125.225.18): icmp_req=1 ttl=63 time=38.0 ms15:28
stevemarhue hue15:29
stevemarlbragstad, question for you abt notifications15:29
lbragstadsure15:29
stevemarlbragstad, is there anyway I can get the user id of the person who issued the request to delete a project?15:29
stevemarthe resource is always in the payload15:29
lbragstadstevemar: not currently, no15:30
lbragstadI feel like that falls under the pycadf standard though15:30
*** stevemar has quit IRC15:30
*** jasondotstar has quit IRC15:30
ayoungdolphm, meh,  I don't see anything radically changeable, though.15:31
*** stevemar has joined #openstack-keystone15:31
ayoungWe can drop the asn1 stuff in a release or two, and the two functions I listed above15:31
lbragstadstevemar: what's your use case?15:31
dolphmayoung: how about method names, variable names, documentation, and module organization?15:31
stevemarlbragstad, https://review.openstack.org/#/c/109616/1/ceilometer/identity/notifications.py15:32
*** chandankumar has quit IRC15:33
*** erecio has joined #openstack-keystone15:34
lbragstadstevemar: ok, where do you want to store that information?15:35
lbragstadstevemar: you'll end up with something like 'identity.project.deleted', right?15:36
lbragstadstevemar: but you want the user_id injected into the from_notification part?15:38
*** erecio has quit IRC15:38
dstaneki didn't see any examples of print error messages when using the bin/keystone-* scripts - is there some guidance there?15:39
stevemarlbragstad, that's supposed to be the issuing user_id15:39
dstanekspecifically my comment about the print here: https://review.openstack.org/#/c/88207/5/keystone/common/openssl.py15:39
*** amerine has quit IRC15:40
lbragstadstevemar: so in Project, you want to call _Base.process_notifications(..., user_id=<person who issued the delete event>, ...) right?15:40
morganfainbergoh new openid thing for lp/ubuntu15:42
morganfainbergweird15:42
*** gyee has joined #openstack-keystone15:42
lbragstadstevemar: I would think you'd have to find a seam in here https://github.com/openstack/keystone/blob/2d3d00e29c7e55b5eef3e37372aae309cf93b22c/keystone/notifications.py#L71-L9015:44
lbragstadto see if you could pull out15:45
lbragstadof the request that would give that kind of information, and include it in the notifcation15:45
lbragstadnotification*15:45
*** jasondotstar has joined #openstack-keystone15:48
*** hrybacki has joined #openstack-keystone15:51
dstanekmy next-review count keeps going up. lots of stuff happening the last few days15:51
*** Chicago has quit IRC15:51
openstackgerritDiane Fleming proposed a change to openstack/identity-api: Add create, update, and delete user to admin API v2.0  https://review.openstack.org/10825915:55
*** dims has quit IRC15:56
*** jasondotstar has quit IRC15:57
lbragstaddstanek: ++15:57
*** jasondotstar has joined #openstack-keystone15:57
*** ayoung has quit IRC15:58
*** elmiko has joined #openstack-keystone15:58
elmikohi folks, is there an easier way to get a list of role names for a client than iterating through the role from the RoleManager and pulling the names out?15:59
dolphmelmiko: something easier than [r['name'] for r in c.roles.list()] ?16:00
elmikodolphm: agreed that is easy, i just want to make sure i don't put something in that might break. so i'm double checking :)16:00
dolphmelmiko: nope, that shouldn't break!16:01
elmikoawesome :)16:01
dolphmelmiko: every role is guaranteed a name, etc16:01
elmikook16:01
elmikoi was mainly concerned that i might be creating code that digs too deep into the RoleManager structure16:01
dolphmoslo meeting is starting; i added the move of pycadf to keystone to the agenda if anyone wants to discuss (cc- bknudson morganfainberg lbragstad topol )16:02
dolphmelmiko: taht's all public API, so you're very much safe!16:02
lbragstaddolphm: openstack-meeting?16:03
elmikoare there any plans to allow TrustManager.create to take the list from RoleManager.list() instead of just names?16:03
bknudsonlbragstad: meeting-alt16:03
dolphmlbragstad: #openstack-meeting-alt actually16:03
elmikoi'll check back later16:03
*** topol has joined #openstack-keystone16:05
lbragstadstevemar: there isn't much in assignment.core:Manager.delete_project for grabbing the user_id16:07
*** dims has joined #openstack-keystone16:07
stevemarlbragstad, i was hoping it's in the context16:10
lbragstadstevemar: checking something else quick16:10
lbragstadManager in assignment.core doens't have a context16:10
dolphmbknudson: we both just made the exact same comment https://review.openstack.org/#/c/108935/1/keystone/tests/test_sql_upgrade.py16:12
*** ayoung has joined #openstack-keystone16:13
bknudsondolphm: that's great!16:13
lbragstadstevemar: you have the token16:19
lbragstadin the controller layer16:19
lbragstadstevemar: a lot of that info isn't carried into the Manager layer, so you'll probably have to do it there.16:20
stevemarlbragstad, blahhh16:21
*** radez_g0n3 is now known as radez16:31
*** amerine has joined #openstack-keystone16:36
*** richm has joined #openstack-keystone16:42
*** slogan has joined #openstack-keystone16:46
openstackgerritSergey Nuzhdin proposed a change to openstack/keystone: Fix invalid self link in get access token  https://review.openstack.org/10965016:46
openstackgerritMorgan Fainberg proposed a change to openstack/keystone: Add the new Keystone TokenModel  https://review.openstack.org/10691716:50
openstackgerritMorgan Fainberg proposed a change to openstack/keystone: Make token_provider_api contain token persistence  https://review.openstack.org/10904116:51
*** lbragstad has quit IRC16:51
openstackgerritMorgan Fainberg proposed a change to openstack/keystone: Remove assignment controller dependency on token_api  https://review.openstack.org/10916216:51
openstackgerritMorgan Fainberg proposed a change to openstack/keystone: Expose token revocation list via token_provider_api  https://review.openstack.org/10917016:51
openstackgerritMorgan Fainberg proposed a change to openstack/keystone: Remove ec2 contrib dependency on token_api  https://review.openstack.org/10917316:51
openstackgerritMorgan Fainberg proposed a change to openstack/keystone: Remove trust dependency on token_api  https://review.openstack.org/10946216:51
morganfainbergdolphm, ^ that should be a little less defensive now.16:52
morganfainberg(the token model one)16:52
openstackgerritMorgan Fainberg proposed a change to openstack/keystone: Sample config update  https://review.openstack.org/10965716:57
*** gokrokve has joined #openstack-keystone16:59
*** gokrokve_ has quit IRC17:02
*** gokrokve has quit IRC17:03
*** browne has joined #openstack-keystone17:04
brownequestion, is domain_specific_driver support in icehouse?  the documentation indicates Juno, but the keystone.conf.sample shows the option available in stables/icehouse17:11
morganfainbergbrowne, it is in icehouse, but there is a *BIG* caveate.17:12
morganfainbergbrowne, it wont work very well and has a lot of edge-cases17:12
morganfainbergbrowne, Juno is where we have all the bugs worked out and it should be fully functional17:12
brownemorganfainberg: ok, so i guess your recommendation would be to avoid it in icehouse, correct17:13
morganfainbergbrowne, yes.17:13
brownemorganfainberg: ok thanks17:13
morganfainbergbrowne, you'll pull less hair out that way trying to deal with the weird bugs around it17:13
*** hrybacki_ has joined #openstack-keystone17:13
morganfainberg*rather than dealing with17:14
brownemorganfainberg: is there any other way i could split service users from ldap users in icehouse?  trying to avoid the requirement of having service users in ldap server17:14
*** slogan has quit IRC17:14
morganfainbergbrowne, not sure if there is a good way to approach that.17:15
brownemorganfainberg: ok np17:16
morganfainbergbrowne, though someone else here might have a bit more insight (cc stevemar, gyee )17:16
*** hrybacki has quit IRC17:16
*** harlowja_away is now known as harlowja17:17
*** hrybacki_ has quit IRC17:18
*** marcoemorais has joined #openstack-keystone17:23
*** slogan has joined #openstack-keystone17:25
sloganAny keystone people able to comment on https://ask.openstack.org/en/question/43588/devstack-multi-tenant-and-metadata-service/ ?17:25
*** lbragstad has joined #openstack-keystone17:28
gyeebrowne, not in IceHouse. But I think henrynash did the magic in Juno to make per-domain backend working in Juno17:28
gyeefor IceHouse, you'll need to look at some of the out-of-tree solutions. i.e. http://www.mattfischer.com/blog/?p=57617:28
brownegyee: ok thx17:29
slogan#join openstack-neutron17:33
dstanekI think I'm going to be heading out in a bit to go to PyOhio!17:36
bknudsondstanek: do you have a presentation?17:37
dstanekbknudson: thankfully not this year.I get to enjoy it17:38
dstanekIs thinking about an open space on OpenStack development17:39
*** rwsu has quit IRC17:41
bknudsonI bet that would be a popular booth17:43
*** gokrokve has joined #openstack-keystone17:45
dstanekThere will be other people there that are familiar with the process17:45
*** amerine has quit IRC17:56
*** ukalifon1 has quit IRC17:57
*** hrybacki has joined #openstack-keystone18:03
*** bknudson has quit IRC18:05
*** gabriel-bezerra has quit IRC18:10
*** gabriel-bezerra has joined #openstack-keystone18:11
dolphmmorganfainberg: topol: bknudson: as a follow up to the oslo meeting http://lists.openstack.org/pipermail/openstack-dev/2014-July/041269.html18:11
dstanekdolphm: if the list is also cool with the change is the a process to bring it to the TC?18:13
dolphmdstanek: the two code reviews linked there must be approved by the TC to merge, so that'll be the next step18:13
ayoungmorganfainberg, you have abunch of "remove dependency on token_api" changes that do not remove the @requires  tag, andI assume that is intentional.  What is the overall plan there?18:14
dolphmayoung: morganfainberg: actually that sounds like it should have been removed, unless it was intended to not break people who have extended those classes and were still expecting the token_api?18:17
ayoungdolphm, that would be my expecation, but there was something in the comments to the contrary...18:17
dolphmayoung: link?18:18
openstackgerritA change was merged to openstack/python-keystoneclient: Add the 'auth' interface type  https://review.openstack.org/10473418:19
ayoungdolphm, looking...18:19
*** slogan_ has joined #openstack-keystone18:20
openstackgerritA change was merged to openstack/keystone: Clean up EP-Filter after delete project/endpoint  https://review.openstack.org/10950718:21
*** ukalifon1 has joined #openstack-keystone18:21
*** slogan has quit IRC18:22
ayoungdolphm, https://review.openstack.org/#/c/109173/5/keystone/contrib/ec2/controllers.py,cm18:22
ayoungdolphm, looks like that is the comment, and then it is set at the top level in the wsgi file18:23
ayoungmorganfainberg, Nevermind, as I Looked through the code to answer dolphm 's request for the link, I see the general pattern18:24
ayoungits just the ec2 one tha has to carry the link for a while18:25
openstackgerritA change was merged to openstack/keystonemiddleware: remove unused dep: stevedore  https://review.openstack.org/10906318:30
openstackgerritA change was merged to openstack/keystonemiddleware: remove unused dep: prettytable  https://review.openstack.org/10905918:30
*** joesavak has quit IRC18:33
stevemarayoung, if you have a minute: https://review.openstack.org/#/c/109614/18:41
stevemardolphm, ^18:41
*** gabriel-bezerra has quit IRC18:47
*** gabriel-bezerra has joined #openstack-keystone18:47
*** morganfainberg is now known as morganfainberg_Z18:53
*** gabriel-bezerra has quit IRC18:53
*** amerine has joined #openstack-keystone18:56
*** sacharya has joined #openstack-keystone18:59
*** ukalifon1 has quit IRC19:00
*** bknudson has joined #openstack-keystone19:02
*** sacharya has left #openstack-keystone19:05
*** bknudson has quit IRC19:06
*** marcoemorais has quit IRC19:07
*** bobt has joined #openstack-keystone19:08
*** comstud is now known as bearhands19:08
*** gabriel-bezerra has joined #openstack-keystone19:11
*** marcoemorais has joined #openstack-keystone19:11
*** marcoemorais has quit IRC19:11
*** marcoemorais has joined #openstack-keystone19:11
*** bknudson has joined #openstack-keystone19:20
*** gokrokve has quit IRC19:28
bknudsondstanek: there's a presentation on Heat.19:29
lbragstadbknudson: tried out your patch19:35
lbragstadhttps://review.openstack.org/#/c/109389/19:35
lbragstadit works19:35
lbragstadnice job19:35
bknudsonlbragstad: y... I still have to re-do it though19:35
bknudsonI shouldn't have to change the model. I should be able to create the right kind of events using the fields that are there.19:36
bknudsonbut now I'm backing up and trying to figure out the issue with v2 tokens...19:36
lbragstadgotcha19:36
bknudsonif you do a self.head('/auth/tokens', headers={'X-Subject-Token': token}, expected_status=200) before deleting the v2 token it works19:37
bknudsonbut if you don't check the token before revoking it then it fails19:37
lbragstadstrange19:37
bknudsony, it is19:37
bknudsonchecking a token shouldn't have any effect on the server19:37
bknudsonthe state of the server19:38
lbragstadbknudson: so,19:38
lbragstadyou get a token, do important stuff, and then validate before you revoke and it work19:38
lbragstadworks*19:38
lbragstadbut if you revoke without validating it doesn't?19:39
bknudsony... there's a test I can point you at19:39
bknudsonhttp://git.openstack.org/cgit/openstack/keystone/tree/keystone/tests/test_v3_auth.py#n130419:39
bknudsonlbragstad: if you comment out that line then the test will fail19:40
lbragstadhttps://review.openstack.org/#/c/109125/4/keystone/tests/test_v3_auth.py19:40
lbragstadoh19:40
lbragstadbknudson: ... do you think it's anything in format_token?19:49
bknudsonI don't know what it could be19:50
lbragstadI'm looking through the token api for v219:51
*** ayoung has quit IRC19:56
bknudsonmaybe it's just because it adds a little bit of time... I should try replacing the extra HEAD req with a sleep.19:57
bknudsonno, that doesn't make any sense since I've got breakpoints all over.19:59
*** ayoung has joined #openstack-keystone20:01
openstackgerritA change was merged to openstack/keystone: Add X-Auth-Token header in federation examples  https://review.openstack.org/10961420:01
*** henrynash has quit IRC20:01
*** david-ly_ has quit IRC20:02
*** marcoemorais has quit IRC20:03
*** marcoemorais has joined #openstack-keystone20:05
lbragstadbknudson: I don't *think* I'm seeing any tests that verify the format_token helper20:09
lbragstador verify the output anyway20:10
bknudsonit looks like the token issued_at is later than it should be... which doesn't make any sense.20:12
lbragstadbknudson: paste?20:12
lbragstadlater than it should be wrt?20:12
bknudsonlbragstad: I don't have anything that I could paste20:13
bknudsonlater than what it should be based on when I got the token20:13
lbragstadoh20:13
*** henrynash has joined #openstack-keystone20:17
bknudsonthe returned token says u'issued_at': u'2014-07-25T20:15:49.320034' and then token_data in is_revoked has 2014-07-25 20:16:22.93603420:17
bknudsonthat doesn't make any sense20:17
*** slogan_ has quit IRC20:18
*** gokrokve has joined #openstack-keystone20:19
lbragstadit was revoked 30 seconds after it was issued?20:19
*** henrynash has quit IRC20:19
*** slogan_ has joined #openstack-keystone20:19
*** dims has quit IRC20:20
bknudsonlbragstad: it looks like the token's issued_at time changed.20:20
*** dims has joined #openstack-keystone20:21
lbragstadbknudson: when do you see this?20:24
lbragstadwhen you say 'returned' token, what api call are you making?20:24
bknudsonlbragstad: the POST to /v2.0/tokens returned u'issued_at': u'2014-07-25T20:15:49.320034'20:25
bknudsonand then later in the HEAD to validate that the token is valid then token_data has 2014-07-25 20:16:22.93603420:25
bknudsonI'd expect the token's issued_at time to not change20:26
*** marcoemorais has quit IRC20:28
*** slogan_ has quit IRC20:28
*** marcoemorais has joined #openstack-keystone20:29
*** gordc has joined #openstack-keystone20:30
gordcdolphm: regarding pycadf-core, is the plan to have that continue on as normal? ie. nominating new members and not bringing in keystone-core team by default?20:34
lbragstadbknudson: you're doing http://docs.openstack.org/api/openstack-identity-service/2.0/content/tokens.html ?20:34
dolphmgordc: don't have a rigid plan; what what you suggest?20:34
bknudsonlbragstad: y, that's the original request to get the v2 token20:35
lbragstadyep, I have that20:35
lbragstadwhat does your -HEAD request look like?20:36
gordcdolphm: is there anyone specifically interested in auditing from keystone team? i wouldn't mind having an extra set of eyes for review (if we expect a lot of work in future)20:36
bknudsonlbragstad: it's this one: http://git.openstack.org/cgit/openstack/keystone/tree/keystone/tests/test_v3_auth.py#n130620:36
bknudsonthat actually uses the v3 api and not the v2 api20:36
lbragstadbknudson: right.20:36
gordcalso, oslo-core is by default members as well... will that continue on?20:37
lbragstadbknudson: it uses the v3 api with v2 tokens20:37
bknudsonlbragstad: y. that should be allowed but maybe it's not being handled correctly20:37
*** gabriel-bezerra has quit IRC20:37
dolphmgordc: besides myself, i would guess maybe stevemar, bknudson and morganfainberg_Z ?20:38
bknudsonlbragstad: because it looks like there's calls in the token handling patch that are v3-only.20:38
*** gabriel-bezerra has joined #openstack-keystone20:38
dolphmgordc: i haven't really asked around though, i just know that we've ^ had conversation about audit20:38
lbragstadhttps://github.com/openstack/keystone/blob/master/keystone/token/providers/common.py#L57220:38
lbragstadhttps://github.com/openstack/keystone/blob/master/keystone/token/providers/common.py#L60520:38
stevemardolphm, gordc i can almost guarantee i'll be maintaining pycadf20:39
gordcdolphm: cool cool. i'll just add you for now and we can expand from there? dhellmann, any concerns?20:39
stevemargordc, not naming names, but someone increased my workload :P20:39
dolphmstevemar: well then we have a volunteer20:39
gordcdhellmann: the above assuming everyone is ok with expanded Keystone scope20:40
bknudsonlbragstad: check this out... looks fishy https://github.com/openstack/keystone/blob/master/keystone/token/providers/common.py#L63620:40
bknudsonv3_token_data_helper.get_token_data() doesn't get the issued_at time.20:40
bknudsonlbragstad: and then look here: https://github.com/openstack/keystone/blob/master/keystone/token/providers/common.py#L31920:41
bknudsonit sets issued_at to the current time.20:41
lbragstadbknudson: yep20:41
lbragstadbut... it's that only v3?20:42
lbragstadv2.0 token does something different20:42
lbragstadhttps://github.com/openstack/keystone/blob/master/keystone/token/providers/common.py#L60520:42
bknudsonlbragstad: take a look at https://github.com/openstack/keystone/blob/master/keystone/token/providers/common.py#L636 again... it says "token ref is created by V2 API"20:42
lbragstadgyee: ping?20:43
lbragstadbknudson: should we hit that path though?20:43
lbragstadthat is with a v3 token.20:43
lbragstadthis case is using the v3 api with a v2.0 token20:43
* lbragstad might be missing something? 20:43
lbragstadin the v2 token case, token_data is populated with token_data = self.v2_token_data_helper.format_token()20:44
bknudsonthat path is hit. I got there in the debugger20:44
bknudson/opt/stack/keystone/keystone/auth/controllers.py(503)check_token() -> /opt/stack/keystone/keystone/token/provider.py(184)validate_v3_token()20:44
lbragstad...20:45
lbragstadhmm20:45
bknudsonMaybe the v3 means that we want a v3 response and not that the token is necessarily v320:45
bknudsonI think morganfainberg_Z is going to clean all this up with his token model work20:45
gordcdolphm: while i have you, could you take a look at comment on https://review.openstack.org/#/c/102958/20:45
lbragstadbknudson: strange20:45
gordcstevemar: name names! this isn't being recorded.20:46
lbragstadbknudson: this path seems like it was built for the POST case and not HEAD20:47
gyeelbragstad, here20:47
lbragstadi.e. Give me a new token, in which case the issued_at time needs to be now,20:47
lbragstadgyee: bknudson and I are hitting a weird (or what seems weird) case with using v2 tokens with the v3 token api20:48
dolphmgordc: how does it have a dependency on other middleware?20:48
lbragstadgyee: if you comment out this line: http://git.openstack.org/cgit/openstack/keystone/tree/keystone/tests/test_v3_auth.py#n130420:48
lbragstadthat test fails..20:48
gyeeit failed at the next line?20:49
lbragstadgyee: bknudson traced v2 token validation through https://github.com/openstack/keystone/blob/master/keystone/token/providers/common.py#L31920:49
lbragstadwhich is for v3 tokens only?20:50
gordcdolphm: so originally when i built middleware, there was a separate middleware that did something similar (notifiermiddleware)20:50
gyeeright, anything *_at is v3 stuff20:50
*** marekd is now known as marekd|away20:50
gordcthat middleware basically grabs an undefined set of environment variables for each request and builds/sends a notification of it20:51
bknudsonI haven't tried this, but I think if you get a V2 token and then validate it using V3 it will return a different issued_at time20:51
stevemardolphm, gordc speaking of pycadf, did you all want to talk about: https://review.openstack.org/#/c/109060/20:51
bknudsongyee: ^ is what I think the issue is20:51
dolphmgordc: ah; so the alternative is just to emit the notification from the same piece of middleware?20:51
gordcdolphm: currently the audit middleware inherits the notifiermiddleware and includes the audit event as part of that undefined set of env variables20:52
dolphmstevemar: yeah, it still bothers me that endpoints are considered audit-relevant at all20:52
bknudsonlbragstad: maybe you could try that... get a V2 token and then validate it using V320:52
dolphmgordc: inherits how?20:52
gordcdolphm: yeah, the alternative is to just emit audit event and ignore all the other env variables notifiermiddleware includes20:53
dolphmgordc: in 102958, AuditMiddleware extends object20:53
gordcdolphm: yeah, that wasn't meant to be reviewed... it was sort of a brain dump before i went on vacation20:53
gordcbut that patch is more towards removing dependency on notifiermiddleware20:54
gordcdolphm: the audit middleware in production today is this: https://github.com/openstack/pycadf/blob/master/pycadf/middleware/audit.py20:54
dolphmgordc: ack; one piece of middleware sounds much more attractive if there's no reason for *other* pieces of middleware to add additional data to the audit notification20:55
gordcdolphm: ok, i'll go ahead with single middleware solution20:55
gyeebknudson, but HEAD call should not reconstruct token data20:55
gyeeHEAD simply checks for token ID20:55
bknudsongyee: with revocation events, the HEAD call has to reconstruct the token data to check the data against the revocation events20:56
bknudsonwhen we had a revocation list then only the token ID was needed20:56
dolphmgordc: so, today it's keystonemiddleware.auth_token -> pycadf.middleware.audit in the pipeline, right?20:57
gordcdolphm: yep20:57
bknudsonlbragstad: I think I've got a fix20:57
gordcit would be the same afterwards since we depend on service catalog.20:58
dolphmgordc: but keystonemiddleware.*.audit is intended to replace pycadf.middleware.audit ?20:58
gordcstevemar: in CADF, for Resources, the id field is required. http://docs.openstack.org/developer/pycadf/specification/resources.html20:58
gordcdolphm: right. i'd probably remove the middleware (and it's dependencies) from pyCADF when we move it to keystonemiddleware20:59
dolphmgordc: cool. does pycadf have a -spec repo somewhere?21:00
bknudsonlbragstad: gyee: I'll clean this up and post it since it seems to work.21:00
gordcdolphm: we discussed it but since there wasn't much work being done on it, we didn't create one.21:01
gyeebknudson, you found the problem?21:01
gordcdolphm: do you intend on expanding pyCADF beyond the actual CADF specification?21:01
bknudsongyee: yes, it's essentially also passing along the token's issued_at time here: https://github.com/openstack/keystone/blob/master/keystone/token/providers/common.py#L63621:01
stevemargordc, shouldn't we not expand it beyond the spec?21:02
dolphmgordc: no, i mean for the implementation, not the standard21:02
gordcdolphm: yeah, the pyCADF library itself doesn't have a spec... but could if there's a need.21:02
gordcstevemar: the double negative seems like a trick question.lol21:02
*** dims has quit IRC21:03
bknudsonwe'll probably want to keep matt rutkowski as a core to keep us honest21:03
dolphmgordc: i'm just thinking with a separate core team, a separate spec repo makes sense? or both core teams need +2 on keystone-specs. *shrug*21:03
gyeebknudson, but that's expected though since token is created by V221:03
gordcstevemar: i think it should be as lightweight as possible... so just the spec hopefully (unless something else falls under it)21:03
bknudsongyee: a V2 token also has an issued_at time21:04
gordcdolphm: yeah we can create a separate spec repo... was there a specific bp you had in mind that would fall under pyCADF?21:04
gyeebknudson, yeah I see21:05
dolphmgordc: how do people consume the audit notifications, btw? i haven't gotten that far!21:05
gordci just didn't do it because we didn't really have any bps, just work items to fill gap between implementation and spec.21:05
dolphmgordc: specific bp == moving pycadf middleware to keystoneclient21:05
dolphmerr keystonemiddleware21:05
lbragstadbknudson: sure, I can try that21:06
gordcdolphm: right now, because it's tied to notifiermiddleware, the audit event is part of http.request and http.response meters in ceilometer (if middleware is enabled)21:06
lbragstadbknudson: so steps to recreate, 1.) POST to get a token with v2 and note the time 2.) Use HEAD to check the token with v3 and see if the issued-at time changed21:07
gordcdolphm: i guess that's a bp... (i would've snuck that in as a bug) :)21:07
bknudsonlbragstad: is there a GET v3 to get the token info?21:07
stevemardolphm, why not have pycadf specs under the identity-spec umbrella?21:07
stevemarwe have middlware and client ones there21:07
bknudsonlbragstad: if it's just a HEAD then you're not going to get the data21:08
dolphmstevemar: my only concern with that is how +2's work - if they should be separate core teams then the gerrit permissions should reflect that21:08
stevemardolphm, honor system?21:08
stevemardolphm, seems like a lot of hassle21:09
stevemarjust my 2c21:09
dolphmstevemar: if we're going to have a seperate core team, it seems like less hassle to have two specs repos21:09
lbragstadbknudson: checking21:10
gordcdolphm: tbh, regardless, i think most of the reviews will be from keystone members.. (plus me)21:11
lbragstadbknudson: there is a GET for /auth/tokens/ in v321:11
lbragstadthat is what returns the service catalog21:11
bknudsonthis should be interesting21:11
lbragstadbknudson: http://docs.openstack.org/api/openstack-identity-service/3/content/tokens-1.html21:11
lbragstadbknudson: so, if what you're saying is true, issued_at time for a v2 token using that API shouldn't change unless using HEAD /auth/token21:12
lbragstads/token/tokens/21:12
gyeelbragstad, v2 have no issued_at date I don't think21:13
bknudsonlbragstad: if what I'm saying is true then the issued_at time in the POST /v2.0/tokens will be different than the issued_at time from GET /auth/tokens21:13
gyeeso when we convert a v2 token to v3, we have to pull one our of asses21:13
lbragstadgyee: http://pasteraw.com/37q9v3y80tlydltujo7vwfk7gcabggf21:14
bknudsongyee: lbragstad: my v2 token had an issued_at time21:14
lbragstadbknudson: ^21:14
lbragstadbknudson: so did mine21:14
lbragstadv2 tokens include all that in the response body21:14
gyeewas that added later21:15
*** marcoemorais1 has joined #openstack-keystone21:15
gyeeI remember the original doc doesn't have this date21:15
bknudsonit might have been21:15
bknudsonmaybe it was added for revocation events21:15
gyeeall the *_at dates are v321:15
stevemardolphm, alright 2 repos21:15
lbragstadbknudson: so with the v3/auth/tokens/ GET, you included the v2 token in X-Subject-Token?21:16
lbragstadright?21:16
bknudsonlbragstad: now you should be able to pass that token ID to GET /v3/auth/tokens21:16
*** marcoemorais1 has quit IRC21:16
bknudsonlbragstad: yes21:16
gyeek, looks like identity-api doc for v2 is outdated21:16
gyeedefinitely don't have the issued_at date there21:17
bknudsongyee: the WADLs?21:17
*** marcoemorais1 has joined #openstack-keystone21:17
gyeebknudson, no trace of it anywhere21:17
lbragstadbknudson: http://pasteraw.com/3oycofc541dil3d7hkzhihlcxlthqg421:18
lbragstadbknudson: you're right21:18
lbragstadthe issued_at time changes21:18
bknudsonlbragstad: do you get a different issued_at every time?21:18
*** marcoemorais has quit IRC21:18
lbragstadbknudson: I did between the POST /v2.0/tokens/ and GET /v3/auth/tokens/ calls21:19
bknudsonlbragstad: what if you do a GET again with the same token?21:19
lbragstadbknudson: with the same token in X-Subject-Token?21:19
bknudsonlbragstad: yes21:20
lbragstadbknudson: yes21:20
lbragstadhttp://pasteraw.com/9wgyrmawewer1ptv5ct58w7pcrfb7zt21:20
lbragstadit happens on every GET call21:20
gyeefigured21:20
lbragstadsweet21:21
bknudsonwell, mystery solved21:21
lbragstadwell /v3/auth/tokens/ GET has a bug21:21
bknudsonI feel like a regular Lisbeth Salander21:21
dolphmissued at is changing?21:22
gyeeyeah, like a magic 8 ball21:22
lbragstadbknudson: do you have a bug already open?21:22
bknudsonlbragstad: I'd open a new bug for this one21:23
lbragstadbknudson: ok, I can do that21:23
*** gabriel-bezerra has quit IRC21:23
bknudsonit's probably an OSSA since it means that tokens aren't getting revoked as expected21:23
gyeefunny we keep shoehorning these things into v2 :)21:24
bknudsonwe should just get rid of v221:24
*** gabriel-bezerra has joined #openstack-keystone21:24
gyeewe won't fix it, nice incentive for ppl to move to v3 :)21:25
dolphm(what's not fixable on v2?)21:25
gyeedolphm, its fixable, it was a joke21:26
lbragstadhttps://bugs.launchpad.net/keystone/+bug/134882021:27
uvirtbotLaunchpad bug 1348820 in keystone "Token issued_at time changes on /v3/auth/token GET requests" [Undecided,New]21:27
lbragstadnice catch bknudson21:27
lbragstadgyee: ^21:28
gyeegood stuff!21:28
lbragstadbknudson: it was because of: https://github.com/openstack/keystone/blob/master/keystone/token/providers/common.py#L319 ?21:30
bknudsonlbragstad: y, that's where it's getting the new issued_at every tiem.21:31
lbragstadbknudson: ok, noting that in the bug21:31
gyeeshit that means the hash is broken too21:31
*** gabriel-bezerra has quit IRC21:31
gyeenm, pki tokens we don't regen21:32
*** gabriel-bezerra has joined #openstack-keystone21:32
lbragstadso, when I read the code, it seems like v2 tokens shouldn't be validated with that path21:33
lbragstadshouldn't it go through: https://github.com/openstack/keystone/blob/master/keystone/token/providers/common.py#L60521:34
lbragstad?21:34
bknudsonlbragstad: if you do a v3 request it has to return a v3 token response21:36
bknudsoneven if it was given a v2 token21:36
lbragstadbknudson: gotcha21:36
bknudsonthat doesn't mean you're wrong that a v3 request could go down that path instead... but at some point the v2 token has to be turned into a v3 token21:38
*** gokrokve has quit IRC21:38
*** henrynash has joined #openstack-keystone21:42
lbragstadbknudson: which is where the format_token stuff comes into play?21:43
bknudsonlbragstad: I guess so... it's strange that V2TokenDataHelper has format_token and V3TokenDataHelper has get_token_data21:46
lbragstadbknudson: yeah... that's what I was thinking21:46
openstackgerritBrant Knudson proposed a change to openstack/keystone: Add a test for revoking a V2 token without validating first  https://review.openstack.org/10960221:48
openstackgerritBrant Knudson proposed a change to openstack/keystone: Fix for revoking a V2 token without validating first  https://review.openstack.org/10974721:48
*** cjellick has quit IRC21:49
*** gabriel-bezerra has quit IRC21:49
*** cjellick has joined #openstack-keystone21:49
*** gabriel-bezerra has joined #openstack-keystone21:50
*** doddstack has quit IRC21:52
*** jasondotstar has quit IRC21:52
*** elmiko is now known as _elmiko21:52
*** cjellick has quit IRC21:54
*** cjellick has joined #openstack-keystone21:54
*** gokrokve has joined #openstack-keystone21:54
*** cjellick has quit IRC21:55
*** morganfainberg_Z is now known as morganfainberg21:55
*** gokrokve has quit IRC21:55
*** cjellick has joined #openstack-keystone21:55
morganfainbergbknudson, i'm trying to solve some of it with the tokenmodel21:55
morganfainbergbknudson, but... it's slowish.21:56
*** gokrokve has joined #openstack-keystone21:56
morganfainbergbknudson, lots to get there21:56
*** gokrokve has quit IRC22:01
*** marcoemorais1 has quit IRC22:03
*** gokrokve has joined #openstack-keystone22:03
*** marcoemorais has joined #openstack-keystone22:05
morganfainbergstevemar, ping22:08
morganfainbergstevemar, re: tokens if you're around now22:08
stevemarmorganfainberg, pongish22:08
stevemarmorganfainberg, here, for a bit anyway22:08
morganfainbergstevemar, ok so for the saml2 token, we don't have domain in the user section22:09
morganfainbergstevemar, this breaks things such as revocation events22:09
openstackgerritBrant Knudson proposed a change to openstack/keystone: Add tests related to V2 token issued_at time changing  https://review.openstack.org/10960222:09
openstackgerritBrant Knudson proposed a change to openstack/keystone: Fix for V2 token issued_at time changing  https://review.openstack.org/10974722:09
bknudsonok, I think this is good for that part of the revocation event fixes22:09
morganfainbergstevemar, any thoughts on ... well. what we should be doing, should we *not* assume a token user has a domain info?22:09
henrynashmorganfainberg: hi……in https://review.openstack.org/#/c/106917/10/keystone/tests/unit/token/test_token_model.py, can you explain why you issue, for instance, self.assertTrue(token_data.project_scoped) more than once in a given test?22:10
stevemarmorganfainberg, thats not good22:10
morganfainberghenrynash, i check that we're project scoped, then we delete the project scope22:10
morganfainberghenrynash, i think one should be assertFalse, right?22:11
stevemarmorganfainberg, well whats the impact in assuming a user does not have a domain section? accidentally look up the wrong user?22:11
morganfainbergstevemar, well more we always *assume* there is a domain with a user (even v2, we have 'default')22:11
henrynashmorganfainberg: no that bits correct, but before that….see lines 79 and 8822:11
morganfainberghenrynash, let me look.22:11
stevemarmorganfainberg, no way to skip that part if OS-FEDERATION exists in the dict?22:12
morganfainberghenrynash, ah, copy/paste22:12
stevemarmorganfainberg, or actually, we could put the IDP value in there as domain id/name ?22:12
openstackgerritLance Bragstad proposed a change to openstack/keystone: Add test for checking token issued_at time  https://review.openstack.org/10975722:12
henrynashmorganfainberg: ok, not wrong, but a bit duplicative….22:12
stevemarmorganfainberg, that's guaranteed to be unique22:12
morganfainberghenrynash, yeah it's just a duplicate that isn't needed22:12
morganfainbergstevemar, hmm.22:12
morganfainbergstevemar, well we need to fix middleware as well22:13
lbragstadbknudson: ^22:13
lbragstadyou can incorporate that if you want22:13
bknudsonlbragstad: I updated an existing test in https://review.openstack.org/#/c/109602/22:13
stevemarmorganfainberg, the revocation part?22:14
*** gordc has quit IRC22:14
morganfainbergstevemar, yes and the bug i linked to you this morning22:14
bknudsonlbragstad: there was already a test that checked some fields22:14
lbragstadbknudson: ok, cool22:14
henrynashmorganfainberg: there’s a  similar one for domains in the V2 test….personally I’m ok with a bit of duplication….do you want me to approve, or do you want to fix…22:16
morganfainberghenrynash, i'd be happy to clean it up as a follow-on if that works for you22:16
henrynashmorganfainberg: fine22:16
morganfainberghenrynash, but i wouldn't be opposed to you asking it to be fixed first22:16
*** lbragsta_ has joined #openstack-keystone22:17
morganfainberghenrynash, it depends on how important cleaning up the duplication is (if its as a follow-on, I'll post it in a few minutes)22:17
henrynashmorganfainberg: let’s get what we have in, since teh duplication is beingn, clean up at will22:18
morganfainberghenrynash, ok i'll post cleanup in a few minutes22:18
*** lbragstad has quit IRC22:20
*** lbragsta_ has quit IRC22:21
openstackgerritBrant Knudson proposed a change to openstack/keystone: Add a test for revoking a scoped token from an unscoped  https://review.openstack.org/10912522:22
openstackgerritMorgan Fainberg proposed a change to openstack/keystone: Remove duplicated asserts  https://review.openstack.org/10976022:22
morganfainberghenrynash, ^22:22
henrynashmorganfainberg: thx22:24
*** stevemar has quit IRC22:25
openstackgerritBrant Knudson proposed a change to openstack/keystone: Add a test for revoking a scoped token from an unscoped  https://review.openstack.org/10912522:32
*** stevemar has joined #openstack-keystone22:33
openstackgerrithenry-nash proposed a change to openstack/keystone-specs: Endpoint policy extension  https://review.openstack.org/9984222:34
*** xianghuihui has quit IRC22:35
*** hrybacki has quit IRC22:41
openstackgerritBrant Knudson proposed a change to openstack/keystone: Fix revoking a scoped token from an unscoped token  https://review.openstack.org/10938922:41
*** amerine has quit IRC22:45
*** amerine has joined #openstack-keystone22:45
*** stevemar has quit IRC22:49
*** xianghuihui has joined #openstack-keystone22:51
openstackgerritA change was merged to openstack/keystone: remove static files from docs  https://review.openstack.org/10947222:52
*** hrybacki has joined #openstack-keystone22:55
*** morganfainberg is now known as morganfainberg_Z22:55
*** gokrokve has quit IRC22:55
*** harlowja is now known as harlowja_away22:58
openstackgerritBrant Knudson proposed a change to openstack/keystone: Fix revoking a scoped token from an unscoped token  https://review.openstack.org/10938922:59
*** topol has quit IRC23:04
*** harlowja_away is now known as harlowja23:06
*** morganfainberg_Z is now known as morganfainberg23:08
openstackgerritA change was merged to openstack/keystone: Add the new Keystone TokenModel  https://review.openstack.org/10691723:17
*** gokrokve has joined #openstack-keystone23:18
*** hrybacki has quit IRC23:22
*** gpocente1 has joined #openstack-keystone23:24
*** shuffleb1t has joined #openstack-keystone23:24
*** gpocentek has quit IRC23:29
*** ekarlso has quit IRC23:29
*** shufflebot has quit IRC23:29
*** boris-42 has quit IRC23:29
*** boris-42 has joined #openstack-keystone23:31
*** ekarlso has joined #openstack-keystone23:31
openstackgerritBrant Knudson proposed a change to openstack/keystone: Fix revoking a scoped token from an unscoped token  https://review.openstack.org/10938923:32
*** marcoemorais has quit IRC23:34
*** marcoemorais has joined #openstack-keystone23:35
*** henrynash has quit IRC23:37
*** marcoemorais has quit IRC23:39
*** hrybacki has joined #openstack-keystone23:40
*** stevemar has joined #openstack-keystone23:40
*** marcoemorais has joined #openstack-keystone23:41
openstackgerritBrant Knudson proposed a change to openstack/keystone: Fix revoking a scoped token from an unscoped token  https://review.openstack.org/10938923:50
*** morganfainberg is now known as morganfainberg_Z23:51
*** gokrokve has quit IRC23:54

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