Tuesday, 2015-02-24

*** ljfisher has quit IRC00:02
*** chrisshattuck has quit IRC00:05
*** nkinder has quit IRC00:05
*** dims has quit IRC00:08
openstackgerritJamie Lennox proposed openstack/python-keystoneclient: Import functional CLI tests from tempest  https://review.openstack.org/15850300:12
*** abhirc has quit IRC00:25
*** raildo has quit IRC00:26
morganfainberggyee, we need more than a single string for k2k00:28
jamielennoxmorganfainberg: http://www.jamielennox.net/blog/2015/02/23/v3-authentication-with-auth-token-middleware/00:28
morganfainberggyee, the single string is just not enough.00:28
morganfainbergjamielennox, ^ cc, so the separate service_providers is a better construct. especially since they don't have a region or other such things00:29
jamielennoxmorganfainberg: i like the idea of reusing existing though, project specific endpoints etc will all be required for service_providers00:30
morganfainbergjamielennox, yes. it sadly [short of redefining the catalog data and what is returned] isn't really possible in the current constructs00:30
morganfainbergand *that* will likely break people more than having an element they don't know what to do with (the service_providers list)00:31
jamielennoxi don't think either will break people00:31
jamielennoxwe've managed to add a whole bunch of new services that old clients didn't know about and they just ignore the service_catalog entry00:32
jamielennoxmorganfainberg: what i think we're missing here is some definition of how this should work regarding flow00:34
gyeemorganfainberg, but they are two different endpoints right, one for auth and the other for service API00:34
jamielennoxmorganfainberg: we had the same arguments about whether we should have endpoints from external clouds in our service catalog00:35
jamielennoxand i think we rightly said no there00:35
morganfainbergjamielennox, there is a difference between endpoints that don't conform data wise and those that do00:35
jamielennox(that was my last memory and i hope that happened000:35
morganfainbergwe are wedging this data into endpoints now, even though we just ripped it out of region because it wasn't a good fit for region00:35
gyeejamielennox, how are we proposal to solve the external service problem00:35
gyeeits easy to say they are not our problem :)00:36
jamielennoxgyee: i kind of think putting it in the existing service catalog is saying it's not our problem00:36
gyeebut holistically, it all in the same stack00:36
gyeejamielennox, huh?00:37
gyeeexternal Keystone is a service, as far as we are concerned00:37
gyeepeer service00:37
jamielennoxgyee: how do we differentiate it from the keystone service already in the catalog00:38
gyeejamielennox, we don't have to, that's the beauty of it00:39
gyeeas far as we are concerned, its an endpoint providing some service00:39
jamielennoxthat's going to confuse keystoneclient looking in the catalog though right?00:40
gyeeno, keystoneclient cares about that filter00:40
gyeewhich is basically a dict00:40
gyeean endpoint is no different from an identity, which is essentially a set of attributes00:40
jamielennoxbut you'd still have service_type='identity' right?00:40
gyeeservice_type is up to us to define00:41
gyeebut its one of the attributes which make up an endpoint00:41
*** dims has joined #openstack-keystone00:42
jamielennoxgyee: so how do you see this working?00:43
jamielennoxcan you pastebin what the client flow would be00:44
gyeejamielennox, we have auth plugins, endpoint lookup, header overrides, and auth overrides right?00:45
jamielennoxgyee: with a session and auth plugin, and say novaclient, how would we get nova working in another cloud00:45
jamielennoxi think all those things are currently commited00:46
gyeejamielennox, it will require some degree of orchestration on the client side00:47
gyeelike from the catalog, get a list of other keystone endpoints out there that you have access to00:48
morganfainberggyee, the issue is we need more than just a url get_endpoint now needs to give different information back00:48
gyeethen request to authenticate to a given provider, and list the projects you have access to00:48
morganfainberggyee, than any other endpoint00:48
morganfainbergbecause you need to know the Identity URI and the SP Auth URI00:48
morganfainbergthis isn't a *normal* endpoint.00:48
jamielennoxgyee: this is what i want to know though - how much orchestration00:49
morganfainberghaving .get_endpoint return different information is not good if it has historically always returned 1 thing: a url/uri00:49
jamielennoxgyee: because i know we can filter for whatever we like - but how would we expect heat or something to handle that, do we need a user to provide filters for everything?00:49
gyeeno, it would all be handled by the app00:50
morganfainberggyee, saying "this is the app's problem" is not good ux00:50
morganfainbergit's how we've made a lot of things really awful for our users00:50
morganfainbergand users != deployers00:50
morganfainbergin this case00:50
gyeefederation, websso, etc are really app thingy00:51
gyeeyou don't expect user to curl through all the whole thing :)00:51
morganfainbergi also disagree strongly that keystone catalog is a facilitator - it should be well defined and clear what is available.00:51
gyeethat ain't fun00:51
gyeewho's going to see that catalog? end users?00:52
morganfainberggyee, but why should i need to know how to handle something totally different again when everything in the catalog today looks roughly the same. now we suddenly have data that doesn't conform to a list construct00:52
morganfainberga list should be homogenous data types in most cases00:52
morganfainberggyee, yes, an end user could see it.00:52
morganfainberggyee, in fact you have to assume an end user will see this.00:52
gyeewhat's end user going to do with the catalog?00:53
morganfainbergdo not say "oh that's an app problem" - and if you do, great what do i use in ksc .get_endpoint00:53
morganfainbergand now i get some endpoints that return data X and some that return data y?00:53
gyeeend user need to launch a VM, they just need to provider the username/password/some cred, and the app does the rest00:54
morganfainberggyee, so now i'm writing my own app00:54
morganfainberggyee, and i use ksc to do so00:55
morganfainbergi say .get_endpoint()00:55
morganfainbergto use local services i get back a single url, to use k2k i get back something totally different00:55
morganfainbergthe datatypes are not the same00:55
gyeewell, there are two urls there, auth_url and sp_url, which constitute two separate endpoints00:56
morganfainbergthe same thing holds true if i'm iterating through service['endpoints'], some things have wildly different data types?00:56
morganfainbergexcept now we have random endpoint types which we're trying to pair that down to "internal and external"00:56
morganfainbergbasically i'm saying things are such a mess now lets not keep making it worse00:57
gyee'identity' service have two different types of endpoints today, pubic, interna, and admin00:57
morganfainberggyee, so now we're adding more and more endpoint types00:57
gyeesure, if it needs to be00:57
gyeeor different service00:58
morganfainbergi think we're doing it horribly wrong00:58
morganfainbergthe current catalog should be used as a list of services that work like endpoints do today00:58
gyeebut there was never any expectation that the endpoints must be accessed with a token00:58
morganfainbergand i very much disagree with the wedge data into places00:58
morganfainberggyee, should we just revert the region url change then?00:58
morganfainbergi mean, region makes more sense than endpoint00:59
gyeeI think of region as a group of endpoints, nothing more00:59
morganfainbergwe took this out of region because it is an awful match for region, now we're putting it in an equally bad place where it doesn't fit00:59
morganfainbergso what region does a k2k federation belong to00:59
gyeehell I would use endpoint group to replace region if I have the choice00:59
morganfainbergbecause region is required00:59
morganfainbergthe data does not fit the profile of the data in service/endpoint01:00
jamielennoxmorganfainberg: don't revert the region thing, we have enough trouble trying to define what a region is without shoehorning a service provider on top of it01:02
jamielennoxi made a last ditch effort right before juno to remove regions as urls01:02
jamielennoxgyee: your right in that we never said that elements of the catalog have to be accessed with a token - but i think that's the way we've been operating and i think we should01:03
jamielennoxwe need to figure out (summit?) exactly how the catalog is supposed to work01:03
jamielennoxand figure out hierarchical regions and whatever relation to it01:04
jamielennoxit's not this problem but related01:04
*** drjones has quit IRC01:06
jamielennoxmorganfainberg: on DNS - i've wanted to do this for some time, but in what situations is DNS lookup appropriate? should reading from conf in auth_token middleware be allowed to use DNS discovery?01:06
*** atiwari has quit IRC01:07
morganfainbergjamielennox, i think it should simply be an option01:07
*** ljfisher has joined #openstack-keystone01:08
jamielennoxmorganfainberg: would having it on the 'generic' plugins be sufficient?01:08
*** ayoung has joined #openstack-keystone01:09
*** ChanServ sets mode: +v ayoung01:09
jamielennoxor simply the CLI part of generic01:09
*** adam_g is now known as adam_g_out01:09
*** sigmavirus24 is now known as sigmavirus24_awa01:10
*** devlaps has quit IRC01:11
morganfainbergjamielennox, i think so.01:11
morganfainbergjamielennox, the idea is that there should be away to say i'm using "cloud.rackspace.com" and know how to lookup it's auth URL from DNS.01:11
morganfainbergit's a minor "quality of life" type improvement01:12
*** ljfisher has quit IRC01:12
jamielennoxmorganfainberg: it's something i've talked about before at least - it's a help for your enterprise style deployments01:12
jamielennoxbut you still have so many other credentials you need that you generally get and rc file so it hasn't been a big issue01:12
morganfainbergjamielennox, it would just be a minor QOL thing. if you know where it goes i'd love to see it happen :)01:13
morganfainbergjamielennox, i agree it's not a super big priority, but minor quality of life changes = make users happy01:14
morganfainbergand happy users means more people use this stuff.01:14
jamielennoxlipstick on a pig01:14
morganfainbergesp. if it's "easy"01:14
morganfainbergjamielennox, don't underestimate dressing it up.01:14
*** david-lyle is now known as david-lyle_afk01:19
gyeethat's one pretty hog01:19
gyeethe name's Wilbur I think01:20
*** radez_g0n3 is now known as radez01:22
ayoungI'm going to infer from this that we got a release of policy.  https://review.openstack.org/#/c/148624/01:28
ayoung"Well, we'd have to be talkin' about one charming motherf******* pig."01:29
ayoungI mean he'd have to be ten times more charmin' than that Arnold on Green Acres, you know what I'm sayin'?01:31
*** browne has quit IRC01:31
*** browne has joined #openstack-keystone01:32
gyeeayoung, I love that quote01:32
morganfainbergayoung, policy was tagged.  release (with subsequent tag) will happen soonish01:36
morganfainbergayoung, tag != announced release01:36
ayoungmorganfainberg, so we can't  build against it yet?01:36
ayounghe's just getting things ready with that review?01:37
morganfainbergayoung, i mean you could pip install it01:37
morganfainbergbut yeah it's not in global reqs01:37
morganfainbergand the first one will be the announced release (for global reqs)01:37
ayoungAh...that is still a good step forward01:37
ayounghad a frustrating experience with packages and deployment today.  Case where running Keystone/Juno with everything else Icehouse would have made sense, but  since it is an all-in-one install we have to get the latests dependencies across the board01:38
ayoungwould love to make the norm each openstack service runs in its own container01:38
morganfainbergayoung, youre not the first person even in the last 7 days i've heard that from01:38
ayoungits like;  they don't even look at the LDAP issues when "certifying" a release will suit their needs01:39
ayoungthey lock in to an older version, and then expect the LDAP stuff to be magically cleared up.01:40
*** abhirc has joined #openstack-keystone01:40
ayoungIts like :  that was one of our major features moving to Juno.  No, we are not going to backport it, and no, we can't work around it01:40
*** _cjones_ has joined #openstack-keystone01:43
*** krtaylor has quit IRC01:43
*** jamielennox is now known as jamielennox|away01:46
ayoungmorganfainberg, Its that we've gone through all these unnatural convolutions to make them into sepratable services...Keystone is about as artificial a construct as you can find...and then the installers go and all-in-one on us, and then people are going to complain about complexity01:47
ayoung"You are doing it wrong"01:48
*** abhirc has quit IRC01:48
*** abhirc has joined #openstack-keystone01:49
ayoungstarting to really despise what is happening in our Puppet layer. It is a degree of codification that should not be there01:50
morganfainbergayoung, =/01:50
ayoungIt means that people can't "configure" what they should be configuring01:50
ayoungbecuase they can't hack through all the layers of puppet to get to what needs changing01:50
*** samueldmq has quit IRC01:51
ayoungin this case, one of our guys spent a day  trying to get a puppetized install to work where it was using pre-defined service user accounts instead of the ones that puppet tries to inject01:51
ayounga classic REad-Only LDAP setup01:51
ayoungsometimes you just have to tell them "yes, I could make it work.  But we won't support it."01:52
morganfainbergayoung, hah01:54
morganfainberghave i mentioned how happy i was to write the eventlet deprecation review?01:54
morganfainbergand email?01:54
morganfainbergand LDAP assignment one(s)?01:55
*** nkinder has joined #openstack-keystone01:55
*** gyee has quit IRC01:55
*** krtaylor has joined #openstack-keystone01:55
*** abhirc has quit IRC02:02
*** himangi has joined #openstack-keystone02:03
morganfainbergstevemar, hmm.02:07
stevemarmorganfainberg, o/02:08
*** jamielennox|away is now known as jamielennox02:12
*** dims has quit IRC02:14
ayoungwhat was the hack to get the unified diff in gerit?02:16
morganfainberglike that02:17
ayoung,unified worked.  thanks morganfainberg02:18
morganfainbergayoung, sure thing! :)02:19
*** erkules_ has joined #openstack-keystone02:20
ayoungmorganfainberg, so...reading https://review.openstack.org/#/c/153803/3/specs/backlog/HMAC-Signature-Based-Token.rst,unified  is he proposing KLWT?02:20
*** erkules has quit IRC02:23
*** abhirc has joined #openstack-keystone02:24
*** markvoelker has quit IRC02:25
*** markvoelker has joined #openstack-keystone02:26
morganfainbergayoung, something similar but different02:26
ayounghow is it different?02:27
*** markvoelker has quit IRC02:30
morganfainbergayoung, there is less data transmitted between keystone and the endpoints i *think*02:32
morganfainbergalso no support for encrypting the data02:32
morganfainbergayoung, so i *think* this is a defined message built from data, passed to keystone and validated witha  simple true/false, but all the data is housed in the token like PKI.02:33
morganfainbergi *think*02:33
morganfainbergi need to ask arvind to spend some time explaining a bit more. to me02:33
ayoungSo...big tokens?02:33
morganfainbergi think so02:33
morganfainbergi feel like there is some merit here that we can turn into useful w/ KLWT02:34
morganfainbergbut not sure what it is yet02:34
morganfainbergso more description/discussion will help suss that out02:34
*** abhirc has quit IRC02:34
morganfainbergor show it really is just KLWT and isn't needed02:34
ayoungSo... post Kilo, I want to add an option to have a signer field, and once again push all the validation to the remote service.  THis might help02:35
morganfainbergright like i said, possibly some merit here02:35
ayounganything that is not in the token body will get fetched and cached02:35
morganfainbergbut it's hard to pick it out in at least the previous version of this02:35
ayoungWe may decide to absorb Kite into Keystone02:35
ayoungFor HA keystone it seems to be the safest way to distribute the signing keys02:36
morganfainbergthis is the part i'm not sure about02:37
morganfainberghm, i think he has a mis-understanding of the PKI system: * Services have to share same PKI artifacts (private key)02:38
morganfainbergsince only keystone has the private keys (he's not talking about straight key distribution here)02:39
morganfainbergor it's something else.02:39
morganfainbergayoung, it's on my list to get some clarity on02:39
ayoungmorganfainberg, my guess is that is a key sharing thing:  Keystone shares a different Key with each service, otherwise the service can pretend to be Keystone and sign tokens itself.02:41
ayoungbut...that seems to contradict what he says elsewhere02:42
ayoungValidation will be done by matching the message digest with the signature02:42
ayoungothewise,...use hands a token body to a service, service calculate the HMAC, hands that to Keystone, and Keystone verifies?02:43
*** lhcheng is now known as lhcheng_afk02:43
ayoungto verify HMAC they need the symmetric key...02:43
morganfainbergexcept he was talking about the PKI tokens and issue with PKI tokens02:43
morganfainbergin that line02:43
ayoung+1. Keystone will be responsible for generating signature, token and signature02:44
morganfainbergthe line i'm talking about is in at 6702:44
morganfainbergwhich is problem description02:44
ayoungI think he is discussing KLWT02:44
morganfainbergwhich is under the PKI tokens section02:45
ayoungServices have to share same PKI artifacts (private key) that can cause as big02:45
ayoung68+ security gap.  Is just plane  rrongggg02:45
morganfainbergyeah i think we have some miscommunication on how PKI works02:45
ayoungUm.  Wikipedia PKI02:45
* ayoung shrug02:46
ayoungmorganfainberg, I got called out by Windish on Twitter for using a selfsigned cert for my blog.  Funny thing is, it makes perfect sense for me to do so, as I only care about my security, not my readers02:47
*** diegows has quit IRC02:47
*** spandhe has quit IRC02:48
mtreinishmorganfainberg: if you get a sec: https://review.openstack.org/155901 should be quick02:49
morganfainbergooh i want to see that in action02:50
morganfainbergif that makes things all have request ids that'd be cool02:50
mtreinishmorganfainberg: yeah it puts request_ids in all the response headers: http://logs.openstack.org/01/155901/3/check/check-tempest-dsvm-full/1947e89/logs/tempest.txt.gz#_2015-02-17_15_38_09_71402:51
morganfainbergayoung, so silly question, doesn't that need to go before token auth? so we know a failed request has an id as well? or is that not common in openstack land (cc mtreinish for the common/uncommon-ness)02:51
morganfainbergor do we not care about a failed auth having an id?02:52
morganfainbergFTR: i'm good with that as is ^^02:52
mtreinishmorganfainberg: I was just listening to ayoung on the proper placement in the pipeline :)02:52
ayoungmorganfainberg, you askin about mtreinish 's review?02:52
morganfainbergmtreinish, if it's something we need to adjust location we can do that quickly and still get this in or do it afterwards.02:52
morganfainbergmtreinish, not gonna bike-shed it here just was thinking if there was a reason we'd want a request id prior to json_body02:53
mtreinishmorganfainberg: yeah, it's a simple change either way02:53
ayoungI think All I said was that it needed to not be the last thing in the list...can;t remember thexact context02:53
ayoungso,  what does request_id do?02:53
morganfainbergyou said after json_body02:53
morganfainbergit generates a unique request id02:53
morganfainbergso we get somethjing like: http://logs.openstack.org/01/155901/3/check/check-tempest-dsvm-full/1947e89/logs/tempest.txt.gz#_2015-02-17_15_38_09_714 in our logs02:54
morganfainberg(see req-eblah blah blah)02:54
ayoungif the JSON is crap, would we still want a unique request id?02:54
ayoungor would we just kick it back02:54
*** browne has quit IRC02:54
*** lhcheng_afk has quit IRC02:54
morganfainbergayoung, json_body happens after auth.02:54
ayoungI think after JSON makes sense...02:54
morganfainbergmy only questions was do we need auth failures to have a unique id02:54
ayoungmorganfainberg, so what02:54
mtreinishmorganfainberg: well the keystone logging is the next part. I still need to figure out to teach the context class to use it02:54
*** browne has joined #openstack-keystone02:54
*** browne has quit IRC02:54
mtreinishthe oslo docs are bit sparse (ie non existent)02:55
morganfainbergmtreinish, :( yeah. digging into oslo.messaging it's been "exciting"02:55
mtreinishmorganfainberg: I would think so, so you can track down the failure in the logs easily02:55
morganfainbergnot bad.02:55
morganfainbergjust exciting02:55
ayoungwhat do we need the request id for?  A failure seems to be not so important here02:55
morganfainbergayoung, i'd be ok with it as is, but if we'd want unique ids on failed auth - we should move it. i'm just amking sure we're not missing something crazy by putting it later in the pipeline02:56
ayoungwe want to track something across multiple services, the failure means it is not recognized by the remote service as a valid request.  OK.  No big deal...what are we using the ids for?  Audit?02:56
morganfainbergayoung, the unique id is only per-service today, we don't unify them [yet] i don't think02:57
morganfainbergsome work has to be done in session to do something about that i think02:57
mtreinishayoung: it's super useful for debugging if you've got multiple concurrent requests being able to map them to the incoming call is kinda important02:57
morganfainbergmtreinish, am i wrong that we keep unified Ids across services now?02:57
morganfainbergmtreinish, because i'd be happy to be wrong there ;)02:57
mtreinishmorganfainberg: yeah there was a bp for it at one point, but I think it lost momentum02:58
morganfainbergmtreinish, ok02:58
morganfainbergso this is a unique id that doesn't persist outside of keystone02:58
mtreinishit would be really nice to have02:58
morganfainbergif the auth failure was maintained across services in a single request i think it being earlier would be very good02:58
ayoungmtreinish, I'm OK with you ignoring my comment if I have a bad assumption02:58
morganfainberganyone who goes over sizelimit can suck it :P02:58
ayoungafter url_normalize is OK, though?02:59
morganfainbergi think so02:59
ayoungmtreinish, comment rescinded02:59
morganfainbergif the url_normalization is bad i am happy to tell somebody we don't care. thats just malicious02:59
morganfainbergor so broken03:00
morganfainbergmtreinish, so let me respin this to undo that and i'll +2 and ayoung can too03:00
morganfainbergmtreinish, and we'll approve [unless you want to move it around]03:00
ayoungyeah, happy to do so03:00
morganfainbergmtreinish, but this is a case i don't want you to have to since it was 2-cores disagreeing :)03:00
morganfainbergnot fair to make ya do it03:00
morganfainbergin fact... doing it myself now03:00
mtreinishmorganfainberg: no you can go ahead and respin03:01
mtreinishit's 10pm here and I'm a few beers in, so I'd probably screw it up...03:01
openstackgerritMorgan Fainberg proposed openstack/keystone: Add oslo request id middleware to keystone paste pipeline  https://review.openstack.org/15590103:01
morganfainbergmtreinish, +2, and respun03:03
morganfainbergback to patchset 203:03
mtreinishmorganfainberg: cool, thanks03:03
morganfainberglike i said, not fair if one core says do X and another says do Y03:03
morganfainbergwe should resolve that03:03
morganfainbergayoung, hah beat me to kicking the WebSSO thing through to the gate03:05
morganfainbergayoung, ws looking at it and then hit refresh, oh look +A03:06
morganfainberganyway it looks pretty good, nothing but nits if anything03:06
mtreinishmorganfainberg: heh, that's pretty normal :)03:06
stevemarrequest id eh03:07
morganfainbergstevemar, yeah03:07
morganfainbergyou know those cool things that help trace actions through logs03:07
*** markvoelker has joined #openstack-keystone03:08
stevemari don't, but lets pretend that i do03:08
*** MasterPiece has quit IRC03:11
*** _cjones_ has quit IRC03:14
*** samueldmq has joined #openstack-keystone03:19
*** ccard__ has joined #openstack-keystone03:31
dolphmlbragstad: i can't think of a reason for the token format / version / whatever to prefix the new tokens, since they need to be validated online anyway (only keystone needs to validate them, not auth_token). and the version thing, while useful, belongs as the first part of the ciphertext / msgpack'd piece so it's integrity can be verified03:32
ayoungjamielennox, so...the V3AccessInfo interface assumes it got the ['token'] portion of the response, which does not include oauth data03:32
lbragstaddolphm: yes, that's correct03:32
ayoungjamielennox, or the trust data03:33
lbragstadI think when this was planned out, people wants a way to make sure we were confined to a format03:33
jamielennoxayoung: really?03:33
lbragstadI believe nonameentername had raised that concern03:33
jamielennoxayoung: i think there was trust information in v3 access info03:33
ayoungjamielennox, it seems to be the case03:33
ayoungits one level up03:34
dolphmlbragstad: confied?03:34
dolphmlbragstad: confined*?03:34
*** ccard_ has quit IRC03:34
lbragstadyeah, I can't recall the exact reason but I thought that was it03:34
lbragstadjacorob: you around?03:34
dolphmlbragstad: next up, i can't think of a reason to include the 'issued_at' timestamp because it's already part of fernet's algorithm03:36
ayoungjamielennox, let me confirm03:36
lbragstaddolphm: the only reason I can think of why we need that in there is because we need to have a way to pull out the created at time for revocation events03:36
ayoungjamielennox, so we have no trust or oauth tokens in here http://git.openstack.org/cgit/openstack/python-keystoneclient/tree/examples/pki/cms03:37
ayoungthat seems like an oversite03:37
ayounger oversight03:37
jamielennoxayoung: :(03:37
dolphmlbragstad: hmmmmmmm03:37
dolphmlbragstad: when you decrypt, you give the max token lifespan, as crypto.decrypt(ciphertext, ttl=CONF.token.expiration) ... there must be another (hazmat layer) API call to fetch the create date out?03:38
ayoungwe broke the links!03:39
lbragstaddolphm: we do that on decrypt?03:39
dolphmlbragstad: we can / should03:40
lbragstaddolphm: I thought we just passed the created at and expires at time03:40
morganfainbergayoung, yep03:40
morganfainbergayoung, there is a reason for that03:40
morganfainbergayoung, don't use identity-api repo.03:40
ayoungmorganfainberg, we broken all options03:40
morganfainbergit wasn't maintained and people were wrongly filing bugs against it03:40
ayoungthe link was from the public site03:41
ayoungit was a link to the identity7 api repo03:41
morganfainbergwe need to update that link then03:41
morganfainbergto the correct / maintained version03:41
morganfainbergayoung, that still loads for me03:42
ayoungmorganfainberg, it doesn't matter:  I think we fail to documkent where oauth data should be in the token anyway03:42
dolphmlbragstad: worst case (if we want to stick to the recipes layer), we can have the revocation event api call decrypt() again with a tighter ttl (that of an otherwise-matching revocation event), but that would be gross03:42
ayoungthe reading of the spec is ambiguous enought:03:42
ayoungit just says in the token data.03:42
lbragstaddolphm: yeah, I could see where that might be misleading03:43
dolphmlbragstad: according to the fernet spec, the create timestamp should just be ... encrypted[9:9+64]03:43
morganfainbergdolphm, thats the fernet one?03:43
dolphmmorganfainberg: yes03:43
ayoungjamielennox, OK....I think we got it for trusts, though. and it is inside the "token" section03:43
dolphmlbragstad: i'm probably off by one... [8:8+64]03:44
jamielennoxayoung: isn't token the outer layer for v3 tokens?03:44
*** spandhe has joined #openstack-keystone03:44
ayoungI'll link to the review...maybe I have bad logic03:44
ayoungjamielennox, https://review.openstack.org/#/c/138519/12/keystoneclient/models/builder.py,cm03:45
morganfainbergayoung, the attic one is very much out of date03:45
ayoungor better yet03:46
morganfainbergayoung, http://specs.openstack.org/openstack/keystone-specs/api/v3/identity-api-v3-os-trust-ext.html#consuming-a-trust is the one you're looking for to include any new spec stuff03:46
morganfainbergsuch as redelegation03:46
ayoungdef _build_token_values_v3(self, token_data)03:46
*** tqtran has quit IRC03:47
ayoungmorganfainberg, actually, I wanted the /identity-api.html,  but close enough03:47
ayoungas I wanted what we actually showed in the complete tokne03:47
*** spandhe_ has joined #openstack-keystone03:47
jamielennoxayoung: you sure you want this in client? how about keystone-common as a library?03:48
ayoungjamielennox, I want keystone-common as a library03:48
ayoungbut I'm learning a metric ton about how the client is using it.03:48
*** spandhe has quit IRC03:48
*** spandhe_ is now known as spandhe03:48
ayoungand that is catching alot of my errors03:49
dolphmlbragstad: actually i think the timestamp is base64.urlsafe_b64decode(encrypted)[1:8] (but that's still just bytes)03:49
jamielennoxayoung: awesome03:50
ayoungjamielennox, I wouldn't have caught this one if not for the client...03:50
ayoungI've backed off on tryiung to use it for V2 tokens03:50
ayoungprobably should chop that code out completely for the first round03:51
ayoungbut we'll need it for enforcing policty...which is why I origianlly did all this03:51
* ayoung goes looking for a brick wall in his house03:51
lbragstaddolphm: dumb question, is the time stamp an int?03:52
lbragstador a string?03:52
dolphmlbragstad: i'm trying to figure that out03:53
dolphm>>> bytes(base64.urlsafe_b64decode(encrypted)[1:8])03:53
dolphmor maybe i need to decode the whole thing first :P03:54
dolphmoh wait, i am03:54
dolphmbase64.urlsafe_b64decode(encrypted)[0:1] comes out as expected: the fernet version 0x80 (the first and only version)03:54
*** stevemar has quit IRC03:55
*** stevemar has joined #openstack-keystone03:55
*** ChanServ sets mode: +v stevemar03:55
*** himangi has quit IRC03:55
dolphmlbragstad: Timestamp: This field is a 64-bit unsigned big-endian integer. It records the number of seconds elapsed between January 1, 1970 UTC and the time the token was created.04:00
*** chrisshattuck has joined #openstack-keystone04:00
lbragstaddolphm: sweet04:00
dolphmlbragstad: YAY04:04
dolphmlbragstad: >>> print(datetime.datetime.fromtimestamp(struct.unpack(">Q", str(base64.urlsafe_b64decode(encrypted)[1:9]))[0]).strftime('%Y-%m-%d %H:%M:%S'))04:04
dolphm2015-02-24 03:35:0304:04
dolphmlbragstad: it's 4:04 UTC now, so that means it almsot took me 30 minutes to figure out how to do that04:04
lbragstaddolphm: lol, that string needs a comment04:05
dolphmlbragstad: i can do that one sec04:05
dolphmlbragstad: # base64 decode the ciphertext and slice the 8-byte timestamp, starting from the second byte, unpacking it into an unsigned long-long, and string format it into a human-recognizable datetime of the token's creation time04:08
dolphmyou can also simplify it to:04:08
dolphmprint(datetime.datetime.fromtimestamp(struct.unpack(">Q", base64.urlsafe_b64decode(encrypted)[1:9])[0]).strftime('%Y-%m-%d %H:%M:%S'))04:08
ayoungmorganfainberg, which hotel did you end up going with.  I just realized I have not reserved yet04:08
lbragstaddolphm: +204:09
lbragstaddolphm: works for me!04:09
dolphmlbragstad: i wouldn't consider that to be toooooo hazmatty04:09
dolphmjust make sure you slice the correct bytes04:10
dolphmlbragstad: rip out those create times!04:10
stevemardolphm, go home04:11
dolphmstevemar: i... already am home04:11
stevemarmorganfainberg, so what's on the chopping block for tomorrow?04:11
stevemardolphm, but are *home*04:11
stevemarare you*04:11
dolphmstevemar: i... was?04:12
* lbragstad is lost04:13
stevemardolphm, keystone has missed the dolphinator04:14
*** harlowja is now known as harlowja_away04:14
*** harlowja_away is now known as harlowja04:15
morganfainbergstevemar, i haven't looked at the specs yet04:15
morganfainbergayoung, uh04:16
morganfainbergayoung, waterfront?04:16
morganfainbergi might be changing to a westin though04:16
dolphmstevemar: lol *hugs*04:16
openstackgerritMerged openstack/keystone: Add WebSSO support for federation  https://review.openstack.org/13617704:16
morganfainbergbut haven't thought much about it04:16
ayoungstevemar, dolphm lbragstad you guys picked a hotel yet?04:16
dolphmayoung: yeah, uhh04:16
* morganfainberg needs to book flights04:17
*** devlaps has joined #openstack-keystone04:17
morganfainbergbut that is a bigger deal.04:17
morganfainbergdevlaps, shouldn't you be at home w/ your family or something? ;)04:17
stevemarDelta Vancouver Suites Hotel04:17
*** ajayaa has joined #openstack-keystone04:17
stevemarayoung, ^04:17
devlapsi am. at home and coding :)04:17
stevemar550 West Hastings St, Vancouver CA04:18
morganfainbergdevlaps, but not hacking on keystone :( i see how it is.. you don't <3 us anymore04:18
devlapsmortganfainberg: that can be fixed :) plenty of keystone <304:18
morganfainbergso hack on some keystone code!04:18
dolphmayoung: i, uhh, made an excel https://docs.google.com/spreadsheets/d/16Y4yvjqG19PIXIsPTZYu4gv_SMT9ZiJHQaOaqPwyDjM/edit?usp=sharing04:19
morganfainbergooh that reminds me need to book hotel for april thing04:19
devlapsmorganfainberg: will do :)04:19
morganfainbergoh fun04:20
morganfainbergi get to go to DC april 26 and 27 i think04:20
*** MasterPiece has joined #openstack-keystone04:20
stevemardolphm, i feel that excel is overly detailed04:21
*** samueldmq has quit IRC04:22
stevemardolphm, unless you are bringing a pet, i feel a pet column is not needed04:23
dolphmstevemar: people might have allergies in places where pets are allowed04:23
dolphmstevemar: i was considerate04:23
stevemarthis is hilarious04:23
morganfainbergdolphm, 70ft yact?04:23
dolphmmorganfainberg: that was the original goal04:24
morganfainbergbut no internetz04:24
*** radez is now known as radez_g0n304:24
morganfainbergnow i feel like i need to switch and get the 70ft yact... :P04:25
ayoungdolphm, very nice...04:25
stevemardelta suites is 10 min walk04:25
ayoungI just wanted an indoor ppol04:25
dolphmstevemar: why walk when a yacht can drop you off at the convention center04:25
stevemardolphm, you have a good point there04:26
dolphmayoung: why have an indoor pool when you can have an outdoor ocean?04:26
stevemarexcellent points all around04:26
morganfainbergthe real winner: https://www.airbnb.com/rooms/5067214?checkin=05%2F17%2F2015&checkout=05%2F23%2F2015&guests=5&s=rZnE04:26
stevemarformer mayor04:26
ayoungbecause it is Canada and don't think I want to swim in the Ocean that far north in May.  Even late may.04:27
morganfainbergayoung, def. not on the west coast04:27
morganfainbergon the east coast... it's warmer...04:27
ayoungmorganfainberg, no sufficiently to make a difference04:27
dolphmmorganfainberg: and that includes insurance04:27
*** ajayaa has quit IRC04:28
morganfainbergayoung, people regularly swim maine and north... late may wouldn't be awful. people don't swim in SoCal even most of the summer w/o wet suits04:28
morganfainberguntil you're down in like San Diego04:28
*** richm has quit IRC04:28
morganfainbergthe water is way warmer on the east coast than here04:29
morganfainbergonly $8217/night too04:29
stevemaroh jeez04:29
stevemarthat airbnb is crazy04:30
*** lhcheng_afk has joined #openstack-keystone04:30
morganfainberg6524.54 USD / night [assuming the 8k is CAD]04:30
*** lhcheng_afk has quit IRC04:30
morganfainberg815 a night if all beds are full (8) / person [USD]04:30
dolphmmorganfainberg: all prices are USD04:30
*** lhcheng_afk has joined #openstack-keystone04:31
morganfainbergso 1088 / night?04:31
morganfainbergwow CAD is really .8 USD04:31
*** csoukup has joined #openstack-keystone04:32
morganfainbergit wasn't that long ago it was almost 1:104:32
morganfainbergi love that Oriana is "relocateable"04:32
dolphmmorganfainberg: the harbor is actually damn near the convention center already04:33
morganfainbergi know04:33
dolphmmorganfainberg: i also found one in seattle that was willing to relocate04:33
ayoungDid you know that if you die in Canada you die in real life?04:37
lbragstadayoung: no hotel yet04:37
*** markvoelker has quit IRC04:39
*** markvoelker has joined #openstack-keystone04:39
ayounghttp://xkcd.com/195/  there is no green left now04:40
*** ayoung has quit IRC04:43
*** ccard_ has joined #openstack-keystone04:43
*** markvoelker has quit IRC04:44
*** ccard__ has quit IRC04:45
dolphmmorganfainberg: the Oriana also includes two Marquipt hydraulic 3500 lb. capacity cranes04:45
morganfainbergi don't know what i'd do with those04:46
morganfainbergbut.. something?04:46
dolphmmorganfainberg: well then may i sell you on the 10 cu. ft bar refrigerator and Mansfield vacuum toilet system?04:46
dolphmmorganfainberg: i wonder if the microwave interferes with the Simrad flybridge radar system04:47
dolphmi need a 16" hydraulic bow thruster in my life04:48
jamielennoxdolphm: why do you care about pets04:52
dolphmjamielennox: allergies04:52
jamielennoxoh these are mostly airbnbs04:53
dolphmjamielennox: all but 4 or 504:53
dolphmjamielennox: was looking for a better value than hotels04:53
jamielennoxapparently not having modify permissions means you can't change the size of columns so couldn't tell04:53
*** krtaylor has quit IRC04:55
*** spandhe has quit IRC04:59
*** MasterPiece has quit IRC05:00
jamielennoxstevemar: so if the federation stuff you are doing is just CRUD based you can probably do it in regular ksc05:00
stevemarjamielennox, oh hai05:03
*** ajayaa has joined #openstack-keystone05:04
stevemarjamielennox, basically i just need to post something to /auth/os-federation/saml05:04
stevemar+ service provider CRUD (but that's unrelated)05:04
jamielennoxi think that stuff is ok in ksc05:05
jamielennoxwe don't have an extensions mechanism05:05
jamielennoxand i don't want to start doing managers and stuff outside05:05
*** krtaylor has joined #openstack-keystone05:07
*** c_soukup has joined #openstack-keystone05:09
stevemarjamielennox, yeah the manager bits were making me wary of adding to ksc-federation05:09
*** csoukup_ has joined #openstack-keystone05:10
*** markvoelker has joined #openstack-keystone05:10
*** csoukup has quit IRC05:13
*** c_soukup has quit IRC05:14
*** krtaylor has quit IRC05:14
*** lhcheng_afk has quit IRC05:15
*** devlaps has quit IRC05:17
*** MasterPiece has joined #openstack-keystone05:17
*** markvoelker has quit IRC05:17
openstackgerritSteve Martinelli proposed openstack/keystone: Cleanup policy related bits in tests  https://review.openstack.org/15856105:20
openstackgerritSteve Martinelli proposed openstack/keystone: Remove policy parsing exception  https://review.openstack.org/15856205:22
*** krtaylor has joined #openstack-keystone05:26
*** csoukup_ has quit IRC05:32
*** jamielennox is now known as jamielennox|away05:33
*** chrisshattuck has quit IRC05:33
*** jamielennox|away is now known as jamielennox05:34
*** lhcheng_afk has joined #openstack-keystone05:34
openstackgerritSteve Martinelli proposed openstack/keystone: Get initiator from manager and send to controller  https://review.openstack.org/15566005:42
openstackgerritSteve Martinelli proposed openstack/keystone: Add CADF notifications for trusts  https://review.openstack.org/15186705:42
openstackgerritSteve Martinelli proposed openstack/keystone: Emit failure notifications for CADF audits events  https://review.openstack.org/15690505:42
morganfainbergstevemar, you have no idea how much i hate passing info to methods just so a decorator can consume it05:43
morganfainbergstevemar, i think we're doing something horribly wrong if that is a pattern05:43
stevemarmorganfainberg, i equally hate it and think it's silly as balls05:43
morganfainbergstevemar what was the result w/ bkudson and thread.local05:43
stevemarbut the only option was equally hated05:43
stevemarhe hatd it05:43
morganfainbergbecause tbh, i want to say no on principle on the current thing05:43
morganfainberglike remove the decorators level of no05:43
stevemari'm kinda stuck here05:44
morganfainbergand emit directly from the controller05:44
morganfainbergnot the manager.05:44
stevemarmorganfainberg, we could do that05:44
morganfainbergi think this is a sign the decorators do not work for us05:44
stevemarit's forcing a puzzle piece to fit05:45
morganfainbergis my issue. if you are passing data into a method so a decorator can use it, you're doing it wrong.05:45
stevemari 100% agree05:45
stevemarbut it's the only way to get the darn data05:45
morganfainbergso either we use initiator for emit in the methods05:45
morganfainbergor we thread.local it05:45
morganfainbergso, i'd just rip the decorators out and make the methods emit the notifications directly05:45
morganfainbergat least it'd be easier to follow. and it open the door to do smarter (not only at start/end) notifications05:46
morganfainbergso, instead of decorator, use a direct emit call in the manager method.. probably the cleanest option05:46
stevemari want my stuff in first :)05:46
stevemarthen refactor05:46
morganfainbergstevemar, i'm not ok with this impl.05:46
stevemarbut i understand if that isn't good05:47
morganfainbergstevemar, i'll help you do this if you need05:47
stevemarthat'd be great05:47
morganfainbergcan probably whip up the change tonight after food.05:47
stevemarsure, we can iterate on it together05:47
morganfainbergthen we can add the initiator / stuff after on top05:47
morganfainbergbtw, you know if we move to pecan we get the thread.local for free >.>05:48
morganfainbergbecause thats just how it works05:48
stevemari'm switching through too many things right now, the mental context switching is kicking my ass05:48
morganfainbergok i'll propose a couple changes for notifications tonight and rebase your stuff on top of it if i can05:48
morganfainbergdepending on tired05:49
morganfainbergvs not tired05:49
stevemarokay, i'll be up a few more hours anyway, gotta do a few more things by tomorrow05:49
morganfainbergi wont be starting for an hour or so.05:49
morganfainbergneed fooodz05:49
morganfainbergtime for pizza05:49
morganfainbergstevemar, yeah sorry man. this just an absolutely awful pattern i don't want to encourage. if we're doing it this way we're def. doing it wrong :{05:50
stevemarno, it05:50
stevemarit's fine05:50
stevemarjust getting antsy to get stuff finished before ff05:51
morganfainbergstevemar, can i get https://review.openstack.org/#/c/155901/ a +2/+a on that?05:51
morganfainbergshould be easy05:51
*** atmark1 has left #openstack-keystone05:54
openstackgerritOpenStack Proposal Bot proposed openstack/keystone: Imported Translations from Transifex  https://review.openstack.org/15857206:04
stevemari bet openstack proposal bot has so many commits, probably not much of a reviewer though06:05
stevemarjamielennox, also about the samlize token for ksc, you okay with having token_id as one of the arguments?06:06
stevemari am wondering if it's better to dig that out of the auth_ref06:07
morganfainbergjamielennox: not sure why -kerberos is broken in pypi. Might ask you to make me an owner so I can poke it with a stick.06:07
jamielennoxi don't see how it's much better06:07
jamielennoxmorganfainberg: sure06:08
morganfainbergGonna bug infra more about it tmrrow.06:08
morganfainbergIn either case.06:08
jamielennoxmorganfainberg: pypi username?06:08
morganfainbergUhm.  Uhhhhhh06:08
jamielennoxstevemar: i think token_id is better06:08
jamielennoxmarginally but whatever06:09
morganfainbergLook at kite, I should be an owner. Mdrnstm maybe?06:09
jamielennoxdid we release kite06:09
jamielennoxhttps://pypi.python.org/pypi/kite - 40406:09
jamielennoxwe should reserve that06:09
jamielennoxone of these days i want to finish it06:09
morganfainbergKite client.06:09
morganfainbergThat one I know I registered.06:09
jamielennoxmorganfainberg: gave you owner on -kerberos06:10
*** harlowja is now known as harlowja_away06:11
*** markvoelker has joined #openstack-keystone06:13
jamielennoxServer response (403): You are not allowed to store 'kite' package information06:13
jamielennoxif kite exists why do i get 404 on /pypi/kite?06:14
*** _cjones_ has joined #openstack-keystone06:14
jamielennoxkite exists on the index page: https://pypi.python.org/simple/ with no information - and a dead link06:16
jamielennoxgogo pypi UI06:16
*** lhcheng_afk has quit IRC06:17
*** markvoelker has quit IRC06:17
*** _cjones_ has quit IRC06:20
marekdmorganfainberg: looking at the patch.06:38
openstackgerritSteve Martinelli proposed openstack/keystone: Revamp the documentation surrounding notifications  https://review.openstack.org/12618006:39
openstackgerritSteve Martinelli proposed openstack/keystone: Get initiator from manager and send to controller  https://review.openstack.org/15566006:41
openstackgerritSteve Martinelli proposed openstack/keystone: Emit failure notifications for CADF audits events  https://review.openstack.org/15690506:41
openstackgerritSteve Martinelli proposed openstack/keystone: Revamp the documentation surrounding notifications  https://review.openstack.org/12618006:41
openstackgerritSteve Martinelli proposed openstack/keystone: Add CADF notifications for trusts  https://review.openstack.org/15186706:41
morganfainbergstevemar, so06:42
stevemarmorganfainberg, hola06:42
morganfainbergstevemar, only question i have is... what is your feeling on naming of these new notiiers06:42
stevemarmorganfainberg, i don't care06:42
morganfainbergi can do one of two things... 1: make a magic wrapper that makes it so you can call it either as decorator or function.. oor06:43
stevemar(not trying to sound snippy)06:43
morganfainbergfind some random name :P06:43
stevemarmorganfainberg, i'd like it if audit was in the name06:44
stevemaraudit_event, audit notification06:44
morganfainbergso .. instead of notifications.created, notifications.audit_created ?06:44
openstackgerritSteve Martinelli proposed openstack/keystone: Add documentation for key terms and basic authenticating  https://review.openstack.org/15201806:46
stevemarmorganfainberg, shoot i'd like it to be just in audit.py (so it's called as audit.created) but i think that'll be too hard06:47
morganfainbergactually. hm.06:47
stevemarnotifications.audit_created would work for me06:47
morganfainbergi think thats doable.06:48
morganfainbergi think i'm going to keep it notifications for this change we can move it later if needed06:48
*** rushiagr_away is now known as rushiagr06:49
*** lhcheng_afk has joined #openstack-keystone06:49
stevemarmorganfainberg, makes sense06:50
openstackgerritSteve Martinelli proposed openstack/keystone: Classifying extensions and defining process  https://review.openstack.org/14679306:57
openstackgerritSteve Martinelli proposed openstack/keystone: Add links to extensions that point to api specs  https://review.openstack.org/14731106:58
openstackgerritMarek Denis proposed openstack/keystone: Implements whitelist and blacklist mapping rules  https://review.openstack.org/14257306:58
*** lhcheng_afk has quit IRC07:04
*** MasterPiece has quit IRC07:09
marekdmorganfainberg: how heavily are we relying memcached now? (are we trying to cache as much as possible?)07:16
morganfainbergmarekd, uhm07:16
morganfainbergmarekd, only when it's turned on07:16
morganfainbergmarekd, and configured07:16
morganfainbergmarekd, some things but not everything07:16
marekdand sqlalchemy has some internal caching layer ?07:17
morganfainbergmarekd, eh, kindof, but usually you layer dogpile in directly as well07:18
*** mzbik has joined #openstack-keystone07:19
morganfainbergi think07:19
*** xavpaice has joined #openstack-keystone07:25
*** MasterPiece has joined #openstack-keystone07:26
stevemarjamielennox, can you update https://blueprints.launchpad.net/keystone/+spec/unscoped-catalog - i think it's done?07:34
*** chlong has quit IRC07:34
stevemaror if it's targeted to a release or not07:34
marekdstevemar: https://review.openstack.org/#/c/126180/14..16/doc/source/event_notifications.rst,cm where is event_type here?07:41
stevemarline 4207:42
*** rushiagr is now known as rushiagr_away07:42
stevemaralso lines 226, 270, 313, 36807:42
openstackgerritAbhishek Kekane proposed openstack/keystone: Eventlet green threads not released back to pool  https://review.openstack.org/13082407:43
marekdstevemar: ah, thanks. Gerrit hid it from me and I didn't expand full page.07:43
stevemarmarekd, s'all good07:43
morganfainbergstevemar, almost have the additional notifiers in place07:44
morganfainbergstevemar, running tests now.07:44
openstackgerritMerged openstack/keystone: Add oslo request id middleware to keystone paste pipeline  https://review.openstack.org/15590107:52
stevemarmorganfainberg, ++08:02
morganfainbergstevemar, ok having a test issue.08:07
morganfainbergstevemar, posting the code while i hunt why this isn't working.08:07
openstackgerritMorgan Fainberg proposed openstack/keystone: Add in non-decorator notifiers  https://review.openstack.org/15860008:07
morganfainbergstevemar, it's not calling the callbacks :(08:09
stevemarmorganfainberg, i don't think you want the internal classmethod there, since it's internal and not worth auditing08:11
morganfainbergyah probably08:11
stevemarthe callbacks are tricky08:11
morganfainbergi know... i wrote a bunch of that code :P08:11
morganfainbergor re-wrote it08:11
stevemardidn't want to place these at the controller level and keep them decorator?08:16
stevemarthat way we get context08:16
morganfainbergbecause the controllers could call many things on maangers08:16
morganfainbergthis way we always catch the events, you can't "go around" a controller08:17
morganfainbergok this is wierd08:22
morganfainbergit's not looping through the subscribers...08:22
openstackgerritMerged openstack/keystone: Imported Translations from Transifex  https://review.openstack.org/15857208:22
morganfainbergthe dict looks correct...08:23
morganfainbergoh derp08:25
*** henrynash has joined #openstack-keystone08:29
*** ChanServ sets mode: +v henrynash08:29
morganfainbergstevemar, ^^08:30
openstackgerritMorgan Fainberg proposed openstack/keystone: Add in non-decorator notifiers  https://review.openstack.org/15860008:30
morganfainbergerm that one08:30
stevemarhehe, that was derpy08:32
morganfainbergstevemar, going to rebase your non-doc changes on this one. but not doc ones, those should prob not be inline unless they need to be08:32
morganfainbergstevemar, do they need to be?08:32
morganfainbergs/inline/in the chain08:33
stevemarthere's only 1 doc one, the chained up ones should be merged on top08:33
morganfainbergso i should rebase mine on your doc one?08:33
morganfainbergthen yours on this one?08:33
morganfainbergor well, guess that doesn't matter much08:33
stevemarmorganfainberg, the doc one can go in solo, no big deal there08:35
morganfainbergok i will let the doc one stay as is then08:35
stevemarmorganfainberg, i'm confused on how this will handle the case where the operation fails, i guess wrap things in a try/catch08:36
stevemarerrr try/except08:36
morganfainbergstevemar, currently we don't emit a cadf for these on failure08:36
morganfainbergwe try/except and raise the execpt before notifications are sent08:36
morganfainbergoh https://review.openstack.org/#/c/156905/08:37
stevemarmorganfainberg, yep, i had a patch for.. yep08:37
stevemari think that was the one benefit of using decorators08:37
morganfainbergyeah but the pattern really makes my skin crawl08:38
stevemarbut tbh, that is value-add, the goal was parity with existing notifications08:38
morganfainbergso we can try/catch08:38
morganfainbergand do the same thing.08:38
morganfainbergit's not automatic08:38
stevemarjust change outcome08:38
morganfainbergtotally doable.08:38
stevemarso don't bother trying to rebase that one, unless you are feeling brave08:38
morganfainbergeh. i'll do that tmmrow08:38
morganfainbergthis one should be straight forward08:39
morganfainbergjust a bunch of things to change.08:39
morganfainbergbut still straight forward08:39
openstackgerritSteve Martinelli proposed openstack/keystone: Revamp the documentation surrounding notifications  https://review.openstack.org/12618008:39
stevemarrebased to master ^08:40
stevemarat least most of the work was good :P just the initiator08:40
stevemarwhich should also be enhanced to get the project id too...08:41
stevemarof the user08:41
*** pnavarro has joined #openstack-keystone08:51
*** jistr has joined #openstack-keystone08:54
openstackgerritSteve Martinelli proposed openstack/keystone: Enable endpoint_policy, endpoint_filter and oauth by default  https://review.openstack.org/15384208:56
stevemarmarekd, ^^ just a rebase08:56
marekdstevemar: re+2'd both patches. :-)08:57
*** swartulv has quit IRC09:04
marekdstevemar: still here?09:06
morganfainbergstevemar, so i think i have these done.09:06
marekdso, the remite_id must be unique and the only constraint is websso09:06
morganfainbergstevemar, i am going to push this, its been a lot of mucking around to get there.09:06
marekdremember that we get identity_provider object from remote_id09:06
stevemarmarekd, i'm here09:07
stevemarmorganfainberg, sounds good09:07
morganfainbergstevemar i apologize if i blow this one up :P09:08
stevemarmarekd, really it *must be* unique, bah09:08
openstackgerritMorgan Fainberg proposed openstack/keystone: Add in non-decorator notifiers  https://review.openstack.org/15860009:08
openstackgerritMorgan Fainberg proposed openstack/keystone: Get initiator from manager and send to controller  https://review.openstack.org/15566009:08
marekdstevemar: hm?09:08
stevemarmorganfainberg, i don't think you should have removed the decorators09:10
openstackgerritMorgan Fainberg proposed openstack/keystone: Get initiator from manager and send to controller  https://review.openstack.org/15566009:10
openstackgerritMerged openstack/keystone: Classifying extensions and defining process  https://review.openstack.org/14679309:10
morganfainbergstevemar, why?09:10
stevemarmorganfainberg, i thought the internal callbacks still needed them09:11
morganfainbergnope, just replaced all that09:11
morganfainbergthe internal callbacks are called via the same mechanism09:11
morganfainbergi just replicatdd the logic09:11
morganfainberghaving a decorator for the sake of a decorator is bad.09:11
morganfainberghave some bugs still in notifications not being sent. but imminently fixabler09:12
stevemari'll have to pull this down and play around09:13
morganfainbergbasically instead of having a notifier decorator, notifications are called directly inline09:13
morganfainbergof the function09:13
morganfainbergand there are some bugs to still squash in the testing, i'm seeing them go by09:14
stevemarmorganfainberg, found at least one mistake09:14
morganfainbergbut should be easy to fix09:14
morganfainbergyeah i needed to post to gerrit to move to my test vm09:15
stevemarkeystone/identity/core.py -> notifications._ACTIONS.deleted -> notifications.Audit.deleted09:15
morganfainbergthats the one i'm seeing mostly09:15
morganfainbergstevemar, have that fixed in the next patch09:16
morganfainbergjust waiting for tests to run locally09:16
*** markvoelker has joined #openstack-keystone09:17
*** karimb has joined #openstack-keystone09:21
*** markvoelker has quit IRC09:22
*** karimb has quit IRC09:23
*** aix has quit IRC09:25
*** karimb has joined #openstack-keystone09:27
openstackgerritMorgan Fainberg proposed openstack/keystone: Add in non-decorator notifiers  https://review.openstack.org/15860009:27
openstackgerritMorgan Fainberg proposed openstack/keystone: Get initiator from manager and send to controller  https://review.openstack.org/15566009:27
morganfainbergstevemar, ^^ fixed09:27
morganfainbergand passes all tests now09:27
morganfainbergstevemar, i'll rebase the failure one tomorrow and then deprecated the decorator versions09:29
*** henrynash has quit IRC09:30
stevemarmarekd, instead of adding us 1 at a time, type in keystone-core in gerrit ui :)09:31
stevemarmorganfainberg, i'll look at it tomorrow09:31
*** stevemar has quit IRC09:34
marekdstevemar, oh i didn't know that. Thanks!09:35
*** openstackgerrit has quit IRC09:36
*** openstackgerrit has joined #openstack-keystone09:36
*** himangi has joined #openstack-keystone09:40
*** nellysmitt has joined #openstack-keystone09:44
*** jaosorior has joined #openstack-keystone09:50
*** aix has joined #openstack-keystone09:52
*** harlowja_away has quit IRC10:04
*** himangi has quit IRC10:08
*** markvoelker has joined #openstack-keystone10:18
*** markvoelker has quit IRC10:23
openstackgerritMarco Fargetta proposed openstack/keystone: IdP ID registration and validation  https://review.openstack.org/15215610:23
*** fmarco76 has joined #openstack-keystone10:24
*** aix has quit IRC10:30
*** himangi has joined #openstack-keystone10:33
*** jamielennox is now known as jamielennox|away10:42
*** aix has joined #openstack-keystone10:43
*** jamielennox|away is now known as jamielennox10:58
*** himangi has quit IRC10:58
*** jamielennox is now known as jamielennox|away11:01
*** jamielennox|away is now known as jamielennox11:02
*** henrynash has joined #openstack-keystone11:02
*** ChanServ sets mode: +v henrynash11:02
*** jamielennox is now known as jamielennox|away11:08
*** jamielennox|away is now known as jamielennox11:10
*** markvoelker has joined #openstack-keystone11:19
*** dims has joined #openstack-keystone11:20
openstackgerritMarek Denis proposed openstack/keystone: Implements whitelist and blacklist mapping rules  https://review.openstack.org/14257311:21
*** markvoelker has quit IRC11:24
*** jamielennox is now known as jamielennox|away11:38
*** diegows has joined #openstack-keystone11:39
*** jamielennox|away is now known as jamielennox11:41
*** MasterPiece has quit IRC11:44
*** henrynash has quit IRC11:52
*** himangi has joined #openstack-keystone11:54
*** chlong has joined #openstack-keystone11:56
*** markvoelker has joined #openstack-keystone12:05
openstackgerritSamuel de Medeiros Queiroz proposed openstack/keystone: Exposes bug in SQL when honoring driver_hints  https://review.openstack.org/15841212:07
*** markvoelker has quit IRC12:11
*** henrynash has joined #openstack-keystone12:24
*** ChanServ sets mode: +v henrynash12:24
*** ajayaa has quit IRC12:31
*** amakarov_away is now known as amakarov12:35
openstackgerritAlexander Makarov proposed openstack/keystone: Fix for KVS cache backend incompatible with redis-py  https://review.openstack.org/15330712:35
openstackgerritRodrigo Duarte proposed openstack/keystone: Add is_domain field in Project Table  https://review.openstack.org/15742712:36
openstackgerritRodrigo Duarte proposed openstack/keystone: Change project name constraint  https://review.openstack.org/15837212:36
*** chlong has quit IRC12:44
openstackgerrithenry-nash proposed openstack/keystone: Refactor and provide scaffolding for domain specific loading  https://review.openstack.org/15770113:00
openstackgerrithenry-nash proposed openstack/keystone: Implement backend driver support for domain config  https://review.openstack.org/15805113:01
openstackgerrithenry-nash proposed openstack/keystone: Add support for whitelisting and partial domain configs  https://review.openstack.org/15867913:03
openstackgerrithenry-nash proposed openstack/keystone: Add support for whitelisting and partial domain configs  https://review.openstack.org/15867913:03
*** markvoelker has joined #openstack-keystone13:06
*** himangi has quit IRC13:09
*** markvoelker has quit IRC13:11
*** jamielennox is now known as jamielennox|away13:18
*** jamielennox|away is now known as jamielennox13:20
*** radez_g0n3 is now known as radez13:25
*** gordc has joined #openstack-keystone13:28
*** rushiagr_away is now known as rushiagr13:43
*** ioram has joined #openstack-keystone13:44
*** csoukup has joined #openstack-keystone13:50
openstackgerritAlexander Makarov proposed openstack/keystone: Chain a trust with a role specified by name  https://review.openstack.org/14864213:56
*** bknudson has joined #openstack-keystone13:57
*** ChanServ sets mode: +v bknudson13:57
*** radez is now known as radez_g0n313:59
*** richm has joined #openstack-keystone14:00
*** markvoelker has joined #openstack-keystone14:07
*** richm has quit IRC14:08
*** dims has quit IRC14:13
*** dims has joined #openstack-keystone14:13
*** nkinder has quit IRC14:18
*** mzbik has quit IRC14:19
ccardI have keystone set up with domain-specific configuration, with one domain (testdomain1) using LDAP as the identity backend, while the default domain is using the sql backend. The "openstack user list --domain testdomain1" command works ok, and shows the users from the LDAP backend. I have also created a project (testproject1) in the testdomain1 domain ok. But if I try to do "openstack role add --domain testdomain1 --user <user> _member_" or14:23
ccard"openstack role add --project testproject1 --user <user> _member_" I get the error message "ERROR: openstack The request you have made requires authentication. (HTTP 401)". Any ideas?14:23
ccard(This is Juno)14:23
*** joesavak has joined #openstack-keystone14:25
*** ljfisher has joined #openstack-keystone14:25
rodrigodshenrynash, makes sense to call list_projects_in_subtree(None) ?14:26
henrynashrodigods: what’s the context?14:27
rodrigodshenrynash, was thinking if we could return all hierarchies14:28
*** nellysmitt has quit IRC14:28
rodrigodsso we'd need to pass project_id=None to list_projects_in_subtree()14:28
*** nellysmitt has joined #openstack-keystone14:29
*** nellysmitt has quit IRC14:29
rodrigodsI'm thinking about not allowing it, raising an exception if it is being called with project_id=None14:29
*** nellysmitt has joined #openstack-keystone14:29
henrynashrodigods: what would be the difference from that and just list_projects()14:29
rodrigodshenrynash, no difference, actually14:30
rodrigodswould be just a really expensive list_projects() :P14:30
henrynashrodigods: sounds like there isn’t probaly a reason to support it14:30
henrynashrodigods: and we want to avoid given people the chance to issue dumb commands :-)14:31
rodrigodshenrynash, great :)14:31
rodrigodsthanks henrynash14:31
*** markvoelker has quit IRC14:32
*** markvoelker has joined #openstack-keystone14:33
*** ayoung has joined #openstack-keystone14:37
*** ChanServ sets mode: +v ayoung14:37
*** markvoelker has quit IRC14:38
*** abhirc has joined #openstack-keystone14:38
*** abhirc has quit IRC14:39
*** joesavak has quit IRC14:41
openstackgerritAlexander Makarov proposed openstack/keystone: Correct initialization order for logging to use eventlet locks  https://review.openstack.org/15491514:44
amakarovbknudson, greetings! I've tried to invent a solution for initialization order, please look here ^^.14:48
bknudsonamakarov: seems way more complicated than necessary.14:51
amakarovbknudson, just wrote that I fear it too much for the issue :)14:51
*** nkinder has joined #openstack-keystone14:52
amakarovand also I think passing a special function to another function slowly turns code to a mess...14:53
*** joesavak has joined #openstack-keystone14:53
*** nellysmitt has quit IRC14:55
amakarovbknudson, I can just follow your suggestion in the comment in hope of future refactoring14:55
bknudsonamakarov: y, it will. Eventually the functions can be put into a class, where the base class provides methods that can be overridden.14:55
bknudsonthat would be a useful refactoring.14:56
amakarovbknudson, ok, let's put it that way14:56
bknudsonamakarov: you can see setup_backends does something similar... passing in methods... so those could be abstract methods instead.14:57
bknudsonI thought this file was larger so it would be more work to create a class but it's actually only a couple of functions.14:57
amakarovbknudson, I understand it. Do we need a class that does _all_ the initialization with abstract overridables for specific parts?14:59
bknudsonamakarov: maybe... I think you'll find out when you create the class.15:00
amakarovbknudson, got it15:01
openstackgerritRodrigo Duarte proposed openstack/keystone: Fixes some HMT internal calls  https://review.openstack.org/15872015:06
rodrigodshenrynash, ayoung, ^ found some bugs in the already merged HMT code while implementing the new features15:06
ayoungrodrigods, point of process:  can you try to make the change description more specific?15:07
ayoung" Fixes some HMT internal calls"  seems to say "I've lumped a bunch of changes together"15:07
rodrigodsayoung, absolutely...15:07
ayoungand someone is going to  say "split the patch"15:07
ayounginstead say what you've fixed15:08
ayoungrodrigods, I'm on information overload.  Anything you do that helps me context switch is greatly appreciated15:08
*** joesavak has quit IRC15:08
rodrigodsayoung, I understand, thanks for the feedback15:08
openstackgerritMerged openstack/keystone: Remove invalid comment/statement at role manager  https://review.openstack.org/15802915:11
*** joesavak has joined #openstack-keystone15:12
bretonyes, that was me who said "split the patch"15:13
openstackgerritMerged openstack/keystonemiddleware: Updated from global requirements  https://review.openstack.org/15777015:14
marekdGod bless UTF-815:14
*** sigmavirus24_awa is now known as sigmavirus2415:16
*** nellysmitt has joined #openstack-keystone15:18
marekdwhile runnin unit tests a setUp() method is ran before every question, right?15:20
bknudsonmarekd: the test setUp runs before every test_ method.15:21
marekdbknudson: thank you.15:21
bknudsonwe seem to have very large setUps in our tests.15:22
ayoungHey.... I just learned that /whois for a nick will list the channels that person is in15:22
*** jsavak has joined #openstack-keystone15:23
*** devlaps has joined #openstack-keystone15:24
*** devlaps has quit IRC15:24
marekdbknudson: that's true. and of course every test_* method starts with a 'fresh database' populated by setUp() ?15:24
bknudsonmarekd: yes, and then there's the generic user / project / role fixtures that get loaded for almost every test.15:25
*** joesavak has quit IRC15:27
samueldmq-awaybknudson, so for test_v3_* load_sample_data is called for every test?15:27
*** samueldmq-away is now known as samueldmq15:28
marekdsamueldmq: yes.15:29
bknudsonsamueldmq: looks like it: http://git.openstack.org/cgit/openstack/keystone/tree/keystone/tests/unit/rest.py#n6915:30
*** Ephur has quit IRC15:30
bknudsonit's load_fixtures, no load_sample_data.15:30
openstackgerritRodrigo Duarte proposed openstack/keystone: Prohibit invalid ids in subtree and parents list  https://review.openstack.org/15872015:32
openstackgerritRodrigo Duarte proposed openstack/keystone: Fix _get_children() method from SQL backend  https://review.openstack.org/15873115:32
*** nellysmitt has quit IRC15:32
*** nellysmitt has joined #openstack-keystone15:32
bknudsonI think the nova unit tests actually take less time than keystone's.15:33
marekdsamueldmq: just remove this 'cleaning' part and i will be happy to +215:33
*** jsavak has quit IRC15:36
*** jsavak has joined #openstack-keystone15:37
samueldmqbknudson, well.... loading that for each test is definitively not the best approach IMO ...15:39
samueldmqbknudson, it just reduces a little bit of code .... but increases execution time and readability (once the used entities are not created in the test itself)15:40
bknudsonsamueldmq: it's been that way a long time, just waiting for someone to come in and clean it up.15:40
samueldmqbknudson, we should either i) create a common scenario used by everyone or ii) create entities at each test15:41
samueldmqbknudson, I do prefer i)15:41
bknudsonI prefer ii15:41
*** chrisshattuck has joined #openstack-keystone15:41
samueldmqbknudson, hm .. why?15:41
bknudsonI think we already have i ?15:41
samueldmqbknudson, what I said looks like i)15:42
*** jsavak has quit IRC15:42
samueldmqbknudson, but it should be created once ... not for each test15:42
bknudsonI prefer ii because it shows what's being tested.15:42
samueldmqbknudson, there is a common scenario, use it and let it as it was at the end15:42
bknudsonthe reason it's recreated every time is to ensure that the starting point is the same.15:42
*** stevemar has joined #openstack-keystone15:43
*** ChanServ sets mode: +v stevemar15:43
bknudsonrather than having different tests messing with the same data.15:43
samueldmqbknudson, well .... henrynash told me somewhen he prefers this (as you)15:43
*** csoukup has quit IRC15:43
samueldmqbknudson, ok ... so it makes easier to someone read any test15:43
samueldmqbknudson, the only con is that it takes longer ...15:44
samueldmqbknudson, if we had small classes (one for functionality, for ex), we could use a scenario in there .... and if it was shared ... that wasnt a big problem15:44
bknudsonif it means you can run tests in parallel then it can take a lot less time.15:44
samueldmqbknudson, great point ! sharing data would result in race conditions15:45
samueldmqbknudson, and possibly take longer at the end15:45
samueldmqbknudson, I was thinking with a batch brain ... and you with a cloud parallel one ... thx15:46
*** david-lyle_afk is now known as david-lyle15:47
openstackgerritSamuel de Medeiros Queiroz proposed openstack/keystone: Exposes bug in Federation list projects endpoint  https://review.openstack.org/15816315:48
samueldmqmarekd, ^15:48
lbragstadstevemar: spec registered and targeted https://review.openstack.org/#/c/145317/2215:49
*** markvoelker has joined #openstack-keystone15:49
*** rushiagr is now known as rushiagr_away15:50
stevemarlbragstad, thanks sir15:50
lbragstadstevemar: thank you!15:51
*** realist__ has joined #openstack-keystone15:53
realist__ Hi, I am unable to install Devstack, i submitted my question here yesterday and got no answer : https://ask.openstack.org/en/question/61583/devstack-installation-failure/15:53
*** abhirc has joined #openstack-keystone15:54
*** mattfarina has joined #openstack-keystone15:55
samueldmqbknudson, well.. I think I'll grab this ... I'll talk to henrynash and dstanek to see how it would look like with functional + data-driven tests15:58
*** abhirc_ has joined #openstack-keystone15:58
dstaneksamueldmq: reading up on the convo15:59
realist__Is it acceptable to ask questions here ?15:59
*** abhirc has quit IRC15:59
bknudsonsamueldmq: functional tests might require setting up some global users that aren't modified by the tests. They're not going to start from a clean db every time.16:01
dstanekmarekd: see the section starting at line 90 here: https://etherpad.openstack.org/p/keystone-test-restructuring16:02
dstanekbknudson: why not make new users each time?16:03
bknudsondstanek: they can, I'd expect it to be much slower on real db than it is using sqlite.16:04
bretonnot really. Postgres works quite fast on our tests.16:06
dstanekbknudson: not saying we should, but i'd rather lean toward the automated approach vs. doing it like devstack16:07
bknudsondstanek: the tempest tests create a lot of fixtures in the class setup for better or worse.16:07
bknudsonmaybe not for identity tests, though?16:08
*** csoukup has joined #openstack-keystone16:11
*** chrisshattuck has quit IRC16:11
openstackgerrithenry-nash proposed openstack/keystone: Add API support for domain config  https://review.openstack.org/15875216:15
*** jamielennox is now known as jamielennox|away16:15
*** chrisshattuck has joined #openstack-keystone16:15
dstanekbknudson: not sure, i'm in the middle of converting a few v3 unit tests into functional tests now; i'll post when i'm done16:15
bknudsondstanek: awesome!16:15
*** jamielennox|away is now known as jamielennox16:16
*** mhu has quit IRC16:16
bknudsonI hope it's a test for getting a token.16:16
openstackgerrithenry-nash proposed openstack/keystone: Add API support for domain config  https://review.openstack.org/15875216:16
bknudsonthat's kind of important.16:16
morganfainbergrealist__: you can always ask questions here.16:17
morganfainbergrealist__: but realize sometimes it takes a while to get the answer.16:17
morganfainbergWe do our best to make sure questions get answered16:18
*** mhu has joined #openstack-keystone16:20
morganfainbergrealist__: that looks like (iirc) an out of date oslo. So we changed the oslo namespace from oslo.config to oslo_config. I am guessing this is a vm you previously used for devstack? You are likely going to need to update all your oslo libraries to resolve this. I recommend (if you can afford it) to start with a clean VM (easiest solution).16:21
realist__morganfainberg: thats true.16:22
realist__morganfainberg: thank you.16:22
morganfainbergSure thing :)16:22
morganfainbergHappy to help.16:22
samueldmqbknudson, hmm ... so for internal tests (backend, unit) it does make sense to create data in each test ...16:25
samueldmqbknudson, and for functional ones (that would be expensive to put in parallel) we could use a common scenario .. right?16:26
bknudsonsamueldmq: right... we might start out creating data in each test for functional and only if it turns out to be too expensive could use a common scenario.16:27
samueldmqbknudson, ++16:28
samueldmqbknudson, for backend tests .. there is a data-driven approach being introduced on keystone ....16:28
samueldmqbknudson, it's from henrynash https://review.openstack.org/#/c/149178/16:28
samueldmqbknudson, it supports the idea of creating data for each test16:28
*** richm1 has joined #openstack-keystone16:29
henrynashsamueldmq, bknudson: well, it’s just a short-hand data driven approach16:29
samueldmqhenrynash, but a great start imo ... we could make it generic to be used by other backends in the future :-)16:30
*** richm1 is now known as richm16:30
bknudson'entities': {'domain': [{'contents': {'user': 1, 'group': 1, -- doesn't look very obvious to me what this is testing.16:30
samueldmqbknudson, this still is not testing.. just setting up the data16:31
samueldmqbknudson, to be used on the test cases16:31
bknudsonit's also not obvious what data is being set up.16:31
samueldmqbknudson, the specific attributes of a user/proejct etc?16:32
bknudsonlooking at "'entities': {'domain': [{'contents': {'user': 1, 'group': 1," I have no idea what's going on.16:32
samueldmqcreate a domain, containing 1 user and 1 group16:33
bknudsonevery time I see that I'll have to read the documentation.16:34
samueldmqthat shouldnt be that hard if you get the approach ... maybe this is not too easy now because the approach is completely different from what we have today16:34
ccardRE my issue with "openstack role add" for a user in a domain, I see the same issue with a domain that doesn't use LDAP as the backend, so I think the LDAP part is not connected. The issue seems to be that the request sent to keystone doesn't have a domain in the v3 token.16:34
samueldmqbknudson, yes... the idea is good, that makes complex test cases smaller and easier to understand :)16:34
samueldmqbknudson, looking forward to see your reviews there :-)16:35
openstackgerritMatthieu Huin proposed openstack/keystone: Get method's class name according to python version  https://review.openstack.org/15877716:35
samueldmqpossibly there are some cons that I didnt notice16:35
bknudsonthe test itself is definitely shorter.16:36
samueldmqand will become much easier as well.. once you get familiar with the approach16:37
*** realist__ has quit IRC16:37
bknudsonbut tests should be short and simple to begin with (one rule is to have a single call to assert)16:37
bknudsona unit test shouldn't require a test plan.16:38
amakarovbknudson, common.setup_backends() is still needed for testing engine - I want to leave it be, what do you think about it?16:38
samueldmqbknudson, so we should have 1 test case per test ?16:38
bknudsonsamueldmq: yes.16:38
samueldmqbknudson, why not group them if it makes sense .. instead of multiples tests with common scenario ?16:39
bknudsonamakarov: I don't have a problem with that... maybe the tests can be fixed up later... the tests 'should' be able to use the same setup.16:39
samueldmqwouldnt that be too purist?16:39
bknudsonsamueldmq: because it makes it harder to see what the test was actually trying to verify when it failed, and also if the test fails in the middle then the rest of the test isn't run.16:40
*** _cjones_ has joined #openstack-keystone16:40
amakarovbknudson, I'll postpone it till another patch - too many for a single bugfix16:40
bknudsonamakarov: yes, please, don't mix the refactoring in with the bug fix.16:41
*** _cjones_ has quit IRC16:41
samueldmqbknudson, good point... than maybe we could keep the setup ('entities' and 'assignments' as they are) and split 'tests' out of test plan ...16:42
samueldmqbknudson, and then we should call separate test cases one by one16:42
bknudsonsamueldmq: that would be great16:42
*** _cjones_ has joined #openstack-keystone16:42
*** radez_g0n3 is now known as radez16:42
samueldmqnice! fell free to let a review :)16:43
samueldmqhenrynash, ^16:43
samueldmqbknudson, I'll add a comment there later if you didnt get time to do so16:43
bknudsonsamueldmq: I wouldn't -1 for this... it's my opinion and different developers have different opinions on it.16:44
bknudsonif someone likes to construct their tests this way I'm fine with it.16:44
bknudsonI'm usually just happy that there are tests.16:45
*** _cjones_ has quit IRC16:46
*** _cjones_ has joined #openstack-keystone16:46
samueldmqbknudson, great! we share that opinion .. I'll add a comment and let's see what henry and others think about16:47
samueldmqbknudson, we could even let it as is and keep the idea in mind .. and then refactor when we put that for all backends (if we go for it )16:48
samueldmqbknudson, yes, the fact of having tests is already great16:49
openstackgerritRodrigo Duarte proposed openstack/keystone: Do not allow the use of slash in the project name  https://review.openstack.org/15715216:54
openstackgerritRodrigo Duarte proposed openstack/keystone: Add is_domain field in Project Table  https://review.openstack.org/15742716:54
openstackgerritRodrigo Duarte proposed openstack/keystone: Change project name constraint  https://review.openstack.org/15837216:54
ccardis it even possible to get a domain scoped v3 token using the openstack cli?16:55
rodrigodsccard, yes, you just need to export the right environment vars16:59
samueldmqbknudson, yes, the fact of having tests is already great17:01
samueldmqbknudson, sorry, I meant to re-run tests in the terminal ...17:01
*** ioram has quit IRC17:07
*** nellysmitt has quit IRC17:17
*** jistr has quit IRC17:18
*** nellysmitt has joined #openstack-keystone17:18
*** rwsu-afk is now known as rwsu17:18
*** afazekas has quit IRC17:26
openstackgerritAlexander Makarov proposed openstack/keystone: Correct initialization order for logging to use eventlet locks  https://review.openstack.org/15491517:28
*** afazekas has joined #openstack-keystone17:28
amakarovbknudson, ^^17:28
amakarovbknudson, it's growing...17:28
openstackgerritSteve Martinelli proposed openstack/keystone: Cleanup policy related bits in tests  https://review.openstack.org/15856117:29
ccardrodrigods: I've tried all the combinations of environment variables that seemed likely, no luck17:31
rodrigodsccard, you should import username, password, domain_name and user_domain_name17:31
rodrigodsccard, or _id (if it is the case)17:32
*** _cjones_ has quit IRC17:33
*** _cjones_ has joined #openstack-keystone17:36
stevemargordc, could you help reduce the amount of open patches i have :) https://review.openstack.org/#/c/156463/17:36
openstackgerritayoung proposed openstack/keystone-specs: Correct unscoped token request layout  https://review.openstack.org/15879117:38
gordcstevemar: ah right. i forgot about that patch.17:38
*** chrisshattuck has quit IRC17:39
ccardrodrigods: I'm probably confused, but what I'm trying to do is give a user access to a project in a domain. As far as I can see, the command to do this is "openstack role add --project testproject1 --user ccard _member_", is that right?17:39
mhustevemar, hi ! I didn't realize you were already working on https://launchpad.net/bugs/1420125 from the bug description, let me know if you want to get back to it17:39
openstackLaunchpad bug 1420125 in Keystone "href variables for federation controller are inconsistent" [Low,In progress] - Assigned to Matthieu Huin (mhu-s)17:39
stevemarmhu, i'm not, just reported it17:40
stevemarmhu, there was a patch there, but i abandoned it, since we will have to deprecate it17:40
stevemaryou can look at the patch for notes17:40
mhustevemar, will do, thx !17:40
morganfainbergstevemar, argh... https://review.openstack.org/#/c/155660/ merge conflict17:41
openstackgerritMorgan Fainberg proposed openstack/keystone: Add in non-decorator notifiers  https://review.openstack.org/15860017:41
*** lhcheng_afk has joined #openstack-keystone17:42
ccardrodrigods: no matter what combination of OS_ variables I export, I can't get this command to run without (at best) getting a 401 error, and the keystone log seems to indicate that this is because the v3 token it gets isn't domain scoped.17:42
stevemarccard, paste of your env. vars?17:43
openstackgerritMorgan Fainberg proposed openstack/keystone: Get initiator from manager and send to controller  https://review.openstack.org/15566017:43
morganfainbergstevemar, ^^ rebased.17:43
*** pdesai has joined #openstack-keystone17:43
*** fmarco76 has left #openstack-keystone17:46
ccardstevemar: with these settings: http://pastebin.com/ht9ahYmQ, "openstack user list --domain testdomain1" works17:46
*** browne has joined #openstack-keystone17:46
ccardbut # openstack role add --project testproject1 --user ccard _member_17:46
ccardERROR: openstack The request you have made requires authentication. (HTTP 401)17:46
ccardkeystone.log here: http://pastebin.com/HMqqC5nK17:49
*** tqtran has joined #openstack-keystone17:49
*** karimb has quit IRC17:56
stevemarccard, bah keystone meeeting now, i might be a bit longer to get back to you17:59
ccardstevemar: ok, I'm off home now anyway17:59
*** pnavarro has quit IRC17:59
*** lhcheng_afk is now known as lhcheng18:00
*** spandhe has joined #openstack-keystone18:01
jamielennox /join #openstack-meeting18:07
*** devlaps has joined #openstack-keystone18:11
*** jacorob has left #openstack-keystone18:11
*** raildo_away is now known as raildo18:12
*** jacorob has joined #openstack-keystone18:12
*** harlowja has joined #openstack-keystone18:20
*** tqtran_ has joined #openstack-keystone18:20
*** xavpaice has left #openstack-keystone18:21
*** tqtran has quit IRC18:21
*** joesavak has joined #openstack-keystone18:24
*** harlowja has quit IRC18:24
*** harlowja has joined #openstack-keystone18:24
*** aix has quit IRC18:29
*** diegows has quit IRC18:30
*** gyee has joined #openstack-keystone18:31
*** ChanServ sets mode: +v gyee18:31
openstackgerritMerged openstack/pycadf: Additional doc clean up  https://review.openstack.org/15646318:39
openstackgerritAlexander Makarov proposed openstack/keystone: Redis token backend  https://review.openstack.org/15084418:44
openstackgerritAlexander Makarov proposed openstack/keystone: Redis token backend  https://review.openstack.org/15084418:45
*** krtaylor has quit IRC18:48
openstackgerritRodrigo Duarte proposed openstack/keystone-specs: Recursive deletion and project disabling  https://review.openstack.org/14873018:57
marekdmorganfainberg: gyee re: service providers let me get back with that once i am done with my dinner and other evening stuff.18:59
gyeemarekd, I am fine with it18:59
*** krtaylor has joined #openstack-keystone19:00
morganfainbergI'm going to relocate and will be doing cleanup now.19:00
morganfainbergSo will be around in 15 mins. Or so.19:01
marekdme in more 40 mins.19:01
gyeemarekd, my feeling is that we may just ended up needing a more comprehensive catalog service19:01
*** pdesai1 has joined #openstack-keystone19:01
ayoungmarekd, K2K provider list...keep it out of the Service catalog.  Any reason to force it in there?19:02
*** browne has quit IRC19:03
lhchengayoung: is there a spec or bug that describes the changes in Access Info? Wanted to check if there would be an impact on django_openstack_auth.19:03
*** amakarov is now known as amakarov_away19:04
*** pdesai has quit IRC19:04
*** browne has joined #openstack-keystone19:04
gyeeayoung, its for workflow, user needs to know what other clouds he have access to19:05
gyeeotherwise, we'll have to create a separate API for that19:06
*** csoukup has quit IRC19:11
*** pdesai has joined #openstack-keystone19:14
stevemarbknudson, going to put your requested changes in a test clean up patch for policy19:14
bknudsonstevemar: ok... does that also take care of dhellmann's comment?19:15
*** pdesai1 has quit IRC19:15
stevemarbknudson, it should, not with a fixture but with your suggestion19:16
stevemari'll add it here https://review.openstack.org/#/c/158561/19:16
bknudsonstevemar: I think I noticed another place where there was an addCleanup for resetting the enforcer...19:16
*** _cjones_ has quit IRC19:16
stevemarbknudson, probably, check the patch i linked, i tried to make things more consistent there19:17
bknudsonstevemar: http://git.openstack.org/cgit/openstack/keystone/tree/keystone/tests/unit/test_v3.py#n14919:17
ayounglhcheng, should be no impact.  The goal is a drop in replacement for the access info19:17
ayoungthe main goal is to make it possible to have a strict Python object model instead of dictionaries.19:18
ayounggyee, so we don't have proper support in the SC for what we need, do we19:18
bknudsonstevemar: so test_v3.RestfulTestCase already does self.addCleanup(rules.reset) ...19:18
ayoungwe need to be able to put something into the SC that is not shown by default19:18
lhchengayoung, ah yes it is just a dictionary now. cool, good to know.19:19
ayoungand only shows up if specifically requested, like in the K2K case19:19
stevemarso we're doing it unnecessarily in a bunch of spots, youre saying?19:19
ayounglhcheng, review is WIP19:19
bknudsonstevemar: if the cleanup can just happen on every test then add it to the base testcase, then we'll always start with a clean setup.19:19
ayounghttps://review.openstack.org/#/c/138519/  lhcheng19:19
ayounggyee, the only scoping of a catalog we perform is per project today.  Would that be sufficient?19:20
gyeeayoung, we do, endpoint constraints19:20
ayounggyee, those are are neither necessary nor sufficient, I think.  Here it is an advertisement project19:21
*** _cjones_ has joined #openstack-keystone19:21
ayoungI have a token for K1 and I want to use in K219:21
ayoungbut K2 should not show up as an endpoint in the SC for K1 except in rare occurances19:21
ayoungwe don't really care what K2 does (ok we do, be we can't enforce it)19:22
gyeeif user is allowed to access K2, why not?19:22
lhchengayoung, thanks for the link! added myself to the reviewer, will check it later.19:22
ayounglhcheng, thanks19:22
gyeeayoung, problem right now is we don't have seamless resource discovery across boundaries19:23
gyeethis is a problem with federation in general19:23
gyeeuser does not have an aggregated view, that's mostly application logic19:24
gyeeaggregated view from API19:24
gyeeayoung, think DB design, how can we have a *view* which consists columns from different tables19:25
gyeeif we can apply that thinking into federation at a macro level, we can get there19:26
stevemarbknudson, can you mark bp https://blueprints.launchpad.net/keystone/+spec/prefer-notifications if it's done19:27
ayounggyee, HMT, and service catalog scoping.  I have a general idea of how this should work, but it is not "in the next 10 days" type stuff19:28
ayoungideally, we would be able to have a reusable entity that is subset of the global service catalog19:29
ayoungthe default catalog would have what most people use19:29
ayoungbut some people would see a different subset, possibly with the K2K info in it19:29
gyeeayoung, yeah, it definitely needs some thinking in that area19:31
gyeenot that easy19:31
ayounggyee, do we have "hidden" service catalog items yet?19:32
gyeewhy hidden?19:32
ayounggyee, I mean, not show up by default19:32
gyeeayoung, yeah, endpoint filtering19:32
gyeeBob's working on the enforcement middleware19:32
ayoungyeah, but that removes items19:32
ayoungdoes that keep them from showing up if not explicitly asked for?19:33
gyeeyeah, it won't show up in a scoped token19:33
gordcstevemar: hey, can you ask someone whether db2 nosql supports ttl?19:33
ayoungOK...so we could make K2K other keystones be endpoint filtered away19:33
*** devlaps has quit IRC19:33
jamielennoxi currentl have IRC and no other internet - how can i be seeing this and ping: unknown host google.com at the same time19:34
stevemarbknudson, ^ do you know what gordc is talking about?19:34
gordcstevemar: or more importantly if it is still supported.19:34
ayoungjamielennox, DNS failure?19:34
ayoungand IRC is using IP address19:34
bknudsongordc: does mongodb support it? I didn't think it did.19:35
gyeeayoung, right, that's why I was pushing SP as an endpoint19:35
jamielennox100% packet loss from ping
ayounggyee, I think that fits the abstraction19:35
gyeeso we can put them under endpoint constraint as well19:35
ayoungjamielennox, try another dns...I'm inside VPN so I don't have one19:35
ayounglet me give you the dreamhost one, but tread lightly19:36
gordcbknudson: mongodb has native ttl support. i'm assuming db2 doesn't (it's just a translation engine on top of sql?)19:36
marekdmorganfainberg: ayoung stevemar gyee: I am back.19:36
gyeeayoung, a robust SC is essentially in discoverability19:36
ayoungmarekd, OK, so K2k other keystone  in catalog is, I think, the right approach19:37
ayoungthe service catalog should say where a user can use a token19:37
ayoungand K2K falls into that category19:37
bknudsongordc: I'll ask around.19:38
marekdayoung: so put remote keystones into endpoint list?19:38
ayoungthe remote Keystone should be endpoint filtered such that it does not show up by default, maybe scoped to a specific project19:38
ayoungmarekd, yes, I think so19:38
ayoungit passes the test "can I use a token here?"19:38
gordcbknudson: thanks!19:38
marekdayoung: not really, as you need to exchange your token for an assertion, and trade that assertion for another token issued by a remote keystone.19:39
morganfainbergayoung, so there is an issue there: 1) we can't decouple the two URIs and .get_endpoint in ksc would return something unsuable19:39
morganfainbergayoung, and ^^ you can't just use the token.19:39
ayoungmarekd, ah....19:39
ayoungwe should be able to, damnit19:39
ayoungthat was what I designed years ago19:39
gyeebut why even restrict to tokens?19:40
marekdthat 'one token to rule them all' was discussed in July last year, and posed some security concerns.19:40
ayounggyee, no "restrict" but "allow"19:40
morganfainbergand yes, SPs should be filtered per project, and if the SP isn't in the catalog we should never issue SAML for it.19:40
*** mestery has joined #openstack-keystone19:40
*** flaviof has joined #openstack-keystone19:40
ayoungthat works.  And if we allow tokens in the future, it still makes sense19:40
morganfainbergs/per project/per project|domain19:40
gyeemarekd, right, bearer tokens are dangerous :)19:40
bknudsongordc: DB2 nosql doesn't support TTL.19:40
marekdgyee: i think there is a thin line between seamless bursting into remote cloud and overtaking remote clouds.19:41
ayoungSAML is just a bearer token19:41
morganfainbergayoung, so, part of the issue is the current catalog is very naive and can't tightly couple endpoints and we need 2 uris here.19:41
ayoungthere is no silver bullet19:42
gyeejust use x509 cert and surf the clouds at ease19:42
morganfainbergayoung, but SAML is a much easier sell to the security focused people than keystone tokens19:42
morganfainbergayoung, trust me ;)19:42
morganfainbergeven though they could be functionally interchangeable19:42
morganfainbergthe whole standards thing19:42
ayoungI trust you the same as I do anyone.  About as far as I can throw you.19:42
gordcbknudson: cool cool. thanks for confirming19:42
ayoungBut you are light19:42
morganfainbergyou could prob thow me a bit further than some other folks19:43
marekdmy oncly concern is that one day i would like to be able # openstack list server --federated and get a nice list of VMs from all federated clouds19:43
marekdbe able to make neutron net across my clouds and things like that.19:43
gyeemarekd, yeah, we all want that19:43
jamielennoxmorganfainberg: so we can always do the two parts via the interface filters but it's not pretty19:44
marekdand i am fearing that if we start splitting endpoint we will need to unwind it faster than we think.19:44
morganfainbergnow if we put this in the normal catalog we need 2 things: 1) new definitions of the endpoint types, that are new for the k2k stuff.19:44
morganfainbergand 2) a way to ensure you can never filter one of those endpoints out but not the other via endpoint filtering19:44
morganfainbergoh and 3) [off by one error!] a non sucky way to manage that.19:44
gyeenever heard of off by one :D19:45
morganfainbergright now the data structures are not endpoints in the catalog.19:45
morganfainbergthey are something totally different19:45
morganfainbergand need to be so federation can do stuff with it19:45
morganfainbergand the workflow is very different than normal token operations.19:45
morganfainbergso if we address those issues ^^ we can put it in the normal catalog. otherwise this needs to be separate so we can manage it appropriately.19:46
morganfainbergin both cases we need to support the idea of filtering per domain|project19:46
morganfainbergand not issue SAML if that endpoint wouldn't appear in the catalog19:46
marekdmorganfainberg: we don't have logic for such filtering now :(19:47
gyeemorganfainberg, with SP as a separate thingy, we need to add more plumbing for the filtering part right?19:47
morganfainbergmarekd, no we don't and because this has been so contentious we haven't worked on it19:47
ayoungdoes this call for a separate API then?19:47
morganfainbergayoung, this already has a separate API  [based on the spec]19:47
morganfainbergthat is hooked into federation19:48
ayoungand it stays out of the SC for now?19:48
morganfainbergayoung, today we have no way to represent it to end users19:48
morganfainbergwe ripped out the region part cause that was bad19:48
morganfainbergthis is putting the representation for users back in19:48
morganfainbergright now it doesn't work.19:48
morganfainbergat all19:48
morganfainbergunless you magically know how to ask for tokens and urs19:48
morganfainberguris to auth against19:48
gyeeayoung, that goes back to the "view" thing we talked about earlier. What does an end user view of an SP?19:49
gyeeor does end user really cares as long as we tell him there's a service you can use19:49
ayoungmorganfainberg, "magically" sounds like it could be handled by the client19:49
morganfainbergayoung, magically as in you just happen to know - you can't get that info w/o being cloud admin atm19:50
morganfainbergayoung, and able to setup SPs.19:50
ayoungthat sounds like policy, then19:50
morganfainbergno, there is *no* way to get it now19:50
morganfainbergthere is no API for it19:50
morganfainbergthis is putting the API for the client to get it19:50
morganfainbergwhich the SC was where we said we'd put it...19:50
morganfainbergback when this was designed19:50
morganfainbergok i lied, you can probably get it if you're cloud admin but i don't want you to list all SPs to guess at that.19:51
jamielennoxwhat are the two URLs that are required for service providers? the base keystone and the OS-FEDERATION one?19:51
stevemarjamielennox, yeah 'auth_url' and 'sp_url'19:51
marekdjamielennox: one for sending your SAML, second is usually /v3/auth/tokens19:52
marekdonce you have your session open19:52
*** pdesai1 has joined #openstack-keystone19:52
jamielennoxok, so i think that's wrong - we shouldn't have both - but we can get away with one19:52
*** pdesai1 has quit IRC19:52
jamielennoxfrom a catalog perspective auth_url shouldn't be there19:52
marekdjamielennox: then you will move this responsibility to the user.19:52
jamielennoxbecause you can't communicate with auth_url with your token19:52
jamielennoxdoes it make sense to only include sp_url, do the unscoped catalog, scope based on that19:53
* morganfainberg is thinking we should just revert the change to pull this out of the region and say "screw it we'll keep a bad ux, at least that wasn't contentious to land"19:53
jamielennoxunscoped catalog would contain the auth_url19:53
marekdbut you *will be* able to if you use K2K.19:53
jamielennoxor some other way of returning auth_url19:53
jamielennoxmarekd: no, with my local keystone token i can't talk to a remote keystone19:54
jamielennoxi need to get a token in that remote cloud19:54
gyeemorganfainberg, lets just make it work for now and improve later, baby steps19:54
marekdjamielennox: wait a second. who is issuing unscoped token?19:54
*** pdesai has quit IRC19:54
gyeemorganfainberg, the ocean temp is raising :)19:55
gyeeanyhoo, food time19:55
jamielennoxmarekd: wouldn't the initial call to the remote sp_url be getting an unscoped19:55
marekdjamielennox: no, it merely SAML stuff.19:56
ayoungmarekd, ok,  I think the flow is something like this19:56
marekdsp_url is something like: https://example.com:5000/Shibboleth.sso/SAML2/ECP"19:56
marekdayoung: let me finish19:56
jamielennoxmarekd: k2k?19:56
*** sanket has joined #openstack-keystone19:57
marekdjamielennox: yes, saml/oidc in general.19:57
jamielennoxergh, that's right - we shortcutted that and didn't actually use keystone tokens to talk between keystones19:57
ayounguser gets token,  from token gets assertion,  list sps, get sp-url.  passes assertion to spur, gets unscoped token19:57
marekdayoung: he needs auth_url to get unscoped token19:57
ayounglast unscoped token has auth_url in the (new unscoped) catalog19:57
ayoungthis is redonculous19:57
morganfainberg marekd, it's part of the redirect logic right?19:57
marekdsp_url is where he puts his saml assertion, but then, he doensn't know where to go and ask for a token.19:57
marekdmorganfainberg: yes.19:58
marekdmorganfainberg: we do this today with Icehouse federation too.19:58
morganfainbergmarekd, yeah just clarifying why we need both urls19:58
marekdmorganfainberg: it's hidden in normal websso, because it's one of 302 redirect.19:58
marekdmorganfainberg: yes we do, if tey are not in the server, client will need to make an efford, go to cloud admin, ask, export env variable19:59
marekdthis is what i had to do when we had only one url in a region.19:59
jamielennoxmarekd: but we never post SAML to /auth/tokens do we?19:59
marekdjamielennox: no, we dont,19:59
*** rm_work is now known as rm_work|away19:59
morganfainbergjamielennox, no, you don't because that doesn't know how to read SAML [and not everything *is* saml]19:59
marekdjamielennox: sp_url: https://example.com:5000/Shibboleth.sso/SAML2/ECP, auth_url: keystone/v3/auth/tokens19:59
jamielennoxthat's good - just checking20:00
morganfainbergyou could still have username/password that needs to not be processed by saml20:00
jamielennoxso the return from the OS-FEDERATION urls has to be a keystone token20:00
*** lhcheng is now known as lhcheng_afk20:00
marekdfirst, go to sp_url, take cookie session in return, then, go to auth_url, and since you have your cookie, you can get through, which effectively means get unscoped fed-token.20:00
jamielennoxsp_url being something shib doesn't make sense there, we don't have an external sp, we have a keystone20:00
morganfainbergjamielennox, the SP_url is shibboleth validating the SAML auth and passing/telling you to fly a kite20:01
morganfainbergwithout hitting that first you can't get things over to the auth url. it's not a pass-through20:01
marekdmorganfainberg: ++20:01
jamielennoxright - but in the k2k situation what is going to be our sp_url?20:01
marekdjamielennox: sp_url: https://example.com:5000/Shibboleth.sso/SAML2/ECP, auth_url: keystone/v3/auth/tokens20:01
morganfainbergSP url is apache mod_shib20:01
marekdexamples ^^20:01
morganfainbergwhich validates things, in a web browser you're then 302'd to the real location20:02
morganfainbergwhich in our case is an AUTH URL20:02
marekdmorganfainberg: +++++++20:02
jamielennoxmmm, k2k should have been done with actual tokens.....20:02
*** rm_work|away is now known as rm_work20:02
morganfainbergbut we can't know that, because it's apriori knowledge, from the SP usually, in this case we are IDP initiated20:02
morganfainbergjamielennox, it would have died20:02
stevemardied so fast20:03
marekdjamielennox: that would mean reinventing what saml give sus for free.20:03
morganfainbergjamielennox, the keystone tokens are extremely hard to sell to security folks when they need to move across network boundries20:03
jamielennoxmarekd: as do tokens20:03
marekdjamielennox: crypto, signing etc.20:03
marekdjamielennox: plus, with saml we can burst into non openstack services20:03
*** flaviof has quit IRC20:04
marekdbknudson: for instance.20:04
marekdjoesavak had some use cases for that.20:04
*** flaviof has joined #openstack-keystone20:04
morganfainbergtechnically this makes it *more* possible for keystone to provide identity to apps that aren't openstack aware20:04
morganfainbergand... it gives warm and fuzzies to the security folks because they understand saml workflows20:05
bknudsonI hope that doesn't happen.20:05
morganfainbergand saying "it works like saml but it's something else" does not sell well to enterprise folks20:05
morganfainbergyou can replace saml with oidc or anything else20:05
morganfainbergbknudson, i don't really classify it as a win to provide identity outside of openstack to openstack. but meh20:06
morganfainbergsomeone could do it20:06
morganfainbergin fact i wouldn't advertise it in our docs :P20:06
morganfainbergthe last reason we benefit from SAML is that is reuses a lot of the workflows we designed for federation20:07
marekdjamielennox: yeah, we are somewhat screwed that we still need separate token per cloud.20:07
morganfainbergthere really wasn't extra glue needed on the service provider side to "work"20:07
bknudsonhttps://review.openstack.org/#/c/156509/1/api/v3/identity-api-v3.rst has as an example "auth_url": "https://example.com:5000/v3/OS-FEDERATION/identity_providers/acme/protocols/saml2/auth"  / "sp_url": "https://example.com:5000/Shibboleth.sso/SAML2/ECP"20:08
bknudsonis that not a k2k example?20:08
stevemarmorganfainberg, yeah it came as a freebie20:08
marekdbknudson: it is.20:08
stevemari feel like bknudson is going to say something profound20:09
bknudsonI don't think it will be profound... just trying to figure out how it works.20:10
bknudsonI haven't used it.20:10
*** csoukup has joined #openstack-keystone20:11
stevemar*womp womp*20:11
bknudsonI send SAML to "sp_url" and then get a token?20:11
marekdbknudson: 1) local authn, get local token, trade it for corresponding saml assertion and send to sp_url, once you are done, use your cookie and go to auth_url. You are already authenticated, so you will get unscoped token ready to use with remote cloud.20:11
stevemarbknudson, you'd get an unscoped token20:11
bknudsonmarekd: ok, thanks.20:11
*** sigmavirus24 is now known as sigmavirus24_awa20:11
ayoungmorganfainberg, any security person that looks at keystone and doesn't have apoplexy should probably not be a security person20:12
marekdayoung: quote of the day.20:13
jamielennoxmarekd: even in the case of k2k you'd get an unscoped token?20:13
*** sigmavirus24_awa is now known as sigmavirus2420:13
bknudsonwe could use some docs in api/v3/identity-api-v3.rst that says what auth_url and sp_url are.20:13
ayoungmarekd, I just like the work apoplexy20:13
marekdjamielennox: yes.20:13
stevemarjamielennox, always20:13
morganfainbergbknudson, sure so we should probably get that into marekd's reviews for changing the API docs20:13
morganfainbergjamielennox, i am going to try and re-release -kerb5 again20:14
jamielennoxso how does the project and roles from local cloud get to remote cloud again20:14
jamielennoxi know the answer is 'mapping' but remind me where20:14
* jamielennox has given talks on this stuff...20:15
openstackgerritSamuel de Medeiros Queiroz proposed openstack/keystone: Honor domain operations in project table  https://review.openstack.org/14376320:16
marekdjamielennox: it's mapping on the remote side20:17
marekdalways remote side20:17
marekdit's once you get through remote.keystone.com/v3/auth/tokens20:17
bknudsonon the local side you get a SAML assertion with roles and stuff?20:17
marekdbknudson: yes20:17
stevemarjamielennox, roles/projects/user info on local keystone are transformed into saml assertion, hand saml assertion to remote keystone, through the mapping you are dumped into a group, once in a group you can list projects/domains20:18
bknudsonso then your mapping is remote roles -> local group, I guess.20:18
jamielennoxmarekd: right - but i just exchanged my local scoped token, for a saml, which got me a remote unscoped token, then ....20:18
openstackgerritSamuel de Medeiros Queiroz proposed openstack/keystone: Honor domain operations in project table  https://review.openstack.org/14376320:18
marekdjamielennox: yes, but i will let remote admin to decide what resources i can touch with this set of roles20:18
jamielennoxok, right - you go into a group with existing perms, remember that now20:19
jamielennoxit's early here20:19
stevemarjamielennox, refer to latter half of what i said ^ - the mapping will always just give you a token with group/idp info. from there use that token to call /domains or /projects20:19
stevemarwe *could* do project to project mapping to get back a scoped token20:19
stevemarbut that would be a lot of out-of-band communication between deployers i think20:19
marekdstevemar: i planned to implement this shortcut next cycle.20:20
jamielennoxi think we'll need some way of doing thta20:20
marekdjamielennox: the problem here is that we need mapping at the remote side and also...we must trust each other (hence federation and resources sharing), but cannot trust in 100%20:20
marekdthe goal is to find there this boundary is.20:21
jamielennoxotherwise the experience sucks, you've burst over to your remote cloud and you need to go through scoping again when you may not know what projects even exist or what they do ther e20:21
openstackgerritDolph Mathews proposed openstack/keystone: Rename test_content_types  https://review.openstack.org/15885420:21
dolphmlbragstad: ^ https://review.openstack.org/#/c/158854/20:21
jamielennoxwe kind of need default_project_id for federated users20:21
jamielennoxand i hate that i said that20:21
bknudsonhorizon will show the projects on the remote cloud.20:21
marekdjamielennox: to skip one scoping step?20:22
lbragstaddolphm: reviewed20:22
jamielennoxmarekd: to not have to make users pick20:22
jamielennoxit's fine in the horizon case where you are stepping through things manually20:23
* marekd feels we will re-discuss whole k2k somewhere very soon.20:23
bknudsonwithout a ui you'd need some way to provide the remote project just like you had to provide the local project.20:23
jamielennoxbut in an automated scenario i want to burst a few compute nodes out onto a public cloud i have to go through it all again20:23
openstackgerritDolph Mathews proposed openstack/keystone: Rename test_content_types  https://review.openstack.org/15885420:23
dolphmlbragstad: fixeded20:23
bknudsonfinally renaming test_content_types!20:24
jamielennoxbknudson: wouldn't in 90% of the time having come from a project means you will end up in another project20:24
jamielennoxspecific project to specific project20:24
bknudsonjamielennox: y, probably, in the bursting scenario.20:24
lbragstaddolphm: want me to open a bug saying that the new test_v2.py should be consolidated with test_v2_auth.py?20:25
morganfainbergjamielennox, that really depends on the mapping rules20:25
jamielennoxmorganfainberg: agreed20:25
jamielennoxanyway either way it's an optimization step for something we've got20:25
morganfainbergjamielennox, but also explicitly mapping always to a project = bad if we do the unscoped->scoped only20:25
jamielennoxif we have to deal with the longer case we should do that first20:26
stevemarjamielennox, putting that in place won't negate any of the current work, it'll be a great add-on20:26
*** nellysmitt has quit IRC20:26
jamielennoxwhat about a landing page20:26
jamielennoxsomething on keystone that returns {sp_url: '', auth_url: ''}20:27
jamielennoxand then that url goes into the catalog20:27
jamielennoxit would need to be accessible with local clouds token ...20:27
morganfainbergjamielennox, uh20:29
morganfainbergyou mean the IDP cloud or the SP cloud?20:29
jamielennoxif we do it locally there is no point in including it in token, if we put it in token it's the same as creating a new service_providers section20:29
jamielennoxsometimes i think i should make my own empty channel and just type things out there first20:29
* morganfainberg is trying to fix -kerberos now too20:30
jamielennoxalright - i don't think it works in catalog20:31
jamielennoxlets make /auth/service_providers first20:31
openstackgerritDolph Mathews proposed openstack/keystone: Rename test_keystoneclient*  https://review.openstack.org/15885620:31
dolphmlbragstad: in the same spirit ^20:31
jamielennoxthen i think it gets its own section in token20:32
morganfainbergjamielennox, ok so we just add another round trip to know if you *can* burst?20:32
dolphmlbragstad: i don't think refactors deserve bugs - they're not user facing20:32
morganfainbergthis feels like catalog data, just not service/endpoint data20:32
jamielennoxmorganfainberg: /auth/catalog exists, you'd need to make /auth/service_providers regardless20:32
morganfainbergjamielennox, ok hold on20:33
morganfainbergback up20:33
morganfainbergi need to know what SPs i can burst to. this *feels* like catalog data20:33
morganfainbergyou are now advocating we make another round trip to get the sps?20:33
marekdresources discovery20:33
morganfainberg[not complaining, just clarifying]20:33
morganfainbergso if i want to burst, i have my token, then i ask /service_providers for a list20:34
morganfainbergthat is scope specific20:34
morganfainbergthen i can burst.20:34
jamielennoxi'm saying that if we don't put it in the standard catalog we need to have that path20:34
morganfainbergassuming i already have a catalog because i'm an end user.20:34
jamielennoxfor the same reasons as ?include_catalog=False20:34
morganfainbergjamielennox, so marekd's prposal was to put a new section in the catalog, that is always there if you can burst20:35
morganfainbergso you'd just use /auth/catalog and look for "service_providers" in it20:35
jamielennoxis there no provision for using an unscoped token?20:36
jamielennoxguess not the mapping would fail20:36
morganfainbergyou can't use unscoped20:36
morganfainbergbecause SAML requires scope information (or should) to know if you can burst to a given SP20:36
morganfainbergsaml generation20:36
jamielennoxthat's an implementation limitation, i was just thinking of the idea20:37
morganfainbergwell no, that isnt20:37
morganfainbergthat is a design choice20:37
morganfainbergauthing against a cloud does not mean you are allowed to burst.20:38
*** samueldmq_ has joined #openstack-keystone20:38
morganfainbergyou should only be allowed to burst if you've been granted the capability to do so [some SPs might allow all scopes]20:38
*** pdesai has joined #openstack-keystone20:38
morganfainbergbut for example i have developers and i don't want them able to consume resources on $burst_target_public_cloud that should be handled via scope - because RBAC limitations in keystone, but it works20:39
jamielennoxok fair enough20:39
morganfainbergif i'm not working on the project that would allow me to burst (result in a useful mapping) i shouldn't be able to.20:39
jamielennoxalright, i agree, they should be a seperate section, not just a standard endpoint in catalog20:40
morganfainbergjamielennox, so if we really need this to be another round trip - sure we can do that. it does feel like catalog data though.20:40
jamielennoxnow i need some breakfast and a coffee20:41
morganfainbergjamielennox, go get coffee :)20:41
morganfainbergit's important20:41
jamielennoxmorganfainberg: agree they should be in token, just saying we needed constistency in the /auth paths20:41
morganfainbergjamielennox, sure.20:41
*** jaosorior has quit IRC20:41
morganfainbergjamielennox, totally buy that. thats why i said a round trip is fine, but if it isn't then catalog is a good place for it20:42
morganfainbergi would prefer from a UX to not have another round trip20:42
openstackgerritMorgan Fainberg proposed openstack/python-keystoneclient-kerberos: Fix the package name in setup.cfg  https://review.openstack.org/15886020:42
openstackgerritMorgan Fainberg proposed openstack/python-keystoneclient-kerberos: Fix the package name in setup.cfg  https://review.openstack.org/15886020:44
*** samueldmq_ has quit IRC20:49
*** marzif_ has joined #openstack-keystone20:49
*** pnavarro has joined #openstack-keystone20:51
*** sanket has quit IRC20:53
lbragstaddolphm: those make sense20:57
ayoungHollleeee Moleeee.  I just realized how much of my job is keeping people from writing code.  Gah20:57
dolphmayoung: =)20:57
morganfainbergayoung, and i realized how much of my life is meetings :P20:58
dolphm"You can look, but don't touch." "But I want to write my own encryption implementation." "Please, please don't touch ANYTHING."20:58
ayoungdolphm, exactly20:58
morganfainbergdolphm, no worse "oh god why did you write that?!"20:58
ayoungmorganfainberg, I feel that way about Keystone tokens.20:58
morganfainbergdolphm, "you touched something"20:58
morganfainbergayoung, i feel that way about a lot of keystone things.20:59
ayoungmorganfainberg, You know that whole rant you said earlier about SAML?  I have actually said pretty much the exact same thing.  I was only pretending to argue with you20:59
morganfainbergayoung, :)20:59
morganfainbergayoung, i figured.20:59
morganfainbergayoung, you usually get way more involved when you legitimately disagree with a direction21:00
ayoungmorganfainberg, If I can figure out a way to keep from handing a token to Nova that nova has to hand to Neutron (etc)  we can get rid of sooooo much21:00
morganfainbergayoung, i'd love to do that21:00
stevemarmorganfainberg, i looked away for a bit, did we come to a resolution on the whole catalog issue?21:00
morganfainbergstevemar, uh. well sortof21:00
morganfainbergayoung, a poor re-implmentation of kerberos is not what i want keystone's auth model to be.21:02
ayoungmorganfainberg, Kerberos is only authentication anyway21:02
morganfainbergi wasn't specific on which Auth<thing> it was ;)21:02
ayoungIn a corp environment, Kerberos is always partenred with an LDAP groups lookup to see what a user can actually do21:03
*** pdesai1 has joined #openstack-keystone21:03
openstackgerritMerged openstack/python-keystoneclient-kerberos: Fix the package name in setup.cfg  https://review.openstack.org/15886021:03
morganfainbergjamielennox, ayoung, https://pypi.python.org/pypi/python-keystoneclient-kerberos21:06
morganfainbergwe had a bug in setup.cfg21:06
morganfainbergthat was the whole issue21:06
morganfainbergall fixed now21:06
morganfainbergand released21:06
*** pdesai has quit IRC21:06
ayoungexcellent.  Thanks morganfainberg21:06
jamielennoxwhat was it?21:07
morganfainbergjamielennox, https://github.com/openstack/python-keystoneclient-kerberos/commit/46d0f4eedf163d358831fa875a2ce676fabd557f21:07
jamielennoxmorganfainberg: oh21:08
jamielennoxmorganfainberg: dumb :)21:08
ayoungmtreinish, can you put this one to bed https://review.openstack.org/#/c/145331  it is asecurity issue, and tempest is key to move the ball down the court21:10
ayoungmtreinish, consider this an official request for Horse Trading.21:11
mtreinishayoung: heh, it was on my review list for today anyway :)21:11
mtreinishayoung: it won't be able to land util the icehouse gate is fixed (the fix should be going through the gate now)21:12
ayoungmtreinish, thanks.  Its one of those cases where RH has put all the effort in to it, and we are a bit trigger shy cuz we don't want to be railroading through changes, but it is the right thing21:12
ayoungmtreinish,  I mean, I don't think anyone is against the idea of "use SSL everywhere" right?21:13
ayoungand thanks for dealing with the gate issue, too21:13
mtreinishayoung: sure, no worries21:15
mtreinishayoung: I just +A'd the change21:15
morganfainbergjamielennox, can you check -federation for the same bug?21:15
ayoungmtreinish, now...what horse was it I was supposed to buy from you?21:15
morganfainbergjamielennox, and if it's there feel free to self +2/+A it.21:15
mtreinishayoung: heh, I'll put it in the bank :) once I figure out the request_id logging for keystone21:16
ayoungAh..already paid!21:16
morganfainbergjamielennox, nvm https://github.com/openstack/python-keystoneclient-federation/blob/master/setup.cfg#L2 looks good to me21:16
morganfainbergjamielennox, are we ready to tag/release -federation too?21:17
jamielennoxmorganfainberg: no21:18
jamielennoxi never know how much to trust pypi stats21:22
jamielennox37 downloads today of ksc-kerberos21:22
morganfainbergjamielennox, just ignore the stats21:23
*** diegows has joined #openstack-keystone21:23
openstackgerritAlexander Makarov proposed openstack/keystone: Redis token backend  https://review.openstack.org/15084421:24
lbragstaddolphm: are you able to run nosetests against test_content_types.py?21:30
dolphmlbragstad: test_v2?21:30
lbragstaddolphm: yes21:30
dolphmlbragstad: either way, yes21:30
lbragstadok, thanks21:31
dolphmlbragstad: you can't?21:31
lbragstaddolphm: nope, cleaned out my .pyc files but end up with 45 some errors21:31
*** marzif_ has quit IRC21:32
dolphmlbragstad: still running but http://pasteraw.com/neaquvi7t41ykab887t0jrh7o3x5hqy21:32
*** lhcheng_afk is now known as lhcheng21:34
lbragstaddolphm: did yours complete with 116 tests passed?21:36
dolphmlbragstad: yes21:38
*** _cjones_ has quit IRC21:39
morganfainbergstevemar, ok so once i'm done with meetings and $stuff$ for bp cleanup / priority reviews i'll rebase that other patchset for you for the cadf failure notifications21:39
*** pnavarro has quit IRC21:46
*** diegows has quit IRC21:46
stevemarmorganfainberg, tried to do some LP cleanup for you21:49
morganfainbergstevemar, thnx21:50
*** _cjones_ has joined #openstack-keystone21:50
*** karimb has joined #openstack-keystone21:52
morganfainberganyone have an issue with '/' being an excluded character from project names?21:59
*** pdesai1 has quit IRC22:00
morganfainbergbefore we start merging things in.22:00
bknudsonmorganfainberg: I think that's proposing a change that's not backwards-compatible.22:00
morganfainbergbknudson, yeah thats my feeling22:00
bknudsonit doesn't meet the stability guidelines.22:00
bknudsonunless it's disabled by default.22:01
marekdbknudson: they said they had some migrations plans that was generally agreed.22:02
*** pdesai has joined #openstack-keystone22:02
morganfainbergmarekd, but i don't see any clear migration plan nor how that would impact an operator22:02
*** c_soukup has joined #openstack-keystone22:02
bknudsonmarekd: they got an exemption from the openstack stability requirements?22:02
morganfainbergor end user.22:02
* morganfainberg has not proposed an exemption22:02
marekdbknudson: i don't know22:02
marekdrodrigods: raildo are the persons to ask.22:03
*** elarson has joined #openstack-keystone22:03
bknudsonHere's the list: https://wiki.openstack.org/wiki/APIChangeGuidelines#Generally_Not_Acceptable22:03
*** csoukup has quit IRC22:04
morganfainbergbknudson, fwiw, -2 has been applied to it22:04
sigmavirus24elarson: https://github.com/openstack/python-keystoneclient/blob/master/keystoneclient/session.py#L13122:04
bknudsonmorganfainberg: thanks!22:04
bknudsondoesn't want keystone to get kicked out of openstack.22:04
sigmavirus24elarson: also https://github.com/openstack/python-keystoneclient/blob/master/keystoneclient/session.py#L7722:04
elarsonsigmavirus24: there it is!22:04
morganfainbergbknudson, we have been good about not breaking things22:04
sigmavirus24elarson: i'll be your tour guide today =P22:05
bknudsonlet's not start now.22:05
morganfainbergbknudson, but this is a challenging thing to address.22:05
morganfainbergbknudson, i think we broke the API contract 2 times in ~6 cycles.22:05
elarsonsigmavirus24: I tip really well22:05
morganfainbergand those were clearly we either violated RFC or OMG security22:05
henrynashdumb question on how our routers->controller calls work….22:05
morganfainberghenrynash, pattern matching22:05
morganfainberghenrynash, i mean... there is a lot more to it, but thats the gist of it, matches pattern, pass request to specified method22:06
morganfainbergsome are baked in patterns in the V3 router base22:06
henrynashwhat determins the name of the parameter in teh controller api call that cotains the body of, say, a put/patch call?22:06
morganfainbergiirc, i'd need to 2x check, but it's exploded as kwargs from JSON22:06
henrynashis it just the key of the dict, i.e. {‘domain’ : {}} ?22:06
morganfainbergvia the request object22:06
morganfainbergi *think*22:07
morganfainbergi'd need to go dig to be 100% sure22:07
*** lhcheng has quit IRC22:07
morganfainbergcburgess, ping - coffee?22:07
dstanekmorganfainberg: is this to replace or supplement decorators? https://review.openstack.org/#/c/158600/522:08
morganfainbergdstanek, replace, since the decorators are far too limited and do too much digging into the callstack to figure things out22:09
*** gyee has quit IRC22:09
morganfainbergbut, since not everything was converted there, no deprecation was set. this is specifically with the cadf-for-all-notifications view in mind22:09
*** lhcheng has joined #openstack-keystone22:09
*** sacharya has joined #openstack-keystone22:09
morganfainbergthe decorators are nice in one regard, but we start running into silly patterns like adding a kwarg to a method so a decorator can try and consume it. it makes my skin crawl.22:10
dstanekmorganfainberg: ++ i have been known to publicly blast decorators; almost never a good idea22:11
morganfainbergdstanek, i'd much much rather use the pecan model, but thread.local has about as much disdain as my view on adding kwargs so a decorator can consume it22:11
dolphmdstanek: when are they a good idea?22:11
morganfainbergso, i'll say we make the notifications better by just notifying with the values we need where we need it instead of by magic22:11
cburgessmorganfainberg: Sure22:11
henrynashok, thanks….just having a problem with my put/patch calls failing with “resource not found”22:11
sigmavirus24elarson: ping me with other questions wherever22:11
morganfainbergdolphm, memoization caching22:12
dstanekdolphm: when you move into a new house and the walls are all blank :-)22:12
morganfainbergdolphm, deprecation warnings where the only thing you're doing is doing "hey you shouldn't do this anymore, go over there"22:12
elarsonsigmavirus24: I'll try to avoid bugging you ;)22:12
morganfainbergcburgess, should i walk over to your office or meet me somewhere?22:13
dolphmdstanek: disagree with morganfainberg?22:13
dstanekdolphm: no22:13
cburgessmorganfainberg: inteligensia?22:13
morganfainbergcburgess, sure.22:13
dstanekmy general rule is that they should only be used it they don't force context on a function or interfere with it's inputs/outputs22:14
cburgessmorganfainberg: When? Now? 2:30? What time will you be there?22:14
morganfainbergcburgess, i'm already here ;)22:14
dstanekso i find things like @route('/') completely dumb :-)22:14
cburgessmorganfainberg: LOL ok.. I'll head over.22:14
morganfainbergdolphm, sure.22:15
morganfainbergerm dstanek, sure22:15
openstackgerritSteve Martinelli proposed openstack/keystone: Add CADF notifications for trusts  https://review.openstack.org/15186722:15
openstackgerritSteve Martinelli proposed openstack/keystone: Emit failure notifications for CADF audits events  https://review.openstack.org/15690522:15
stevemarmorganfainberg, not using the new function you made, just rebased to resovle conflicts ^22:16
stevemargotta head out to a meetup!22:16
morganfainbergstevemar, ++ yeah thanks22:16
morganfainbergstevemar, saw it. will fix those as well today22:16
*** rm_work is now known as rm_work|away22:16
*** radez is now known as radez_g0n322:16
*** gyee has joined #openstack-keystone22:17
*** ChanServ sets mode: +v gyee22:17
*** stevemar has quit IRC22:17
*** gyee has quit IRC22:18
*** gyee has joined #openstack-keystone22:26
*** ChanServ sets mode: +v gyee22:26
dolphmdstanek: alrighty then, i agree22:27
*** darrenc is now known as darrenc_afk22:29
*** lhcheng has quit IRC22:30
*** lhcheng has joined #openstack-keystone22:32
*** jaosorior has joined #openstack-keystone22:33
*** gyee has quit IRC22:34
*** openstackgerrit has quit IRC22:37
*** openstackgerrit has joined #openstack-keystone22:37
*** nkinder has quit IRC22:39
dstanekdolphm: i don't remember what i said but i blasted them here : http://frompythonimportpodcast.com/2010/06/15/episode-004-dave-hates-decorators-where-code-goes-to-die/22:44
dstaneki should probably listen again since i was mostly caught off-guard by the topic22:45
*** henrynash has quit IRC22:47
*** toddnni has quit IRC22:53
*** toddnni has joined #openstack-keystone22:54
*** c_soukup has quit IRC22:55
*** darrenc_afk is now known as darrenc22:56
*** rm_work|away is now known as rm_work23:00
lbragstadeasy one https://review.openstack.org/#/c/158854/23:00
*** harlowja is now known as harlowja_away23:02
*** pdesai1 has joined #openstack-keystone23:04
*** harlowja_away is now known as harlowja23:05
*** lhcheng has quit IRC23:06
*** lhcheng has joined #openstack-keystone23:06
*** bknudson has quit IRC23:07
*** mestery has quit IRC23:07
*** lhcheng_ has joined #openstack-keystone23:08
*** pdesai has quit IRC23:08
*** lhcheng_ has quit IRC23:09
*** lhcheng_ has joined #openstack-keystone23:10
*** lhcheng has quit IRC23:11
*** _cjones_ has quit IRC23:12
*** Tahmina has joined #openstack-keystone23:13
*** _cjones_ has joined #openstack-keystone23:14
*** sacharya has quit IRC23:17
*** chlong has joined #openstack-keystone23:19
*** pdesai1 has quit IRC23:23
*** spandhe has quit IRC23:23
*** karimb has quit IRC23:25
*** gyee has joined #openstack-keystone23:27
*** ChanServ sets mode: +v gyee23:27
*** _cjones_ has quit IRC23:30
*** lhcheng_ has quit IRC23:33
jamielennoxgyee: do you mind having a look at https://review.openstack.org/#/c/157277/ and https://review.openstack.org/#/c/157278/23:33
*** gordc has quit IRC23:33
*** lhcheng has joined #openstack-keystone23:33
gyeejamielennox, looking23:34
*** lhcheng_ has joined #openstack-keystone23:35
*** lhcheng has quit IRC23:38
*** henrynash has joined #openstack-keystone23:40
*** ChanServ sets mode: +v henrynash23:40
*** ayoung has quit IRC23:42
rodrigodsmorganfainberg, saw your comment in the slash change23:42
rodrigodslooks like we are really breaking the api23:42
*** _cjones_ has joined #openstack-keystone23:43
*** ljfisher has quit IRC23:45
*** chlong_ has joined #openstack-keystone23:50
openstackgerrithenry-nash proposed openstack/keystone: Add support for whitelisting and partial domain configs  https://review.openstack.org/15867923:51
openstackgerrithenry-nash proposed openstack/keystone: Add API support for domain config  https://review.openstack.org/15875223:52
dstanekis it pyCADF or PyCADF?23:53
openstackgerritDolph Mathews proposed openstack/keystone: Remove explicit mentions of JSON from test_v2  https://review.openstack.org/15891723:55
*** Tahmina has quit IRC23:58
*** joesavak has quit IRC23:58

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