| *** radez_g0n3 is now known as radez | 00:05 | |
| openstackgerrit | Steve Martinelli proposed openstack/python-keystoneclient: Add openid connect client support https://review.openstack.org/134700 | 00:07 |
|---|---|---|
| *** lhcheng_ has joined #openstack-keystone | 00:09 | |
| *** _cjones_ has quit IRC | 00:10 | |
| *** _cjones_ has joined #openstack-keystone | 00:11 | |
| *** lhcheng has quit IRC | 00:12 | |
| *** markvoelker has joined #openstack-keystone | 00:12 | |
| *** drjones has joined #openstack-keystone | 00:12 | |
| *** _cjones_ has quit IRC | 00:15 | |
| *** markvoelker has quit IRC | 00:17 | |
| *** Kennan2 is now known as Kennan | 00:19 | |
| *** sbfox has joined #openstack-keystone | 00:30 | |
| jamielennox | bknudson: this is kind of where i was aiming for the middleware changes https://review.openstack.org/#/c/190673/ | 00:31 |
| jamielennox | oo, and it appears i moved one of your reviews out of sequence to do it, sorry | 00:32 |
| bknudson | no problem | 00:32 |
| bknudson | so keystone would have its implementation of _BaseAuthProtocol ? | 00:34 |
| *** drjones has quit IRC | 00:35 | |
| jamielennox | bknudson: yep, it comes down to this much in keystone: https://github.com/jamielennox/keystone/blob/middlewareinkeystone/keystone/middleware/auth_token.py | 00:36 |
| jamielennox | which we would probably combine into the AuthContext one rather than be standalone | 00:36 |
| bknudson | _BaseAuthProtocol can't be private then | 00:36 |
| jamielennox | bknudson: right, i just want to get it to a point where i know it works then make public what is needed | 00:37 |
| *** ankita_wagh has quit IRC | 00:37 | |
| bknudson | so it's really just _handle_token | 00:38 |
| jamielennox | i was also thinking we should be able to refine it a bit more, so instead of just handle we do the offline validation in middleware before ever going to keystone | 00:38 |
| jamielennox | that would give us non-persistent pki | 00:39 |
| *** sigmavirus24 is now known as sigmavirus24_awa | 00:39 | |
| bknudson | you'd need to override getting the certs is all | 00:39 |
| jamielennox | bknudson: right | 00:39 |
| bknudson | and revocation list | 00:39 |
| bknudson | if you want to support that | 00:39 |
| bknudson | or events | 00:39 |
| jamielennox | so revocations is where i hope this makes the most sense | 00:39 |
| jamielennox | because we have part of an implementation on the server side and none in auth_token | 00:40 |
| *** kfox1111 has quit IRC | 00:40 | |
| bknudson | revocation events? | 00:40 |
| jamielennox | yep | 00:40 |
| bknudson | there's something in keystoneclient, I think. | 00:40 |
| jamielennox | so you'd have an abstract "fetch events" then handle revocation in the same place | 00:40 |
| jamielennox | there is, but it involves building custom models and it's not been used by auth_token middleware | 00:41 |
| bknudson | there's probably no reason to have support in keystoneclient. | 00:41 |
| openstackgerrit | Steve Martinelli proposed openstack/python-keystoneclient: Add openid connect client support https://review.openstack.org/134700 | 00:41 |
| bknudson | maybe an application would want to handle revocation events | 00:42 |
| jamielennox | i saw alexander got his refactor of the event processing code through, hopefully we can make that work with the objects that auth_token provides | 00:42 |
| bknudson | what objects? | 00:42 |
| *** stevemar has joined #openstack-keystone | 00:42 | |
| *** ChanServ sets mode: +v stevemar | 00:42 | |
| jamielennox | _UserToken | 00:42 |
| jamielennox | https://github.com/openstack/keystonemiddleware/blob/master/keystonemiddleware/auth_token/_user_plugin.py | 00:43 |
| jamielennox | UserAuthPlugin - i was close | 00:43 |
| openstackgerrit | Steve Martinelli proposed openstack/python-keystoneclient: Add openid connect client support https://review.openstack.org/134700 | 00:44 |
| bknudson | yield data -- why can't we yield auth_ref? | 00:44 |
| stevemar | jamielennox, i'd appreciate a review of that guy ^ should be in a good state - there's a failing test that i am skipping related to config options | 00:44 |
| bknudson | don't we want handle_token to return an auth_ref? | 00:45 |
| *** r-daneel_ has joined #openstack-keystone | 00:45 | |
| jamielennox | bknudson: so i started like that, it meant that we were constructing an AccessInfo on the keystone side as well as on the middleware side | 00:45 |
| *** r-daneel has quit IRC | 00:45 | |
| bknudson | nice! | 00:45 |
| bknudson | isn't that what we want? | 00:46 |
| jamielennox | bknudson: if we yield data instead then keysotne never needs to know about AccessInfos | 00:46 |
| jamielennox | AccessInfo is still returned from the function | 00:46 |
| bknudson | I want keystone to know about AccessInfo. | 00:46 |
| jamielennox | and we still do all our validation with AccessInfo but middleware is constructing it for us | 00:46 |
| bknudson | we could push construction of AccessInfo up to the token provider | 00:47 |
| *** radez is now known as radez_g0n3 | 00:47 | |
| openstackgerrit | Deepti Ramakrishna proposed openstack/keystone: Reuse token_ref fetched in AuthContextMiddleware. https://review.openstack.org/190863 | 00:48 |
| stevemar | isn't that what adam wanted? | 00:48 |
| jamielennox | adam was looking for a much more complex object representation | 00:48 |
| jamielennox | my understanding is they didn't want AccessInfo as it is today on the server side, it does stupid things like add extra data to the token dictionary | 00:49 |
| stevemar | ah | 00:49 |
| bknudson | shoot. I thought we had something that was actually useful for once. :( | 00:49 |
| bknudson | I guess I should have looked at it first. | 00:49 |
| stevemar | have fun boys, i'm heading to dinner then airport | 00:49 |
| jamielennox | the ksa version should be better | 00:49 |
| jamielennox | stevemar: have a good trip | 00:50 |
| bknudson | godspeed | 00:50 |
| stevemar | i'm with delta and stopping in detroit... bad omens all over | 00:50 |
| bknudson | conference must be done | 00:51 |
| *** sbfox has quit IRC | 00:51 | |
| jamielennox | bknudson: anyway looking at the breakdown there it would seem to make sense, what's in fetch is always dealing with data, because the cache should just be another source of token data, like PKI or the identity server | 00:51 |
| jamielennox | but it conflicts with some of the stuff like having the cache deal with AccessInfo directly | 00:52 |
| bknudson | cache can't deal with accessinfo? | 00:52 |
| jamielennox | not if we keep yield data | 00:52 |
| jamielennox | becaues the validation logic is creating the AccessInfo | 00:53 |
| jamielennox | i was hoping i could yield and return so that you could do like auth_ref = yield data but i think that's why python 3's yield from is for | 00:54 |
| *** stevemar has quit IRC | 00:55 | |
| jamielennox | i don't think i can do it in py2 | 00:55 |
| bknudson | let's drop py2 support | 00:55 |
| jamielennox | :) | 00:56 |
| bknudson | so keystone is going to use the regular headers that auth_token would set | 00:57 |
| jamielennox | bknudson: that's my hope | 00:58 |
| bknudson | then it can just go through mapping like federation | 00:58 |
| jamielennox | or preferrably just the obect | 00:58 |
| bknudson | what's the object ? AccessInfo? | 00:59 |
| jamielennox | _UserAuthPlugin | 00:59 |
| jamielennox | it's essentially just a stripped down AccessInfo | 00:59 |
| bknudson | oh, it can pass that to policy? | 00:59 |
| jamielennox | bknudson: that's where i'm going with this | 00:59 |
| jamielennox | i want oslo.policy, oslo.context all to be based off of that | 01:00 |
| bknudson | _UserAuthPlugin? | 01:00 |
| jamielennox | rather than every service make up their own context dicts | 01:00 |
| jamielennox | yes | 01:00 |
| bknudson | until then we'll have to create context from _UserAuthPlugin | 01:01 |
| jamielennox | yes, and there are a couple of fields we may need to include in the _UserAuthPlugin that aren't currenlty there | 01:01 |
| jamielennox | but that's not a problem - honestly i don't think we use half of what's in our context anyway | 01:02 |
| jamielennox | i guess we can't remove the fields though because they're exposed to policy | 01:02 |
| bknudson | if auth_ref.version == 'v2.0' and not auth_ref.project_id: is going to need to be auth-token only since you can have unscoped v2 tokens. | 01:03 |
| bknudson | do we have to do delay_auth_decision? | 01:03 |
| bknudson | oh, and we need to support stupid admin token | 01:04 |
| bknudson | or else figure out a different way to bootstrap, which should probably do anyways | 01:04 |
| jamielennox | so delay_auth_decision is kept in the auth_token specific class | 01:09 |
| jamielennox | i don't enforce that on the base at all so we would need to check that via policy - which is how i think it should be done anyway | 01:10 |
| jamielennox | admin token i think is fairly easy, we just put a check in process_request before any of this validation happens | 01:10 |
| jamielennox | but yea, i have a comment for v2.0 and project_id, that should be auth_token only | 01:11 |
| bknudson | makes sense | 01:11 |
| jamielennox | it was almost a little disappointing that the only common checks left were binding and expiry time, but with revocations etc it will get more | 01:12 |
| jamielennox | i was looking at rearranging the auth_token validate as well, i think we should make it so that we do not cache PKI tokens | 01:13 |
| bknudson | what's the point of caching a PKI token? | 01:13 |
| jamielennox | that would make it cleaner to do PKI validation for keystone as well because we don't have to deal with the cache layer | 01:14 |
| jamielennox | bknudson: i've no idea | 01:14 |
| jamielennox | but we do it | 01:14 |
| bknudson | https://review.openstack.org/#/c/188650/ might help, since it puts offline validation into a method | 01:14 |
| bknudson | then could just move the call to _validate_offline before cache work | 01:15 |
| jamielennox | bknudson: yep, i had that patch rolled into this dependency for a while | 01:15 |
| bknudson | oh... did I mess it up? | 01:15 |
| bknudson | I didn't think it was in the list. | 01:15 |
| jamielennox | no i removed it because i was modifying the patch itself and it can be easily applied after as well | 01:16 |
| jamielennox | because i removed the AccessInfo bits and i didn't want to mess up your review chain | 01:16 |
| jamielennox | but yes, i think that should go first - before the cache check and limit the cache to online validations | 01:17 |
| bknudson | I wasn't sure how "Refactor _validate_token returns auth_ref only" fits in here anymore. Figured I'd just wip it and figure that out later if it's still interesting. | 01:18 |
| jamielennox | bknudson: oh - i thought that was applied? | 01:18 |
| *** henrynash has quit IRC | 01:18 | |
| jamielennox | there should be no reason to still be returning data from -validate_token | 01:19 |
| bknudson | well, your changes are returning data rather than auth_ref | 01:19 |
| bknudson | there's probably no need for that one anymore. | 01:20 |
| * jamielennox was looking at the wrong review and getting confused | 01:21 | |
| jamielennox | so _validate_token returns AccessInfo | 01:21 |
| jamielennox | which is what is used at the top level | 01:21 |
| bknudson | hmm, maybe it happens some other way | 01:21 |
| jamielennox | data is only used in _handle_token - which really should be called _fetch_token | 01:21 |
| bknudson | if we're going to be sharing _BaseAuthProtocol then it really does need its own unit tests. | 01:22 |
| *** browne has quit IRC | 01:23 | |
| jamielennox | agreed, there are a few reviews in front of it still to go through | 01:24 |
| jamielennox | (though they are moving well) | 01:24 |
| bknudson | jamielennox: I thought the class was modeled on oslo_middleware.base.Middleware because you were going to use it? | 01:24 |
| jamielennox | i just wanted to discuss it with you because of the differences with the AccessInfo changes | 01:24 |
| jamielennox | bknudson: i looked at using it but there are a bunch of dependencies to oslo_middleware | 01:24 |
| jamielennox | because it's not just the base class there are common middlewares in there | 01:25 |
| bknudson | I think there's some that we re-implement in keystone... | 01:25 |
| jamielennox | probably | 01:25 |
| bknudson | like a sizelimiter or something | 01:25 |
| bknudson | although we won't need that middleware with flask! | 01:26 |
| jamielennox | but i figured i could take the pattern that other middleware uses and just not take the actual class | 01:26 |
| bknudson | (and it is something that the container should implement for security) | 01:26 |
| jamielennox | replacing app with application for example needed changes all through the tests | 01:26 |
| *** ankita_wagh has joined #openstack-keystone | 01:26 | |
| *** henrynash has joined #openstack-keystone | 01:27 | |
| *** ChanServ sets mode: +v henrynash | 01:27 | |
| bknudson | well, probably don't even mention it in the comment then | 01:27 |
| jamielennox | bknudson: that was my plan :) i saw you reviewed it again and i was just going to remove all reference to oslo_middleware | 01:27 |
| bknudson | if it's like it but not the same then you'll need to explain all the differences or people are left guessing | 01:27 |
| jamielennox | and it does look like i'll need some sort of factory | 01:28 |
| jamielennox | i was hoping to avoid it on the keystone side | 01:28 |
| bknudson | you can always add it later (along with a test for it) | 01:28 |
| jamielennox | or at least not deal with options from paste | 01:28 |
| bknudson | maybe change the commit message to say "this class can eventually be used by keystone where the behavior is overridden to validate tokens against the database" or something... should be clearer | 01:30 |
| bknudson | of course it would be better to not mention keystone by name since it'll be available to anybody. | 01:31 |
| bknudson | "this class can eventually be used by a server where the behavior is overridden to validate tokens via some other method" | 01:31 |
| jamielennox | i was thinking of explicitly saying keystone | 01:32 |
| jamielennox | like don't override this unless you are keystone | 01:32 |
| bknudson | once it's public you can't stop me from using it. | 01:32 |
| jamielennox | because i can't imagine who else would use it | 01:32 |
| bknudson | better put some docs on it. | 01:32 |
| jamielennox | can't stop, but i might be able to say that the API is only as stable as keystone requires it to be | 01:33 |
| bknudson | maybe it could be used during testing to stub out keystone | 01:33 |
| bknudson | or maybe there will eventually be no keystone and it'll be overridden to validate saml | 01:34 |
| bknudson | ^ right ayoung ? | 01:34 |
| *** dims_ has quit IRC | 01:35 | |
| bknudson | I was just thinking about fernet tokens and the offline/online validation... | 01:35 |
| bknudson | since some validation is done offline and some online. | 01:35 |
| bknudson | although it's all online now | 01:36 |
| jamielennox | bknudson: i don't think any of fernet is validated by middleware? | 01:36 |
| bknudson | not yet but it could be in future | 01:37 |
| jamielennox | all the keys are handled on keystone side | 01:37 |
| bknudson | we just need a REST API to fetch the keys... he he | 01:37 |
| jamielennox | never again | 01:38 |
| jamielennox | dstanek: here? | 01:42 |
| dstanek | jamielennox: on cell phone yes :-) | 01:43 |
| *** sigmavirus24_awa is now known as sigmavirus24 | 01:43 | |
| jamielennox | dstanek: hmm, so this might be a bit difficult to see | 01:43 |
| jamielennox | dstanek: looking at https://review.openstack.org/#/c/190673/ is there anyway i can get a value back from the yield statement? | 01:44 |
| jamielennox | yielding data which is going to a contextmanager | 01:44 |
| dstanek | jamielennox: jas ill go back to laptop | 01:45 |
| jamielennox | dstanek: i guess the question can be theoretical, if you yield to a contextmanager can you get a value back from the yield | 01:45 |
| bknudson | I was surprised that the base _handle_token could just return and not yield. | 01:45 |
| jamielennox | and it's got to be python 2 compatible - because i *think* yield from would solve this | 01:45 |
| *** r-daneel_ has quit IRC | 01:46 | |
| bknudson | don't you iterate over it? | 01:47 |
| dstanek | jamielennox: and _handle_token is expected to return a list? | 01:48 |
| dstanek | a yield just turns a method into a generator or something that "returns" an iterable | 01:49 |
| *** ayoung has joined #openstack-keystone | 01:49 | |
| *** ChanServ sets mode: +v ayoung | 01:49 | |
| jamielennox | dstanek: but not when used with a contextmanager right? | 01:49 |
| bknudson | dstanek: I think he's taking advantage of https://docs.python.org/2/library/contextlib.html#contextlib.contextmanager | 01:49 |
| jamielennox | that just gives me a with | 01:49 |
| bknudson | ? maybe return self._handle_token(token) -> yield self._handle_token(token) | 01:50 |
| jamielennox | there is a oneline function line 504 that just wraps a contextmanager around a call | 01:50 |
| jamielennox | bknudson: thinking about it now i don't know if i want it there anyway | 01:51 |
| dstanek | jamielennox: yes correct because that treats it like a list on your behalf | 01:51 |
| bknudson | this stuff should be able to be implemented with abstract methods. | 01:52 |
| bknudson | although maybe the context manager is prettier | 01:52 |
| dstanek | https://hg.python.org/cpython/file/3156dd82df2d/Lib/contextlib.py#l57 | 01:53 |
| dstanek | contextmanager expects a generator that only generates one thing - the code is different in 2.7, but does the same thing | 01:54 |
| *** sbfox has joined #openstack-keystone | 01:54 | |
| dstanek | why use a contextmanager in that code if there isn't really any cleanup? | 01:54 |
| jamielennox | sorry back | 01:55 |
| jamielennox | dstanek: there is some cleanup | 01:55 |
| jamielennox | if everything goes well in the yielded function then you have to cache the token, or cache the failure | 01:55 |
| jamielennox | i was experimenting with like a before_ and after_ method, but if i used contextmanager i can just yield to the actual validator function and then handle the response | 01:56 |
| jamielennox | (or lack of exception) | 01:56 |
| jamielennox | and that way all the error handling i do is unique to the subclass | 01:57 |
| dstanek | all that would have to change to get rid of the contextmanager is to move the caching up a level right? | 01:57 |
| jamielennox | dstanek: i can't move the caching up | 01:57 |
| dstanek | also, i'm playing devil's advocate. in reality i'd probably be fine with this. doesn't look awful | 01:57 |
| jamielennox | so that function will be implemented on the keystone side as well | 01:58 |
| jamielennox | so to move it up a level would mean we would need to implement caching in the same way on the keystone side as well | 01:58 |
| bknudson | keystone could override _cache_token to do nothing | 01:58 |
| jamielennox | so the reason i was looking to get an auth_ref back from the yield is so i could do additional validation in _handle_token | 01:58 |
| jamielennox | but i think that's probably the wrong place for it anyway, you should override a validate function and do it after the contextmanager bit | 01:59 |
| jamielennox | bknudson: yea, i tried that - it can be done but the contextmanager is so much prettier | 01:59 |
| bknudson | everything is better with generators | 02:00 |
| bknudson | that should be all we do | 02:00 |
| dstanek | :-) | 02:00 |
| jamielennox | i pulled out an itertools.product the other day - felt like a god | 02:00 |
| bknudson | that was prety | 02:00 |
| bknudson | I figured twisted would be built on generators but the examples don't show much | 02:01 |
| *** markvoelker has joined #openstack-keystone | 02:01 | |
| dstanek | i'll be back in a bit ... | 02:02 |
| jamielennox | dstanek: np, thanks | 02:02 |
| *** htruta has quit IRC | 02:02 | |
| jamielennox | bknudson: i think in newer versions you can do generator based stuff | 02:02 |
| jamielennox | when i last used twisted it was all addCallback | 02:03 |
| bknudson | the mail client example here uses it: https://twistedmatrix.com/trac/ | 02:03 |
| bknudson | yikes! | 02:03 |
| jamielennox | i have just not done enough to figure out what that means | 02:04 |
| *** dims has joined #openstack-keystone | 02:05 | |
| *** sbfox has quit IRC | 02:06 | |
| *** markvoelker has quit IRC | 02:07 | |
| *** browne has joined #openstack-keystone | 02:07 | |
| *** bknudson has quit IRC | 02:10 | |
| *** ankita_wagh has quit IRC | 02:23 | |
| *** Ephur has quit IRC | 02:24 | |
| *** BAKfr has quit IRC | 02:31 | |
| openstackgerrit | Chenhong Liu proposed openstack/keystone: Add testcases for list_role_assignments of v3 domains https://review.openstack.org/187899 | 02:32 |
| *** BAKfr has joined #openstack-keystone | 02:37 | |
| *** dims has quit IRC | 02:39 | |
| openstackgerrit | Dave Chen proposed openstack/keystone: Move endpoint_filter migrations into keystone core https://review.openstack.org/186988 | 02:57 |
| *** dsirrine has joined #openstack-keystone | 03:04 | |
| *** stevemar has joined #openstack-keystone | 03:09 | |
| *** ChanServ sets mode: +v stevemar | 03:09 | |
| *** kiran-r has joined #openstack-keystone | 03:12 | |
| *** spandhe has quit IRC | 03:15 | |
| *** sigmavirus24 is now known as sigmavirus24_awa | 03:18 | |
| *** ankita_wagh has joined #openstack-keystone | 03:20 | |
| *** geoffarnold has quit IRC | 03:25 | |
| *** sbfox has joined #openstack-keystone | 03:25 | |
| *** geoffarnold has joined #openstack-keystone | 03:26 | |
| *** sbfox has quit IRC | 03:27 | |
| *** sbfox1 has joined #openstack-keystone | 03:27 | |
| *** geoffarnold has quit IRC | 03:30 | |
| *** geoffarnold has joined #openstack-keystone | 03:30 | |
| *** richm has quit IRC | 03:31 | |
| openstackgerrit | Dave Chen proposed openstack/keystone: Move endpoint filter into keystone core https://review.openstack.org/183377 | 03:39 |
| *** dims has joined #openstack-keystone | 03:40 | |
| *** stevemar has quit IRC | 03:41 | |
| *** stevemar2 has joined #openstack-keystone | 03:41 | |
| *** ChanServ sets mode: +v stevemar2 | 03:41 | |
| *** fifieldt has joined #openstack-keystone | 03:42 | |
| *** dguerri` is now known as dguerri | 03:44 | |
| *** dsirrine has quit IRC | 03:44 | |
| *** kiran-r has quit IRC | 03:45 | |
| *** dims has quit IRC | 03:45 | |
| *** geoffarnold has quit IRC | 03:45 | |
| openstackgerrit | Jamie Lennox proposed openstack/keystonemiddleware: Refactor token fetching https://review.openstack.org/190673 | 03:46 |
| openstackgerrit | Jamie Lennox proposed openstack/keystonemiddleware: Refactor _confirm_token_bind takes AccessInfo https://review.openstack.org/179676 | 03:46 |
| openstackgerrit | Jamie Lennox proposed openstack/keystonemiddleware: Extract basic validation processing to base class https://review.openstack.org/180818 | 03:46 |
| openstackgerrit | Jamie Lennox proposed openstack/keystonemiddleware: Make token bind work with a request https://review.openstack.org/180817 | 03:46 |
| openstackgerrit | Jamie Lennox proposed openstack/keystonemiddleware: Create a simple base class from AuthProtocol https://review.openstack.org/180816 | 03:46 |
| openstackgerrit | Dave Chen proposed openstack/keystone: Move endpoint filter into keystone core https://review.openstack.org/183377 | 03:46 |
| openstackgerrit | Dave Chen proposed openstack/keystone: Move endpoint_filter migrations into keystone core https://review.openstack.org/186988 | 03:46 |
| *** sbfox1 has quit IRC | 03:49 | |
| *** markvoelker has joined #openstack-keystone | 03:50 | |
| *** geoffarnold has joined #openstack-keystone | 03:50 | |
| *** kiran-r has joined #openstack-keystone | 03:51 | |
| *** dguerri is now known as dguerri` | 03:54 | |
| *** markvoelker has quit IRC | 03:55 | |
| *** kiranr has joined #openstack-keystone | 03:55 | |
| *** kiran-r has quit IRC | 03:55 | |
| *** kiranr has quit IRC | 04:02 | |
| *** tobe has joined #openstack-keystone | 04:04 | |
| *** sbfox has joined #openstack-keystone | 04:06 | |
| *** stevemar2 has quit IRC | 04:12 | |
| *** fangzhou has quit IRC | 04:14 | |
| *** sbfox has quit IRC | 04:19 | |
| *** fangzhou has joined #openstack-keystone | 04:21 | |
| *** ozialien has joined #openstack-keystone | 04:22 | |
| *** sbfox has joined #openstack-keystone | 04:24 | |
| *** fangzhou has quit IRC | 04:34 | |
| *** sbfox has quit IRC | 04:39 | |
| *** chlong is now known as chlong_mtg | 04:59 | |
| *** geoffarnold has quit IRC | 05:02 | |
| *** geoffarnold has joined #openstack-keystone | 05:04 | |
| *** tobe has quit IRC | 05:06 | |
| *** kiran-r has joined #openstack-keystone | 05:17 | |
| *** kiran-r has quit IRC | 05:21 | |
| *** kiran-r has joined #openstack-keystone | 05:21 | |
| openstackgerrit | Dave Chen proposed openstack/keystone: Move endpoint_filter migrations into keystone core https://review.openstack.org/186988 | 05:23 |
| *** tobe has joined #openstack-keystone | 05:28 | |
| *** geoffarnold has quit IRC | 05:29 | |
| *** geoffarnold has joined #openstack-keystone | 05:30 | |
| *** markvoelker has joined #openstack-keystone | 05:39 | |
| *** markvoelker has quit IRC | 05:44 | |
| openstackgerrit | Jamie Lennox proposed openstack/keystonemiddleware: Refactor token fetching https://review.openstack.org/190673 | 05:59 |
| openstackgerrit | Jamie Lennox proposed openstack/keystonemiddleware: Separate the fetch and validate token processes https://review.openstack.org/190940 | 05:59 |
| openstackgerrit | Jamie Lennox proposed openstack/keystonemiddleware: Don't cache signed tokens https://review.openstack.org/190941 | 05:59 |
| openstackgerrit | Dave Chen proposed openstack/keystone: Move endpoint_filter migrations into keystone core https://review.openstack.org/186988 | 06:04 |
| *** tobe has quit IRC | 06:05 | |
| *** chlong_mtg is now known as chlong | 06:06 | |
| *** ajayaa has joined #openstack-keystone | 06:15 | |
| ajayaa | HI guys. Can a single LDAP server contain identity data for multiple domains? | 06:16 |
| ajayaa | It seems no from https://github.com/openstack/keystone/blob/master/keystone/identity/backends/ldap.py#L47 | 06:17 |
| ajayaa | jamielennox ^^ | 06:17 |
| jamielennox | ajayaa: umm, i should know this but LDAP isn't really my area | 06:18 |
| jamielennox | i'm not sure sorry | 06:18 |
| ajayaa | np jamielennox. | 06:19 |
| lhcheng_ | ajayaa: I think that should be possible. In the ldap config, you can specify a filter to used. So for single ldap, you can setup a domain and map it to a certain org only. | 06:30 |
| ajayaa | lcheng_, Do I have to enable domain specific driver for this? | 06:32 |
| ajayaa | lhcheng_ ^^ | 06:32 |
| *** belmoreira has joined #openstack-keystone | 06:40 | |
| *** tobe has joined #openstack-keystone | 06:42 | |
| *** ozialien has quit IRC | 06:45 | |
| *** henrynash has quit IRC | 06:50 | |
| lhcheng_ | ajayaa: yeah | 06:50 |
| *** henrynash has joined #openstack-keystone | 06:51 | |
| *** ChanServ sets mode: +v henrynash | 06:51 | |
| lhcheng_ | ajayaa: you probably need to setup something like: https://github.com/openstack/keystone/tree/master/keystone/tests/unit/config_files/domain_configs_multi_ldap | 06:51 |
| *** browne has quit IRC | 06:53 | |
| ajayaa | I think in Kilo, you can store domain specific conf data in database rather than in files. | 06:54 |
| ajayaa | lhcheng_ ^^ | 06:55 |
| lhcheng_ | yup | 06:55 |
| lhcheng_ | that would be better than having the domain config files | 06:57 |
| lhcheng_ | just trying to describe the setup of a multiple domains that may point to same ldap for identity | 06:57 |
| *** ajayaa has quit IRC | 06:57 | |
| *** lufix has joined #openstack-keystone | 07:05 | |
| *** ajayaa has joined #openstack-keystone | 07:13 | |
| morganfainberg | lhcheng_: oh god. Ouch brain hurts. | 07:15 |
| morganfainberg | :P | 07:16 |
| *** lhcheng_ has quit IRC | 07:21 | |
| *** ankita_wagh has quit IRC | 07:27 | |
| *** markvoelker has joined #openstack-keystone | 07:28 | |
| *** markvoelker has quit IRC | 07:33 | |
| *** gordc has joined #openstack-keystone | 07:35 | |
| *** rlt has joined #openstack-keystone | 07:35 | |
| *** henrynash has quit IRC | 07:58 | |
| *** dims has joined #openstack-keystone | 08:02 | |
| *** ajayaa has quit IRC | 08:02 | |
| *** dims has quit IRC | 08:07 | |
| *** kiranr has joined #openstack-keystone | 08:15 | |
| *** kiran-r has quit IRC | 08:15 | |
| *** kiranr has quit IRC | 08:15 | |
| *** kiranr has joined #openstack-keystone | 08:16 | |
| *** chlong is now known as chlong_afk | 08:16 | |
| *** kiranr is now known as kiran-r | 08:18 | |
| *** ajayaa has joined #openstack-keystone | 08:19 | |
| *** jistr has joined #openstack-keystone | 08:20 | |
| *** henrynash has joined #openstack-keystone | 08:23 | |
| *** ChanServ sets mode: +v henrynash | 08:23 | |
| openstackgerrit | Morgan Fainberg proposed openstack/keystonemiddleware: Ensure cache keys are a known/fixed length https://review.openstack.org/186971 | 08:37 |
| *** e0ne has joined #openstack-keystone | 08:38 | |
| *** ajayaa has quit IRC | 08:40 | |
| *** fhubik has joined #openstack-keystone | 08:42 | |
| *** tobe has quit IRC | 08:47 | |
| *** tobe has joined #openstack-keystone | 08:48 | |
| *** crinkle has quit IRC | 08:50 | |
| *** esp has quit IRC | 08:52 | |
| *** esp has joined #openstack-keystone | 08:53 | |
| *** pnavarro_ has joined #openstack-keystone | 08:55 | |
| *** e0ne has quit IRC | 08:57 | |
| *** woodster_ has quit IRC | 09:01 | |
| *** chlong_afk has quit IRC | 09:03 | |
| *** afazekas has joined #openstack-keystone | 09:04 | |
| *** dguerri` is now known as dguerri | 09:05 | |
| *** jimbaker has quit IRC | 09:10 | |
| *** jimbaker has joined #openstack-keystone | 09:13 | |
| *** jimbaker has quit IRC | 09:14 | |
| *** jimbaker has joined #openstack-keystone | 09:14 | |
| *** markvoelker has joined #openstack-keystone | 09:16 | |
| *** markvoelker has quit IRC | 09:21 | |
| *** aix has joined #openstack-keystone | 09:22 | |
| *** jimbaker has quit IRC | 09:35 | |
| *** jimbaker has joined #openstack-keystone | 09:39 | |
| *** jimbaker has quit IRC | 09:39 | |
| *** jimbaker has joined #openstack-keystone | 09:39 | |
| *** davechen is now known as davechen_afk | 09:43 | |
| *** dims has joined #openstack-keystone | 09:49 | |
| *** dims has quit IRC | 09:50 | |
| *** dims has joined #openstack-keystone | 09:56 | |
| *** aix has quit IRC | 10:00 | |
| openstackgerrit | henry-nash proposed openstack/keystone-specs: Support data driven test plans for role assignment testing https://review.openstack.org/190996 | 10:04 |
| *** e0ne has joined #openstack-keystone | 10:04 | |
| *** e0ne is now known as e0ne_ | 10:04 | |
| *** e0ne_ is now known as e0ne | 10:06 | |
| openstackgerrit | henry-nash proposed openstack/keystone-specs: Support data driven test plans for role assignment testing https://review.openstack.org/190996 | 10:08 |
| *** henrynash has quit IRC | 10:12 | |
| *** jimbaker has quit IRC | 10:13 | |
| *** jimbaker has joined #openstack-keystone | 10:18 | |
| *** jimbaker has quit IRC | 10:18 | |
| *** jimbaker has joined #openstack-keystone | 10:18 | |
| *** aix has joined #openstack-keystone | 10:28 | |
| openstackgerrit | Morgan Fainberg proposed openstack/keystoneauth: Move to the keystoneauth1 namespace https://review.openstack.org/191003 | 10:32 |
| morganfainberg | jamielennox: ^ | 10:33 |
| *** pnavarro_ has quit IRC | 10:36 | |
| samueldmq | morning | 10:44 |
| morganfainberg | samueldmq: allo | 10:45 |
| *** fifieldt has quit IRC | 10:58 | |
| *** crinkle has joined #openstack-keystone | 10:59 | |
| *** henrynash has joined #openstack-keystone | 11:03 | |
| *** ChanServ sets mode: +v henrynash | 11:03 | |
| *** fhubik is now known as fhubik_afk | 11:07 | |
| *** tobe has quit IRC | 11:10 | |
| morganfainberg | ayoung: ping | 11:19 |
| morganfainberg | ayoung: re: old reviews, since you are one of the people hanging onto a bunch of them | 11:19 |
| morganfainberg | ayoung: i know you keep saying you might be working on them in the future, but lets be honest, having a bunch of lingering reviews with no eyes on them causes headaches for reviews / new reviewers. We should be abandoning things that haven't been actively worked on in a while, they can be restored later (even searchable in gerrit) | 11:21 |
| morganfainberg | ayoung: I'd like to cleanup the lingering stuff so we really only have at most ~60days of reviews that are active [assuming negative feedback and no followup] | 11:21 |
| *** fhubik_afk is now known as fhubik | 11:35 | |
| *** e0ne is now known as e0ne_ | 11:38 | |
| samueldmq | morganfainberg, what do I do regarding the policy meeting ? | 11:45 |
| samueldmq | morganfainberg, just wait until next week to find a good time for it | 11:45 |
| samueldmq | morganfainberg, or should I at least add a point in the cross-project meeting ? | 11:46 |
| morganfainberg | samueldmq: what is becoming a cross project meeting thing? | 11:47 |
| morganfainberg | samueldmq: i am not sure what this meeting is supposed to accomplish | 11:47 |
| samueldmq | morganfainberg, i) agreement on the roadmap of dynamic policies, then overview spec merged | 11:48 |
| samueldmq | morganfainberg, ii) agreement on specific implementation points from roadmap | 11:49 |
| *** e0ne_ has quit IRC | 11:49 | |
| samueldmq | morganfainberg, this all can be accomplished through reviews and ML threads, however a meeting would accelerate the process | 11:50 |
| samueldmq | morganfainberg, and then ensure we will have a good portion of dynamic policies in L | 11:50 |
| *** markvoelker has joined #openstack-keystone | 11:50 | |
| morganfainberg | samueldmq: the overview spec should not be merged | 11:53 |
| morganfainberg | at all | 11:53 |
| morganfainberg | it is not a represenataion of what is going on | 11:54 |
| morganfainberg | samueldmq: i've been meaning to -2 that giant spec of doom for a while | 11:56 |
| morganfainberg | samueldmq: so what I'm looking for is a set of clearly scoped specs for work in L. or even one spec. | 11:58 |
| morganfainberg | but this wish-washy dumping ground of a spec that contains "everything" is not helpful | 11:58 |
| morganfainberg | we can break it up into work-items that are tied together. loosly, etc | 11:59 |
| morganfainberg | and we can move the specs to L series as the dependencies are completed. | 11:59 |
| samueldmq | morganfainberg, makes sense | 11:59 |
| samueldmq | morganfainberg, would a wiki be helpful ? | 12:00 |
| morganfainberg | but right now i still have not seen anything but a mass of specs that describe something that we can gauge success against. | 12:00 |
| morganfainberg | yes | 12:00 |
| samueldmq | morganfainberg, so we could keep the overview there | 12:00 |
| morganfainberg | a wiki that contains the overview and links to specs would be great | 12:00 |
| morganfainberg | that isn't tied to a release | 12:00 |
| samueldmq | morganfainberg, and a spec should be | 12:00 |
| samueldmq | morganfainberg, I agree with you on this point | 12:00 |
| morganfainberg | yes | 12:00 |
| morganfainberg | something we can say "this was successfuly completed" | 12:00 |
| morganfainberg | the overview spec cannot ever be successful in it's current incarnation | 12:01 |
| samueldmq | haha | 12:01 |
| morganfainberg | since dynamic policy is a massive moving target | 12:01 |
| morganfainberg | whcih is why i am concerned that I have yet to see clear targets for L | 12:01 |
| morganfainberg | or even a clear "put the scaffolding in place" work item. | 12:01 |
| samueldmq | ok, from my point of view, having the policy CRUD + fetch in ksmiddleware is a good target, but need to discuss with others | 12:02 |
| morganfainberg | it's "this is how everything has to work in a perfect world" all at once | 12:02 |
| morganfainberg | so, I don't think KSM should be pulling the policy file | 12:02 |
| morganfainberg | this should be something not "auth_token" | 12:03 |
| morganfainberg | it can live in the KSM package | 12:03 |
| morganfainberg | but i don't see this as being "auth_token" | 12:03 |
| samueldmq | morganfainberg, but in a standalone middleware | 12:03 |
| morganfainberg | we should really keep to the "do one thing and do it well" | 12:03 |
| morganfainberg | yes | 12:03 |
| samueldmq | morganfainberg, a different filter, as auth_token is | 12:03 |
| morganfainberg | yes | 12:03 |
| morganfainberg | though we're doing the hardpart before we're addressing the other hard part | 12:03 |
| samueldmq | morganfainberg, I agree ... I have poc locally where I've put it in the auth_token, but I will refactor it | 12:04 |
| morganfainberg | we should be making sure olso.policy and all the tools we rely on can handle the new policy constructs | 12:04 |
| morganfainberg | we should *not* be trying to centrally source these files until we are there. don't change how people work for a worse UX for the deployers | 12:04 |
| morganfainberg | but honestly, i think we're backwards here now. | 12:04 |
| samueldmq | morganfainberg, so first improve/create whatever CRUD for policies we will need | 12:04 |
| morganfainberg | no | 12:04 |
| samueldmq | morganfainberg, and then try to get people using it ? | 12:04 |
| morganfainberg | improve/create the tools around policy | 12:05 |
| morganfainberg | create crud interfaces that make sense | 12:05 |
| morganfainberg | land use-ful things that pull from crud interfaces | 12:05 |
| morganfainberg | the 2nd and 3rd items can be done concurrently | 12:05 |
| morganfainberg | but right now we need things such as overlay in oslo.policy (ability to merge policy constructs) | 12:05 |
| openstackgerrit | Merged openstack/python-keystoneclient: tox env for Bandit https://review.openstack.org/182912 | 12:05 |
| morganfainberg | etc | 12:05 |
| * morganfainberg is stepping in here because this is headed into a road that is very rocky | 12:06 | |
| * marekd where is morganfainberg today? | 12:06 | |
| morganfainberg | still in berlin | 12:06 |
| morganfainberg | i head home tomorrow | 12:06 |
| marekd | morganfainberg: so you cant be in berlin, they have the best roads in the world :P | 12:07 |
| samueldmq | morganfainberg, ok | 12:07 |
| samueldmq | morganfainberg, but role sets, hierarchical roles, etc can come later | 12:07 |
| samueldmq | morganfainberg, after the dynamic mechanism for CRUD on policies right / | 12:07 |
| samueldmq | ? | 12:07 |
| morganfainberg | samueldmq: pretty much. and i want to see some specs that clearly define what is being approached | 12:09 |
| samueldmq | morganfainberg, k I will create the wiki first, with overview (I won't copy paste, will create based on that) | 12:10 |
| samueldmq | morganfainberg, and point to existing specs + see what is missing | 12:10 |
| morganfainberg | oh you can c&p the spec ;) | 12:10 |
| morganfainberg | and then change it for wiki-ness | 12:10 |
| samueldmq | morganfainberg, k will see | 12:10 |
| samueldmq | morganfainberg, I will create it under https://wiki.openstack.org/wiki/Keystone | 12:10 |
| morganfainberg | sounds good | 12:10 |
| samueldmq | morganfainberg, is that the right place ? | 12:10 |
| samueldmq | morganfainberg, nice | 12:10 |
| morganfainberg | in short we want to have some clear targets to hit | 12:10 |
| morganfainberg | and a graph of the work and how we're approaching it | 12:11 |
| morganfainberg | i'm not willing to take on a moving target that is likely to get 1/3 implemented and just stall | 12:11 |
| samueldmq | morganfainberg, ++ I will make it as better as I can, will ping you once I have that wiki done | 12:12 |
| samueldmq | morganfainberg, thanks for helping :) | 12:12 |
| *** bknudson has joined #openstack-keystone | 12:25 | |
| *** ChanServ sets mode: +v bknudson | 12:25 | |
| *** raildo has joined #openstack-keystone | 12:27 | |
| *** josecastroleon has joined #openstack-keystone | 12:30 | |
| *** dsirrine has joined #openstack-keystone | 12:35 | |
| morganfainberg | gyee, topol, bknudson: stable interface discussion - http://www.gnu.org/software/libtool/manual/html_node/Libtool-versioning.html we should do this. | 12:41 |
| morganfainberg | (cc mordred ) | 12:41 |
| bknudson | switch to libtool? | 12:41 |
| morganfainberg | no | 12:42 |
| morganfainberg | the type of versioning | 12:42 |
| morganfainberg | for the API | 12:42 |
| bknudson | semver would be more consistent | 12:42 |
| morganfainberg | bknudson: this would be for the backend interface and/or REST interface | 12:43 |
| bknudson | it kind of looks like how nova microversioning works | 12:44 |
| morganfainberg | it's a little different | 12:44 |
| morganfainberg | but yeah | 12:44 |
| morganfainberg | nova's microversioning is a full API contract for version X.Y | 12:44 |
| mordred | bknudson: yah - it's microversioning except it's been aroudn for ages and has well understood semantics | 12:44 |
| morganfainberg | yeah | 12:45 |
| *** devananda has joined #openstack-keystone | 12:45 | |
| mordred | bknudson: so I'm suggesting we lift some of the verbage for ease of communication | 12:45 |
| * morganfainberg waves at devananda | 12:45 | |
| mordred | since it's conceptually the same and is how every C library on linux systems knows if it can link or not these days | 12:45 |
| *** afazekas has quit IRC | 12:46 | |
| bknudson | this allows you to have multiple libhellos on the system? | 12:47 |
| mordred | yes | 12:47 |
| bknudson | I must be able to look at a lib and see what it supports... | 12:47 |
| mordred | it's a system for describing ranges of supported versions | 12:47 |
| openstackgerrit | Victor Sergeyev proposed openstack/keystone: Comparision of database models and migrations. https://review.openstack.org/80630 | 12:47 |
| bknudson | objdump -p /lib/libc.so.6 | 12:48 |
| bknudson | Version definitions: | 12:48 |
| bknudson | is that it? | 12:48 |
| bknudson | "1 0x01 0x0865f4e6 libc.so.6" -> "27 0x00 0x0b792650 GCC_3.0" | 12:49 |
| bknudson | so it seems like you'd increase the "current" and "age" as you add new features and increase the "age" as you drop deprecated | 12:50 |
| bknudson | revision must be for bug fixes | 12:51 |
| mordred | http://www.gnu.org/software/libtool/manual/libtool.html#Updating-version-info | 12:51 |
| mordred | yah | 12:51 |
| mordred | revision is for bug fixes | 12:51 |
| mordred | there's a set of rules about when to update library versions there | 12:51 |
| *** fhubik is now known as fhubik_afk | 12:52 | |
| bknudson | "If any interfaces have been removed or changed since the last public release, then set age to 0." | 12:53 |
| *** fhubik_afk is now known as fhubik | 12:53 | |
| samueldmq | morganfainberg, I added a subsection in the wiki called 'Liberty Priorities', so we can add 'dynamic policies' + others (reseller, etc ?) if needed | 12:56 |
| morganfainberg | samueldmq: thanks | 12:56 |
| samueldmq | morganfainberg, np, (I am still doing that, was just checking the naming for the section) :) | 12:57 |
| *** fhubik has quit IRC | 12:59 | |
| *** dsirrine has quit IRC | 13:00 | |
| *** e0ne has joined #openstack-keystone | 13:01 | |
| *** dims is now known as dimsum__ | 13:02 | |
| *** henrynash has quit IRC | 13:04 | |
| *** htruta has joined #openstack-keystone | 13:07 | |
| *** henrynash has joined #openstack-keystone | 13:16 | |
| *** ChanServ sets mode: +v henrynash | 13:16 | |
| *** richm has joined #openstack-keystone | 13:17 | |
| ayoung | morganfainberg, they are all active. If I have a lingering review that I am not going to pursue, I kill it. What you are seeing is an artifact of how slow our process is. | 13:19 |
| ayoung | I have mostly spec reviews. Specs need to die. | 13:20 |
| morganfainberg | ayoung: the reasons specs suck is because git is the wrong tool for it | 13:22 |
| ayoung | morganfainberg, as for the -2 on https://review.openstack.org/#/c/147651/ that has been the most valuable document I've had for communicating the overall concept. It is not a dumping ground, but rather a real roadmap. What I was hoping for on that was approal for the whole process | 13:22 |
| ayoung | but people are too detail oriented when it come to specs | 13:22 |
| morganfainberg | it is a dumping ground spec. it should be in the wiki (samueldmq is doing that now) | 13:22 |
| ayoung | the reason specs suck is because specs are the wrong approach | 13:23 |
| ayoung | here is what I would rather have | 13:23 |
| morganfainberg | no git is thr wrong tool for the job | 13:23 |
| ayoung | Hold on | 13:23 |
| morganfainberg | specs are not bad, specs should be tied to the BP system | 13:23 |
| ayoung | 1. We define a problem to solve and agree on that, no solution | 13:23 |
| *** nkinder__ has quit IRC | 13:23 | |
| morganfainberg | bps are just *so* bad in launchpad we can't collaborate on anything there | 13:23 |
| ayoung | 2. We write code and docs for that solution in one go | 13:23 |
| ayoung | IT should just be an etherpad for design | 13:24 |
| *** henrynash has quit IRC | 13:24 | |
| ayoung | BP should link to an etherpad. | 13:24 |
| ayoung | We are smothering ourselves with workflow here. | 13:24 |
| morganfainberg | i'm ready to kill specs and bps, everything is a bug collaborate on the bug so we have a coherant conversation | 13:24 |
| ayoung | morganfainberg, YES! | 13:25 |
| morganfainberg | etherpad is not a good tool | 13:25 |
| morganfainberg | it is fine for live collab, it is not fine for the cannonical source | 13:25 |
| ayoung | morganfainberg, ether pad is a good tool, just not a good "definitive one" | 13:25 |
| ayoung | tyes, you and eye agree.... | 13:25 |
| ayoung | heh | 13:25 |
| ayoung | you and I agree | 13:25 |
| bknudson | somebody was asking me about a keystonemiddleware release -- we added support for using v3 to get the revocation list and they want to use it. | 13:26 |
| ayoung | morganfainberg, the cannonical should be the docs that get written with the code. Not the spec. | 13:26 |
| morganfainberg | anyway, the overview spec is a dumping ground spec, intended or not. samueldmq is moving it to the wiki - so we can split things up into peices we can say "are complete" | 13:26 |
| *** jdennis has quit IRC | 13:26 | |
| morganfainberg | ayoung: but we don't lose the data. it also less "git" / tool specific then | 13:26 |
| ayoung | morganfainberg, that is fine. It was originally a blog post, that I kep updating with the links to the specs. I wanted something more official. | 13:26 |
| morganfainberg | ayoung: yeah wiki.openstack is a good place for this | 13:26 |
| ayoung | Workds for me. But I did want to get an official approval of the approach | 13:27 |
| ayoung | I think most people still don't understand it | 13:27 |
| *** jdennis has joined #openstack-keystone | 13:27 | |
| ayoung | I think you do, and maybe team Brazil. | 13:27 |
| morganfainberg | ayoung: I don't get it at all now | 13:27 |
| morganfainberg | honestly | 13:27 |
| ayoung | morganfainberg, Ha | 13:27 |
| morganfainberg | i have no clue what you're driving at anymore | 13:27 |
| ayoung | Is that a response to my last email? | 13:27 |
| morganfainberg | and i don't like the fact that the whole thing looks like a giant moving target that will not be implemented | 13:27 |
| morganfainberg | somewhat | 13:28 |
| samueldmq | morganfainberg, ayoung yes, and I agree that is mostly describing the use case (like better describing what is in the bp), so wiki should be fine | 13:28 |
| samueldmq | we keep specs for the steps | 13:28 |
| samueldmq | ayoung, I think I do :) | 13:28 |
| *** jdennis has quit IRC | 13:28 | |
| morganfainberg | ayoung: but it's not really clear to me or (afaict) othe rpeople what the target is. | 13:28 |
| ayoung | morganfainberg, that might be an artifact of it being in the Spec. Maybe this is one that, for now, best belongs in an etherpad, so we can treat it as a collaboration | 13:28 |
| morganfainberg | i can't concentrate on this today tbh though | 13:28 |
| morganfainberg | getting things dealt with so i can fly home tomorrow | 13:29 |
| bknudson | still in berlin? | 13:29 |
| morganfainberg | bknudson: yes | 13:29 |
| morganfainberg | bknudson: leave tomorrow morning | 13:29 |
| morganfainberg | skipping israel and headed home instead. | 13:30 |
| ayoung | morganfainberg, I'm tryin g to get people to collaborate on an essentially broken piece of OpenStack. I'm willing to concede, oto shift, to work with people, but everyone is either so heads down i ntheir corner or ,when they do pop up, propsing solutions that will break the dross project aspec, that it is hard. NP Hard. | 13:30 |
| samueldmq | morganfainberg, ayoung I can setup an etherpad to improve collaboration as well, and keep the wiki updated with it ... | 13:30 |
| bknudson | I'm also boycotting israel. | 13:30 |
| ayoung | morganfainberg, so I am trying to focus on getting the incremental changes in that all show value themselves | 13:30 |
| ayoung | such as just fetching policy from Keystone etc | 13:30 |
| bknudson | due to the palestinian situation | 13:30 |
| morganfainberg | ayoung: that isn't really clear to me that your focusing on that | 13:30 |
| morganfainberg | and hoensty i think that is not the part we need to be working on, but that is a separate conversation | 13:31 |
| ayoung | morganfainberg, I'm doing my best to communicate it. Blame it on my inability to communicate then. | 13:31 |
| ayoung | blame it on the rain | 13:31 |
| ayoung | morganfainberg, there is an ordering to the solution | 13:31 |
| morganfainberg | ayoung: no it's that the conversation is all over the map and we have a spec that "encompasses *everything*" and that has been the source of truth | 13:32 |
| ayoung | and that is why the overview spec.... | 13:32 |
| morganfainberg | so the conversation can't be about "yes this is on the map but we need X anyway, lets do X" | 13:32 |
| ayoung | morganfainberg, that is why the overview | 13:32 |
| *** jdennis has joined #openstack-keystone | 13:32 | |
| morganfainberg | except the overview is the onlything anyone is talking about | 13:32 |
| ayoung | I don't care the format, but it needs to be the starting point | 13:32 |
| ayoung | good | 13:32 |
| morganfainberg | then this wont go anywhere | 13:32 |
| morganfainberg | sorry | 13:32 |
| morganfainberg | what you need is overview + current target | 13:33 |
| morganfainberg | current target should be in work while the steps beyond are being discussed in the overview | 13:33 |
| morganfainberg | without that, you're looking at M or N or O cycle for the start of the work afaict | 13:33 |
| morganfainberg | if there is something non-controversial | 13:33 |
| morganfainberg | that is the foundation, we should be getting that in place as well | 13:33 |
| morganfainberg | concurrent with the other further reaching things that are a bit more nebulous | 13:34 |
| bknudson | when I was following the dynamic policy the steps that were outlined looked like they were useful and good to do by themselves. | 13:34 |
| bknudson | we've already got all sorts of wacky stuff that nobody uses so if nobody uses it then this will just be another thing | 13:34 |
| morganfainberg | bknudson: that is kind of what i want to avoid. | 13:35 |
| morganfainberg | i want less 1/2 implemented things. | 13:35 |
| ayoung | morganfainberg, then we need people to engage on the problem in a cross project reasonable way | 13:35 |
| morganfainberg | in fact maybe we just punt this whole thing into it's own project including the Policy Admin thing. | 13:35 |
| ayoung | I;'ve been trying to do this right | 13:35 |
| morganfainberg | divorce this from keystone itself. | 13:35 |
| *** bradjones has quit IRC | 13:35 | |
| ayoung | I posted the specs, I've gotten the summit session, I | 13:36 |
| ayoung | 've broken it down in to reasonalbe -to implement standalong-show their own value steps | 13:36 |
| ayoung | we can shit can the whiole effort if you really think that things are o\k as is | 13:36 |
| morganfainberg | that way there it is less shoehorn this into keystone | 13:36 |
| ayoung | morganfainberg, we should shitcan keystone as well | 13:37 |
| ayoung | maybe all of openstack | 13:37 |
| morganfainberg | ayoung: sure do it | 13:37 |
| ayoung | just run vCloud | 13:37 |
| ayoung | or just run everything on Amazon and Google | 13:37 |
| morganfainberg | anyway i need to go. | 13:37 |
| ayoung | hell, lets go back to running it all on mainframes | 13:37 |
| morganfainberg | i'm really needing food | 13:37 |
| bknudson | if you've got a "reasonalbe -to implement standalong-show their own value step" that we can do in L then let's get that done. | 13:37 |
| ayoung | bknudson, I do, and they are posted as specs | 13:38 |
| bknudson | which one is it? | 13:38 |
| ayoung | the overveiw spec origianlly had l;inks to them | 13:38 |
| morganfainberg | ayoung: it is not clear what that is. i see a ton of specs | 13:38 |
| *** bradjones has joined #openstack-keystone | 13:38 | |
| *** bradjones has quit IRC | 13:38 | |
| *** bradjones has joined #openstack-keystone | 13:38 | |
| morganfainberg | and the overview seems to span multiple cycles | 13:38 |
| morganfainberg | hence the -2 this morning | 13:38 |
| ayoung | morganfainberg, blame it on the revisions of the overview, then. THey were all there an laid out | 13:38 |
| ayoung | I'll get them into an etherpad or something | 13:38 |
| ayoung | I have them all in the trello, too | 13:40 |
| bknudson | I think you're asking a lot for us to all follow the whole arc of what you're proposing... what the first step that we can get done in L? | 13:40 |
| ayoung | https://trello.com/b/260v4Gs7/dynamic-policy | 13:40 |
| morganfainberg | ayoung: please don't use trello. | 13:40 |
| samueldmq | bknudson, another challenge is to get things agreed in a cross-project view | 13:40 |
| morganfainberg | it's another place for a source of truth | 13:40 |
| morganfainberg | we are going to get kanban boards here in openstack soon | 13:40 |
| ayoung | bknudson, I don't know. The answer changes the closer we get to the release. THe number of changes for Keystione itself are relativley small, most of them are in middleware and policy | 13:41 |
| bknudson | samueldmq: sure, but you don't have to convince keystone cores of that. | 13:41 |
| morganfainberg | lets keep the source of truth to the official sources | 13:41 |
| ayoung | morganfainberg, I tired. You just -2ed it, though | 13:41 |
| samueldmq | I think an etherpad is fine for now | 13:41 |
| bknudson | if this is cross-project then it should be a cross-project spec | 13:42 |
| samueldmq | bknudson, get things agreed with keystone cores ? | 13:42 |
| bknudson | there's a place for thos | 13:42 |
| morganfainberg | no, get this into the wiki and/or etherpads [wiki for things that are less in flux] | 13:42 |
| samueldmq | bknudson, I think cross-project specs is for adoptions (after implemented ? not sure) | 13:42 |
| ayoung | morganfainberg, there is no good solution, so please stop being critical of my attempts to actuall communicate this. | 13:43 |
| ayoung | bknudson, I had a cross-project session at the summit. You might recall no one from the other projects showed up | 13:43 |
| morganfainberg | i am being critical that you're moving it to a tool that most of the people in the community does not use. | 13:43 |
| ayoung | keystone needs to solve this | 13:43 |
| morganfainberg | and will not use. | 13:43 |
| bknudson | :( | 13:43 |
| samueldmq | https://etherpad.openstack.org/p/dynamic-policies should be fine for now | 13:43 |
| morganfainberg | moving to trello is hiding this from view | 13:43 |
| morganfainberg | please do not do that. | 13:44 |
| bknudson | every project somehow needs to be convinced that this is worth their while | 13:44 |
| bknudson | maybe need to get the TC involved? | 13:44 |
| ayoung | morganfainberg, meh. I don;'t love trello, just give me something close to as useful. Etherpad provides no notifications, and there is too much in flux for it to be a wiki. | 13:44 |
| bknudson | if this is really hurting openstack adoption | 13:44 |
| ayoung | BPs suck,. specs suck. it all sucks...so let me just use it through this release, and we'll use Kanban when we get them | 13:44 |
| bknudson | do you have a spec proposed to nova, for example? | 13:45 |
| samueldmq | bknudson, maybe we will need that later .. but I think organizing our docs ^ + trying to setup a dynamic policies meeting are good first steps | 13:45 |
| bknudson | getting a meeting going is great! | 13:45 |
| samueldmq | bknudson, yes, and we could add a point to the existing cross-project meeting to talk a bit about that , and setup our own meeitng | 13:46 |
| bknudson | but considering how much time it takes to get things done, if you want to get something going in L ... | 13:46 |
| samueldmq | bknudson, if people don't get involved enoguh, we call TC police :) | 13:46 |
| samueldmq | yes I wanted to set it up for next week ... I am looking at our docs now, so we can move on that front | 13:47 |
| bknudson | are there changes needed in nova and other projects? | 13:47 |
| samueldmq | nova wants to define their very default policy (source of truth) in python code | 13:48 |
| bknudson | do they have a blueprint for that already? | 13:48 |
| morganfainberg | ayoung: i can't stop you from using trello, i can say i seriously disapprove | 13:48 |
| openstackgerrit | Diane Fleming proposed openstack/keystone-specs: Add side-by-side comparison table of v2 and v3 APIs https://review.openstack.org/187027 | 13:48 |
| samueldmq | they have some requirements, we need to put them on the table and discuss them | 13:48 |
| samueldmq | and make everybody aware of what's going on | 13:48 |
| samueldmq | so we won't suffer with adoption later | 13:48 |
| bknudson | do other projects also want to have default policy in python? | 13:49 |
| samueldmq | bknudson, we don't know, for now just nova showed up | 13:49 |
| morganfainberg | bknudson: i think other projects are going to follow nova | 13:49 |
| *** kiran-r has quit IRC | 13:49 | |
| morganfainberg | bknudson: to be faiur | 13:49 |
| morganfainberg | bknudson: whatever nova moves on | 13:49 |
| bknudson | how about keystone? | 13:50 |
| bknudson | I guess I don't see how this is related to dynamic policy. | 13:50 |
| morganfainberg | bknudson: i'm inclined to follow nova as well - if it works, it presents some aspect of consistency in OpenStack | 13:50 |
| openstackgerrit | Diane Fleming proposed openstack/keystone-specs: Add side-by-side comparison table of v2 and v3 APIs https://review.openstack.org/187027 | 13:50 |
| morganfainberg | bknudson: it is only tangentially related | 13:51 |
| morganfainberg | bknudson: it's how the base policy is defined. which could be 100% independant of the dynamic policy | 13:51 |
| *** woodster_ has joined #openstack-keystone | 13:51 | |
| samueldmq | bknudson, today dynamic policies includes the dynamic CRUD of policies + improvement of roles, etc | 13:51 |
| morganfainberg | bknudson: nothing proposed in dynamic policy mandates that we own policy at the base level if we wanted to pivot away from that | 13:51 |
| samueldmq | bknudson, I think we should split that, and call dynamic policies what really makes it change/move dinamically, i.e, policy crud | 13:52 |
| morganfainberg | if* | 13:52 |
| bknudson | maybe it will be good just to get all projects talking about and working on policy if we pick up this work for nova. | 13:52 |
| bknudson | so get the workgroup going and discussing what nova wants to do, get it done for L, and then for M maybe they'll be more interested in dynamic policy. | 13:53 |
| morganfainberg | bknudson: it's the same pattern microversions (APIs) has taken | 13:53 |
| morganfainberg | bknudson: ++ that is a perfect goal | 13:53 |
| openstackgerrit | Victor Sergeyev proposed openstack/keystone: Fix mysql_engine and FK in *_token tables https://review.openstack.org/174871 | 13:54 |
| morganfainberg | bknudson: having a clear goal for L that we can say is complete (internal to Keystone or not) would help with things when wemove to tyring to drive adoption [esp. if nova is involved] | 13:54 |
| samueldmq | bknudson, that's a good approach I think ... 'hey, nova is working with the dynamic policy stuff, we need that as well ... it's M priority' | 13:54 |
| morganfainberg | i think this cycle is going to be laying some groundwork in the tools that policy is based on [not nessiciarly the stuff keystone itself does] | 13:55 |
| morganfainberg | how policy files are layered together, how the base policy for a project is defined - putting the markers in the ground to change the direction we're headed on policy | 13:56 |
| samueldmq | morganfainberg, maybe + CRUD of policies and dynamic fetch on ksmiddleware, which is pretty simple (I ahve a poc locally) | 13:56 |
| morganfainberg | samueldmq: you're going to find you have to deal with cache coherancy | 13:57 |
| morganfainberg | for that | 13:57 |
| morganfainberg | it's not easy | 13:57 |
| morganfainberg | that is *very* hard | 13:57 |
| morganfainberg | it's not a simple fetch | 13:57 |
| samueldmq | morganfainberg, for now we use a cache_timeout | 13:58 |
| morganfainberg | it's a fetch and make sure policy is sync'd between all nodes behind a given HAProxy (for example) at the same time | 13:58 |
| morganfainberg | annnnnnnnnd | 13:58 |
| samueldmq | morganfainberg, oh, and with haproxy it is a single ksmiddleware .. right | 13:58 |
| morganfainberg | if someone does partial upgrades (possible with microversions) now you have to handle incompatible policy files | 13:58 |
| samueldmq | ? | 13:58 |
| morganfainberg | yeah | 13:58 |
| morganfainberg | no* | 13:59 |
| morganfainberg | it isn't | 13:59 |
| morganfainberg | each process has it's own middleware | 13:59 |
| samueldmq | morganfainberg, yeah | 13:59 |
| morganfainberg | heck each eventlet worker process has it's own middleware | 13:59 |
| morganfainberg | this is not "easy" | 13:59 |
| morganfainberg | the POC is easy, the solution is hard. | 13:59 |
| samueldmq | morganfainberg, even harder if they have different versions | 13:59 |
| morganfainberg | also granted that policy files between versions of APIs are not guaranteed to be compatible | 14:00 |
| samueldmq | morganfainberg, you see it better than me, but yes, there are some challenges in there | 14:00 |
| morganfainberg | the nova defining the policy makes a lot more sense in my view than keystone owning the baseline policy | 14:00 |
| samueldmq | morganfainberg, I don't think keystone should own the primary source of truth | 14:00 |
| morganfainberg | anyway | 14:00 |
| morganfainberg | i'm still trying to et out of here for food | 14:01 |
| * morganfainberg checks out for a bit | 14:01 | |
| *** sigmavirus24_awa is now known as sigmavirus24 | 14:01 | |
| samueldmq | morganfainberg, I think nova should own that (suppose policy.json as today) ... the CMS would be in charge of uploading that policy for nova endpoint, and setting middleware to keep it in sync | 14:01 |
| samueldmq | morganfainberg, k bon apetit | 14:01 |
| *** jaosorior has joined #openstack-keystone | 14:02 | |
| *** csoukup has joined #openstack-keystone | 14:03 | |
| *** henrynash has joined #openstack-keystone | 14:03 | |
| *** ChanServ sets mode: +v henrynash | 14:03 | |
| *** fangzhou has joined #openstack-keystone | 14:06 | |
| ayoung | samueldmq, bknudson so...the idea of splitting the policy (yesterdays) email is to let Nova control what is essential for Nova, and let the dynamic stuff continue as well | 14:06 |
| ayoung | did you guys read it and understand what I was proposing, cus that is probably a good starting point | 14:07 |
| bknudson | I haven't been able to keep up with the mailing list lately -- too much work :( | 14:07 |
| ayoung | bknudson, http://www.mail-archive.com/openstack-dev@lists.openstack.org/msg55467.html | 14:08 |
| ayoung | samueldmq, image we called enforce twice, but with two different policy files | 14:09 |
| ayoung | and each has a check for an api | 14:09 |
| ayoung | so...for example: | 14:09 |
| ayoung | http://git.openstack.org/cgit/openstack/keystone/tree/etc/policy.v3cloudsample.json#n43 | 14:10 |
| ayoung | create_project | 14:10 |
| ayoung | henrynash, coded that as rule:admin_and_matching_project_domain_id | 14:10 |
| ayoung | so the check from the first policy would look like this: | 14:10 |
| ayoung | (ignoring cloud_admin for the moment) | 14:11 |
| *** kfox1111 has joined #openstack-keystone | 14:11 | |
| ayoung | "identity:create_project": "role:admin" | 14:11 |
| *** browne has joined #openstack-keystone | 14:11 | |
| ayoung | the second check would look like this | 14:11 |
| ayoung | "identity:create_project": "domain_id:%(project.domain_id)s" | 14:12 |
| ayoung | now if we want to change the role that can perform create project, people would only edit the first file | 14:12 |
| ayoung | say we create a new role called project_admin | 14:13 |
| ayoung | they would change the first file to | 14:13 |
| henrynash | ayoung: the thing I was unclear about was the “scope check”….is it really a check? Or is it maybe “scope source” or something liek that? | 14:13 |
| ayoung | "identity:create_project": "role:project_admin" | 14:13 |
| ayoung | henrynash, you are right | 14:13 |
| ayoung | henrynash, it could be done in code | 14:13 |
| ayoung | it just needs to be done | 14:14 |
| ayoung | henrynash, once again, I am trying to do incrementals, so I'm just shifting from a known point. | 14:15 |
| *** gordc has left #openstack-keystone | 14:15 | |
| henrynash | ayoung: the only thing that makes me a bit nervous is whether there might be different scope references needed…..I always wondered about an update where you wanted to to check something about both the unmodified entity as well as what you wanted to set it to | 14:16 |
| henrynash | ayoung: and but maybe the source scope would still be teh same | 14:16 |
| henrynash | ayoung: what you suggest would certaiinly, I think, take some of the black art out of wrting policy rules…since you have to sort of just know where to pick up the appropriaet scope from…which ci different from in a GET, LIST and DELETE | 14:18 |
| henrynash | (I’m not sure my example is stricly correct, but you get the idea) | 14:19 |
| *** nkinder__ has joined #openstack-keystone | 14:20 | |
| ayoung | henrynash, lets take the hardest thing you bring up "you wanted to to check something about both the unmodified entity as well as what you wanted to set it to" | 14:21 |
| ayoung | I think the answer there is: would you reallt want to make that dynamic | 14:21 |
| ayoung | if so, then, we'd have an issue, but that is where we are at today | 14:22 |
| ayoung | But I suspect that making that dynamic would be unlikely; you'd need to know way too much about the details of the objects. It seems to me more like something you want to turn-on or off completely | 14:23 |
| *** timcline has joined #openstack-keystone | 14:26 | |
| *** timcline has quit IRC | 14:29 | |
| henrynash | ayoung: I suspect you are right…I think it would be one way or the other.... | 14:33 |
| *** geoffarnold has quit IRC | 14:34 | |
| ayoung | henrynash, look how long that took, and this is one detail, and you are saavy on policy.... | 14:34 |
| ayoung | any wonder why I am getting frustrated? | 14:35 |
| henrynash | ayoung: fair comment, guv | 14:36 |
| ayoung | There are so many WTF moments I have had with OpenStack. *IF* We're trying to head to a micro-service architecture, we need to distribute authorization | 14:36 |
| ayoung | if we don't distribute authorization...lets not do a microservice architecture | 14:36 |
| ayoung | merge nova and cinder and glance back into a single project, implicitly trust and be done with it | 14:37 |
| ayoung | but...we are headed the other way, more and more services, each providing their own addition | 14:38 |
| openstackgerrit | Rodrigo Duarte proposed openstack/keystoneauth: Add Keystone2KeystoneAuthPlugin for K2K federation https://review.openstack.org/188581 | 14:38 |
| ayoung | and we want them to have a common view of authorization. | 14:38 |
| *** e0ne is now known as e0ne_ | 14:49 | |
| *** fangzhou has quit IRC | 14:53 | |
| *** fangzhou_ has joined #openstack-keystone | 14:54 | |
| *** e0ne_ is now known as e0ne | 14:55 | |
| *** htruta has quit IRC | 14:59 | |
| *** zzzeek has joined #openstack-keystone | 15:08 | |
| *** belmoreira has quit IRC | 15:10 | |
| *** alex_xu is now known as alexus | 15:11 | |
| *** e0ne is now known as e0ne_ | 15:18 | |
| *** obedmr has joined #openstack-keystone | 15:24 | |
| obedmr | hi there, does anyone knows if token_flush is not anymore required in Kilo? I used to see it in the Icehouse documentation, but not in Kilo's. I tried to run the "keystone-manage token_flush" and got a "NotImplemented" exception, thanks | 15:26 |
| *** e0ne_ is now known as e0ne | 15:27 | |
| openstackgerrit | Rodrigo Duarte proposed openstack/keystoneauth: Add Keystone2KeystoneAuthPlugin for K2K federation https://review.openstack.org/188581 | 15:31 |
| *** _cjones_ has joined #openstack-keystone | 15:40 | |
| morganfainberg | obedmr: it is not reuqired if you use fernet tokens | 15:42 |
| morganfainberg | obedmr: it is required / should be used if you use pki, pkiz, or uuid tokens | 15:42 |
| morganfainberg | obedmr: fernet tokens do not store anything in the DB, so there is nothing to flush | 15:42 |
| ayoung | morganfainberg, more correct to say "ayoung learned from mistakes of the past and made the revocation events flush automatically so you don't need to schedule anything" | 15:43 |
| ayoung | and then add | 15:43 |
| ayoung | "that is going to come back to bite us, too" | 15:43 |
| morganfainberg | ayoung: tomato, tomato.. | 15:44 |
| *** fangzhou_ has quit IRC | 15:44 | |
| ayoung | was token flush implemented as a backend specific thing? | 15:44 |
| obedmr | morganfainberg: got it, thanks for that, actually I'm using uuid tokens, so, what would be the correct way to flush it? | 15:45 |
| morganfainberg | obedmr: the same as in juno, it's a keystone-manage command | 15:46 |
| morganfainberg | obedmr: you can schedule it with cron | 15:46 |
| morganfainberg | for example | 15:46 |
| morganfainberg | but make sure you're running it in only one place at any given time | 15:46 |
| obedmr | yea, but when I run the command "keystone-manage token_flush", I'm getting NotImplemented exception, | 15:47 |
| obedmr | I'm trying that on Ubuntu 14.04 with Kilo Release | 15:48 |
| morganfainberg | obedmr: weird.. | 15:50 |
| morganfainberg | obedmr: it should be there.... | 15:51 |
| morganfainberg | obedmr: https://github.com/openstack/keystone/blob/stable/kilo/keystone/cli.py#L235 | 15:51 |
| morganfainberg | obedmr: can you use paste.openstack.org and show me the exception? | 15:52 |
| obedmr | sure, for some reason it's going to https://github.com/openstack/keystone/blob/stable/kilo/keystone/token/persistence/backends/kvs.py#L355 | 15:52 |
| obedmr | morganfainberg: here is: http://paste.openstack.org/show/285217/ | 15:53 |
| morganfainberg | uhm.. what are you setting the driver= in the [token] section of the keystone config? | 15:53 |
| ayoung | obedmr, does your config file ... | 15:54 |
| ayoung | yeah what morganfainberg said | 15:54 |
| morganfainberg | ayoung: I'm awake *i swear* | 15:54 |
| morganfainberg | ayoung: :P | 15:54 |
| obedmr | morganfainberg: driver = keystone.token.persistence.backends.memcache.Token | 15:54 |
| morganfainberg | obedmr: ah the flush is only needed if you use SQL backend | 15:54 |
| morganfainberg | obedmr: don't worry about it with memcached | 15:54 |
| morganfainberg | though we should probably catch NotImplemented and make the error message "not needed" or soemthing like that | 15:55 |
| *** belmoreira has joined #openstack-keystone | 15:55 | |
| *** belmoreira has quit IRC | 15:55 | |
| ayoung | morganfainberg, he needs to switch to SQL, or a restart will un-revoke tokens | 15:55 |
| ayoung | or switch to using revocation events | 15:56 |
| obedmr | morganfainberg: oooh, got it, excellent, yeah, NotNeeded would be a better thing. Thanks a lot for the help. Next time I'll be able to help others if they have same question | 15:56 |
| morganfainberg | ayoung: memcache is broken as a persistence backend and it's pretty much just awful | 15:56 |
| morganfainberg | ayoung: we should probably docment "THIS BACKEND SHOULD NEVER BE USED"\ | 15:56 |
| morganfainberg | ayoung: uuid tokens = restart means no un-revoke | 15:56 |
| morganfainberg | ayoung: pki tokens, it would cause an unrevoke | 15:56 |
| ayoung | morganfainberg, ah...right | 15:57 |
| morganfainberg | ayoung: my recommendation is: use fernet ;) | 15:57 |
| *** _cjones_ has quit IRC | 15:58 | |
| ayoung | morganfainberg, is there a real problem with memcache and HTTPD? I thought there were only issues with eventlet | 15:58 |
| morganfainberg | ayoung: yes. the memcache backend is slow, has a ton of house keeping, doesn't handle failover between memcache servers, potentially causes your whole environment to explode if you issue too many tokens for a single user /revoke too many globally | 15:59 |
| morganfainberg | ayoung: if we went to 100% revocation events, memcache would be a lot less bad [just suffers the "restart unauthorizes everything" issue] | 16:00 |
| morganfainberg | since all the housekeeping logic could be stripped out (which is what makes it slow) | 16:00 |
| ayoung | morganfainberg, and we could even do that for PKI, if it were not for the Horizon hash issue. | 16:00 |
| morganfainberg | ayoung: yep | 16:00 |
| ayoung | morganfainberg, I saw the Rev Event refactoring went through. Next step is to make it use model and access info | 16:01 |
| ayoung | anyone interested in picking that up and running with it? | 16:01 |
| *** roxanaghe has joined #openstack-keystone | 16:05 | |
| *** wuhg has joined #openstack-keystone | 16:06 | |
| openstackgerrit | Raildo Mascena de Sousa Filho proposed openstack/keystone: Bye Bye Domain Table https://review.openstack.org/161854 | 16:09 |
| *** lufix has quit IRC | 16:10 | |
| *** kiran-r has joined #openstack-keystone | 16:14 | |
| wuhg | anyone has installed keystone kilo by following http://docs.openstack.org/kilo/install-guide/install/apt/content/keystone-install.html | 16:14 |
| wuhg | i met the same problem as https://www.mail-archive.com/openstack@lists.openstack.org/msg12425.html | 16:15 |
| *** henrynash has quit IRC | 16:18 | |
| *** diazjf has joined #openstack-keystone | 16:21 | |
| *** dguerri is now known as dguerri` | 16:22 | |
| *** htruta has joined #openstack-keystone | 16:22 | |
| *** henrynash has joined #openstack-keystone | 16:24 | |
| *** ChanServ sets mode: +v henrynash | 16:24 | |
| *** e0ne has quit IRC | 16:24 | |
| *** viktors is now known as viktors|afk | 16:26 | |
| samueldmq | ayoung, hi.. was afk, reading up | 16:26 |
| samueldmq | ayoung, so the point is to split role checking (do I have access to this api? ) of scope checking (in which circumstances I may access this api) | 16:28 |
| *** gyee_ has joined #openstack-keystone | 16:28 | |
| *** _cjones_ has joined #openstack-keystone | 16:32 | |
| *** pnavarro has joined #openstack-keystone | 16:33 | |
| samueldmq | ayoung, and role checking could be done out of service (middleware ? ) | 16:34 |
| ayoung | samueldmq, yep | 16:34 |
| samueldmq | ayoung, nice makes sense, but we can split that after having middleware fetching policy right ? | 16:35 |
| ayoung | samueldmq, either order. | 16:35 |
| gyee_ | ayoung, are the dorms still available? | 16:35 |
| samueldmq | ayoung, I think morganfainberg had some directions where we could start , it would be amazing if we could agree easily on that | 16:35 |
| ayoung | gyee_, yes. She reserved a handful of rooms | 16:35 |
| samueldmq | ayoung, we can both split policy file or split the roles themselves | 16:36 |
| ayoung | samueldmq, amazing indeed. | 16:36 |
| samueldmq | ayoung, the latter is better imo | 16:36 |
| samueldmq | ayoung, for example | 16:36 |
| ayoung | spolit the roles? | 16:36 |
| samueldmq | I meant rules | 16:37 |
| samueldmq | "identity:create_project": (("role:admin"), ("domain_id:%(project.domain_id)s")) | 16:38 |
| samueldmq | not sure separating in a tuple is a good example | 16:38 |
| gyee_ | ayoung, how do we reserve the dorms? | 16:38 |
| samueldmq | but in a way we could distinguish between the roles enforced vs scope | 16:39 |
| ayoung | gyee_, I'm in touch with an admin at BU | 16:39 |
| samueldmq | ayoung, ~ | 16:39 |
| samueldmq | ^ | 16:39 |
| ayoung | its cheaper that way, I'll put you and lbragstad in touch with her directly | 16:39 |
| ayoung | ah, yeah, split rules | 16:39 |
| gyee_ | ayoung, thanks, we may have three attending | 16:39 |
| ayoung | gyee_, you need dorms for 3 ? | 16:39 |
| *** pnavarro has quit IRC | 16:40 | |
| gyee_ | ayoung, yes, they are co-ed right? roxanaghe may be joining us as well | 16:40 |
| samueldmq | ayoung, or just keep role + scope in a same sentence, we can parse them and identify what roles are, anyway | 16:41 |
| ayoung | gyee_, fairly sure they are. | 16:42 |
| *** browne has quit IRC | 16:43 | |
| *** lhcheng has joined #openstack-keystone | 16:49 | |
| *** ChanServ sets mode: +v lhcheng | 16:49 | |
| *** lhcheng has quit IRC | 16:51 | |
| lbragstad | ayoung: I ended up booking at the Hyatt (same as dstanek) | 16:51 |
| lbragstad | ayoung: sorry, I should have updated you | 16:52 |
| ayoung | lbragstad, ah, good to know. Not a problem | 16:52 |
| *** obedmr has quit IRC | 16:52 | |
| ayoung | lbragstad, she's got 5 rooms reserved. I don;t think there is any cost associated with that. I'm guessing that dorm occupancy is low enough during the summer that they tend to be used more for transient housing than during the winter | 16:53 |
| lbragstad | ayoung: ++ yeah, that's pretty common | 16:53 |
| gyee_ | lbragstad, that 300 simoleons per night right? | 16:57 |
| gyee_ | for hyatt | 16:57 |
| lbragstad | gyee_: I ended up using the corporate travel tool and got it at a cheaper rate | 16:59 |
| lbragstad | gyee_: but when I called them, that's what they were saying | 16:59 |
| lbragstad | s/they were/the hotel person was/ | 16:59 |
| gyee_ | ding, its not even showing up on our corp travel tool, lemme double click | 17:00 |
| lbragstad | gyee_: there was a cheaper room at the buckminster | 17:00 |
| lbragstad | gyee_: but i believe it was the last one they had available | 17:00 |
| *** henrynash has quit IRC | 17:01 | |
| gyee_ | that's ok, I don't mind bunk with somebody at the dorm | 17:02 |
| *** obedmr has joined #openstack-keystone | 17:06 | |
| *** henrynash has joined #openstack-keystone | 17:07 | |
| *** ChanServ sets mode: +v henrynash | 17:07 | |
| *** HT_sergio has joined #openstack-keystone | 17:08 | |
| *** ankita_wagh has joined #openstack-keystone | 17:09 | |
| *** ankita_wagh has quit IRC | 17:10 | |
| *** kiran-r has quit IRC | 17:10 | |
| HT_sergio | does anyone know "coreycb" or how I can get in touch with him | 17:10 |
| *** ankita_wagh has joined #openstack-keystone | 17:10 | |
| *** henrynash has quit IRC | 17:11 | |
| HT_sergio | he opened a bug against python-memcache that pytohn-keystoneclient is having in python3. | 17:12 |
| HT_sergio | can anyone point me in the direction of the guys working on that please | 17:12 |
| *** lhcheng has joined #openstack-keystone | 17:15 | |
| *** ChanServ sets mode: +v lhcheng | 17:15 | |
| *** jaosorior has quit IRC | 17:15 | |
| *** browne has joined #openstack-keystone | 17:20 | |
| *** gyee_ has quit IRC | 17:23 | |
| openstackgerrit | Michael Tupitsyn proposed openstack/keystone: Fix debug message in flush_expired_tokens job https://review.openstack.org/191157 | 17:30 |
| *** ankita_wagh has quit IRC | 17:32 | |
| *** radez_g0n3 is now known as radez | 17:38 | |
| david8hu | ayoung, I will be attending the mid-cycle meetup. | 17:40 |
| ayoung | david8hu, excellent. | 17:40 |
| david8hu | ayoung, I like to stay at the dorm, but hated making the bed every morning, so Hyatt for me :) | 17:40 |
| *** spandhe has joined #openstack-keystone | 17:42 | |
| ayoung | Heh | 17:42 |
| ayoung | david8hu, I can teach you how to make a bed to West Point standards. Hospital corners at 45 degrees, tight enough to bounce a dime off the collar | 17:42 |
| ayoung | Wanna know the secret? | 17:43 |
| *** kiran-r has joined #openstack-keystone | 17:43 | |
| openstackgerrit | Michael Tupitsyn proposed openstack/keystone: Fix debug message in flush_expired_tokens job https://review.openstack.org/191157 | 17:45 |
| *** ankita_wagh has joined #openstack-keystone | 17:46 | |
| david8hu | ayoung, I rather have the expert do it for me. LOL | 17:46 |
| *** jistr has quit IRC | 17:48 | |
| ayoung | david8hu, you can't afford my rates | 17:48 |
| david8hu | ayoung, very limited budget | 17:49 |
| ayoung | The hyatt is a good option. It is right across the river from BU, so an easy walk, and really nice in summer time. | 17:50 |
| ayoung | I was at BU yesterday checking out the room we have. We actually have two reserved, a larger room for the main meeting, and an overflow room. The overflow is downstairs, and I don't expect we will actually need it | 17:52 |
| ayoung | The main room is roughly the size of what we used at Rackspace, approx twice the size of what we used at Geekdom....maybe the size of the larger rooms from the summit. | 17:53 |
| ayoung | So, enough space for a main discussion, and also break down into subgroups | 17:53 |
| *** roxanaghe has quit IRC | 17:54 | |
| *** gyee_ has joined #openstack-keystone | 17:57 | |
| *** fangzhou has joined #openstack-keystone | 18:00 | |
| *** e0ne has joined #openstack-keystone | 18:00 | |
| *** ankita_w_ has joined #openstack-keystone | 18:02 | |
| *** ankita_wagh has quit IRC | 18:02 | |
| *** cloudnull is now known as cloudkiller | 18:03 | |
| *** Ephur has joined #openstack-keystone | 18:04 | |
| *** cloudkiller is now known as cloudnull | 18:06 | |
| *** e0ne has quit IRC | 18:13 | |
| *** e0ne has joined #openstack-keystone | 18:19 | |
| *** aix has quit IRC | 18:22 | |
| *** e0ne is now known as e0ne_ | 18:25 | |
| david8hu | ayoung, I do like to see westpoint style bed making | 18:28 |
| ayoung | ++ | 18:29 |
| openstackgerrit | Kevin Fox proposed openstack/keystone-specs: Unscoped Service Catalog https://review.openstack.org/190732 | 18:29 |
| *** kiran-r has quit IRC | 18:30 | |
| *** e0ne_ has quit IRC | 18:30 | |
| samueldmq | david8hu, ayoung 'Making A West Point Bed' https://www.youtube.com/watch?v=Yra3Fwux2p8 | 18:34 |
| samueldmq | hah | 18:34 |
| david8hu | samueldmq, I am sure ayoung can do it faster then the boys in the videos ;) | 18:39 |
| *** bknudson has quit IRC | 18:39 | |
| samueldmq | david8hu, ++ | 18:40 |
| kfox1111 | ayoung: thanks for the reviews. Would a domain scoped token run into the same issues with the catalog? Can you convert a domain scoped token to a project scoped one later? | 18:43 |
| ayoung | that is a joke. It would not actually work | 18:44 |
| ayoung | you sleep on it one night and it gets all loose, you need to tighten it each day | 18:44 |
| ayoung | kfox1111, two different tokens, get them each with the original request | 18:45 |
| kfox1111 | I was thinking you'd want to pass an unscoped token to the vm so that it can talk to keystone and convert it to a domain scoped or a project scope as it needed. | 18:45 |
| ayoung | kfox1111, ok that is better, but you would not want to pass an unscoped token to the VM...too much power....let me think.... | 18:46 |
| kfox1111 | I was under the impression scoped -> unscoped or scoped to a different type of scoped was going to be restricted at some point? | 18:46 |
| kfox1111 | really ideally, there would be a service scoped token too. | 18:46 |
| ayoung | kfox1111, I need coffee to think...one sec | 18:46 |
| kfox1111 | ok. :) | 18:47 |
| kfox1111 | with a service scoped token, the service couldn't give it to a different service to use. | 18:47 |
| kfox1111 | ala kerberos service tokens. | 18:47 |
| samueldmq | ayoung, kfox1111 it would require one request to keystone for every request on other projects = bottleneck | 18:48 |
| ayoung | nah] | 18:48 |
| ayoung | ok...let's start at the begining | 18:48 |
| ayoung | Nova itself is creating the new users, not the user that requested the workflow | 18:48 |
| kfox1111 | correct. | 18:49 |
| ayoung | the nova service user needs a scoped token in order to create the VM user. | 18:49 |
| kfox1111 | sure. its an admin currently. | 18:49 |
| ayoung | now, it gets that token using its credentials, and explicitly scoping to the the service-user domain | 18:49 |
| kfox1111 | ok. | 18:49 |
| ayoung | now...that the vm-specific user exists, you inject it whereever it needs to go...the VM in this case, right? | 18:50 |
| kfox1111 | no, it sticks the username/password in the nova database for future reference. | 18:50 |
| kfox1111 | now, when the vm needs its token, it contacts the metadata server and says "give me a token" | 18:50 |
| ayoung | kfox1111, what is that "future reference?" | 18:50 |
| ayoung | why ? | 18:50 |
| kfox1111 | the metadata server then looks up the username/password for the keystone user associated with the vm that's trying to get the token, | 18:51 |
| kfox1111 | authenticate with keystone using that username/password, and get the unscoped token for the user. | 18:51 |
| ayoung | kfox1111, no way! | 18:51 |
| kfox1111 | it then passes the token back to the vm. | 18:51 |
| kfox1111 | in this way, the vm user's creds are never known to the vm. | 18:51 |
| ayoung | kfox1111, you don't need a user per VM...just use the nova user, and a trust from the person that requested it. | 18:52 |
| *** rlt has quit IRC | 18:52 | |
| kfox1111 | earlier when the I discussed this with some keystone folks at the summit, trusts were considered too heavy for this task. Also the trust roles are very very corse grained and give the vm way too much power with trusts. | 18:53 |
| ayoung | kfox1111 completely backwards | 18:53 |
| ayoung | trusts are as light weight as new user records | 18:53 |
| kfox1111 | heat does create users in a similar manner today. | 18:53 |
| ayoung | trust roles are more fine grained than user records | 18:54 |
| ayoung | kfox1111, I know, but heat is doing something different | 18:54 |
| ayoung | kfox1111, if you want to make a new user, it is to separate concerns. Let that user request tokens itself | 18:54 |
| ayoung | put the password on the VM and let it fly | 18:54 |
| kfox1111 | that was brought up in the spec. | 18:54 |
| ayoung | but trusts make more sense: | 18:54 |
| kfox1111 | there's a major flaw with that though. | 18:54 |
| kfox1111 | policy at sites like mine won't allow users to create multiple user accounts, especially ones that could potentially out last the user's stay at the lab. | 18:55 |
| kfox1111 | but vm's will need to since they are part of the project. | 18:55 |
| ayoung | kfox1111, trusts make more sense | 18:55 |
| ayoung | kfox1111, OK,...here is how is should work | 18:55 |
| kfox1111 | by having nova manage the user/password, and never making it available to the user, that issue is sidestepped. | 18:55 |
| kfox1111 | if trusts were fine enough grained, I almost might agree. I'm not sure how they would work with barbican acl's though. | 18:56 |
| ayoung | user talks to nova to do something. Nova creates a trust, and stick that trust ID in the VM. VM needs a token, NOva user executes the trust and gets token. Trustor is the user that asked for the initial work | 18:56 |
| ayoung | now, say I am that user | 18:56 |
| ayoung | and I, lazy slob that I am, get fired | 18:56 |
| kfox1111 | how do you restrict a subset of secrets to a specific vm with a trust? | 18:56 |
| ayoung | nova goes to get token using trust, buit it can't cuz I not longerh ave that power myself | 18:57 |
| ayoung | kfox1111, is thei Barbican secrets type thing? | 18:57 |
| kfox1111 | I'd expect the vm is owned by the project and if the project manager wants to keep the project alive, the vm's shouldn't break because one user left the project. | 18:57 |
| kfox1111 | yeah. so you may have 10 secrets associated with your project, and you, as a project member have access to them all. | 18:58 |
| kfox1111 | you may want to delegate access to a vm for just the 1 key it needs access to. | 18:58 |
| kfox1111 | with barbican acl's, you can say user foo can download just this one secret. | 18:58 |
| kfox1111 | so if each instance has its own user, you can setup the acls to allow it to access only the keys it needs access to, blocking all the rest, keeping the rest of the secrets in the same project safe. | 18:59 |
| ayoung | kfox1111, put them each in a separate project, then | 19:00 |
| ayoung | kfox1111, I have a meeting now...I will give you a fuller answer in a bit. If I miss you, I'll post to the mailing list | 19:00 |
| *** ayoung is now known as ayoung-mtg | 19:00 | |
| kfox1111 | ok. thanks. I think we're making it increadibly hard to manage secrets. :/ | 19:00 |
| kfox1111 | when you make secret management hard, everyone does it wrong. :/ | 19:01 |
| *** ankita_w_ has quit IRC | 19:02 | |
| *** wuhg has quit IRC | 19:04 | |
| *** csoukup has quit IRC | 19:05 | |
| *** dontalton has joined #openstack-keystone | 19:09 | |
| *** e0ne has joined #openstack-keystone | 19:09 | |
| *** tqtran has joined #openstack-keystone | 19:16 | |
| *** e0ne is now known as e0ne_ | 19:18 | |
| *** e0ne_ is now known as e0ne | 19:22 | |
| openstackgerrit | Deepti Ramakrishna proposed openstack/keystone: Reuse token_ref fetched in AuthContextMiddleware. https://review.openstack.org/190863 | 19:32 |
| *** lhcheng has quit IRC | 19:37 | |
| *** dontalton has quit IRC | 19:52 | |
| samueldmq | morganfainberg, ayoung-mtg https://wiki.openstack.org/wiki/DynamicPolicies#Evolution | 19:52 |
| samueldmq | morganfainberg, ayoung-mtg I will recheck it against the overview spec + add links to existing specs (linking them with the items in the roadmap) this weekend | 19:53 |
| samueldmq | oops, just https://wiki.openstack.org/wiki/DynamicPolicies .. #Evolution is a section in there :) | 19:53 |
| *** lhcheng has joined #openstack-keystone | 19:59 | |
| *** ChanServ sets mode: +v lhcheng | 19:59 | |
| *** chmouel has quit IRC | 20:07 | |
| *** csd has quit IRC | 20:07 | |
| *** redrobot has quit IRC | 20:07 | |
| *** Guest19563 is now known as dan | 20:07 | |
| *** redrobot has joined #openstack-keystone | 20:08 | |
| *** redrobot is now known as Guest67074 | 20:08 | |
| kfox1111 | morganfainberg: could you please have a look at https://review.openstack.org/#/c/186617/ and weigh in when you get a minute? I kind of feel like we keep going around and around without pinning anything down. :/ | 20:09 |
| openstackgerrit | Rodrigo Duarte proposed openstack/keystoneauth: Add Keystone2KeystoneAuthPlugin for K2K federation https://review.openstack.org/188581 | 20:09 |
| *** EmilienM is now known as EmilienM|afk | 20:10 | |
| *** csd has joined #openstack-keystone | 20:11 | |
| *** chmouel has joined #openstack-keystone | 20:12 | |
| *** e0ne has quit IRC | 20:19 | |
| *** greghaynes has quit IRC | 20:27 | |
| *** radez is now known as radez_g0n3 | 20:34 | |
| *** ayoung-mtg has quit IRC | 20:36 | |
| openstackgerrit | Kevin Fox proposed openstack/keystone-specs: Unscoped Service Catalog https://review.openstack.org/190732 | 20:39 |
| *** htruta has quit IRC | 20:41 | |
| *** ozialien has joined #openstack-keystone | 20:44 | |
| *** raildo has quit IRC | 20:46 | |
| *** ayoung-mtg has joined #openstack-keystone | 20:50 | |
| *** lhcheng has quit IRC | 20:54 | |
| openstackgerrit | Dolph Mathews proposed openstack/keystone-specs: User groups in token bodies https://review.openstack.org/188564 | 20:56 |
| *** pnavarro has joined #openstack-keystone | 21:13 | |
| *** edmondsw has joined #openstack-keystone | 21:14 | |
| *** dguerri` is now known as dguerri | 21:17 | |
| *** iurygregory has quit IRC | 21:17 | |
| openstackgerrit | Kevin Fox proposed openstack/keystone-specs: Unscoped Service Catalog https://review.openstack.org/190732 | 21:18 |
| *** ayoung-mtg has quit IRC | 21:20 | |
| *** ozialien has quit IRC | 21:26 | |
| *** edmondsw_ has joined #openstack-keystone | 21:27 | |
| *** ayoung-mtg has joined #openstack-keystone | 21:32 | |
| *** gyee_ has quit IRC | 21:33 | |
| *** edmondsw_ has quit IRC | 21:36 | |
| *** edmondsw has quit IRC | 21:40 | |
| *** nkinder__ has quit IRC | 21:42 | |
| -openstackstatus- NOTICE: Gerrit will be offline for project renames between 22:00 and 22:30 UTC | 21:43 | |
| *** ChanServ changes topic to "Gerrit will be offline for project renames between 22:00 and 22:30 UTC" | 21:43 | |
| *** pnavarro has quit IRC | 21:49 | |
| *** diazjf has left #openstack-keystone | 21:57 | |
| *** Raildo has joined #openstack-keystone | 21:59 | |
| -openstackstatus- NOTICE: Gerrit is offline for project renames. ETA 20:30 | 22:04 | |
| *** ChanServ changes topic to "Gerrit is offline for project renames. ETA 20:30" | 22:04 | |
| -openstackstatus- NOTICE: Gerrit is offline for project renames. ETA 22:40 | 22:08 | |
| *** ChanServ changes topic to "Gerrit is offline for project renames. ETA 22:40" | 22:08 | |
| ayoung-mtg | dolphm, just one group for scoped tokens, but all groups for unscoped. Make sense? | 22:09 |
| kfox1111 | depends on the resolution to the instance user thing too? | 22:13 |
| kfox1111 | I'm really nervious without some kind of filtering it will break on one of our clouds. | 22:14 |
| kfox1111 | wait... how do you pick a group when scoping? | 22:14 |
| kfox1111 | I didn't think that was a thing. | 22:15 |
| kfox1111 | We're using groups right now to allow users access to tenants, and it seems to work fine with the dashboard and launching vm's but no where does the user pick a group when logging in. | 22:16 |
| ayoung-mtg | kfox1111, so when a user authenticates, we look up the list of groups for that user. If they request a scoped token, we look for role assignement, first based on their userid, ehtn based on their group assingments | 22:16 |
| *** ayoung-mtg is now known as ayoung | 22:16 | |
| ayoung | kfox1111, for revocations, we only care about the group actually used to assign the user to the project. | 22:17 |
| kfox1111 | ah, so its filtered by role association. I see. | 22:17 |
| kfox1111 | So it still could be multiple groups, but probably just one. | 22:17 |
| ayoung | I guess in theory, the user could have multiple ways to be assigneed to the project, including multiple groups. | 22:17 |
| kfox1111 | that makes sense. | 22:17 |
| ayoung | in theory it could be direct assignment plus group | 22:17 |
| kfox1111 | I would assume I'm a normal user and an admin in some projects... | 22:18 |
| kfox1111 | probably through different groups. | 22:18 |
| ayoung | so, we could remove a direct assignment, but leave on that the user got due to being in a group | 22:18 |
| ayoung | so, their are edge conditions, but I think there are anyway | 22:18 |
| ayoung | so if we revoke by group, and the token has multiple groups in it.... | 22:19 |
| kfox1111 | yeah. | 22:19 |
| ayoung | actually, we have to limit the groups in the token relevant to the assignemnt, otherwise we can't revoke by group | 22:19 |
| ayoung | is that what he said and I misread it? | 22:19 |
| kfox1111 | It might be good to bring up filtering by role back to the barbican guys. I'm thinking that they would not expect that behavior. | 22:19 |
| ayoung | and....gherrit is down | 22:20 |
| kfox1111 | thought any more about the instance user use case? I was under the impression the barbican folks came up with the whole acl thing to avoid needing lots of projects. | 22:23 |
| kfox1111 | I also see a good use case where a vm may need to be given access to just one zaqar queue owned by a project. | 22:33 |
| *** ChanServ changes topic to "Gerrit is offline for project renames. ETA 20:30" | 22:42 | |
| -openstackstatus- NOTICE: Gerrit is back online. Zuul reconfiguration for renamed projects is still in progress, ETA 23:30. | 22:42 | |
| *** lhcheng has joined #openstack-keystone | 22:50 | |
| *** ChanServ sets mode: +v lhcheng | 22:50 | |
| *** ChanServ changes topic to "Liberty Development Open | Review Liberty Specs | See you at the summit!" | 22:50 | |
| *** zzzeek has quit IRC | 22:51 | |
| *** lhcheng_ has joined #openstack-keystone | 22:53 | |
| *** dguerri is now known as dguerri` | 22:54 | |
| *** sigmavirus24 is now known as sigmavirus24_awa | 22:54 | |
| *** obedmr has quit IRC | 22:55 | |
| *** lhcheng has quit IRC | 22:55 | |
| *** arunkant has quit IRC | 22:56 | |
| *** arunkant has joined #openstack-keystone | 22:56 | |
| *** Ephur has quit IRC | 22:59 | |
| *** Raildo has quit IRC | 23:02 | |
| ayoung | kfox1111, OK, so putting hte password in Nova is no more secure than just sticking the secret in nova | 23:13 |
| kfox1111 | Disagree. For the following reasons. | 23:14 |
| kfox1111 | the metadata for a vm outlasts its life span (soft deletes) | 23:14 |
| kfox1111 | a secret's lifespan/usefullness often outlives the vm's. | 23:15 |
| kfox1111 | orchistration is very important to the process, and you don't want secrets passing through both nova and heat and stored in both db's like it must be done today. | 23:16 |
| kfox1111 | associating a vm's instance to a container, allows you to update the secrets in the container without having to modify stuff in nova. | 23:16 |
| kfox1111 | there may be other reasons. those are just off the top of my head. | 23:17 |
| kfox1111 | the lifespan of the acl associating the vm's and the secrets can be less then the lifespan of the secret. | 23:18 |
| kfox1111 | it can be revoked after the vm is put in place and then the pw in the nova database no longer can be used to get the secret. | 23:18 |
| kfox1111 | if sticking the secret in the db was ok, barbican wouldn't buy you anything over just sticking it in swift as well. | 23:20 |
| kfox1111 | barbican buys you other things like hardware encryption devices. | 23:20 |
| *** openstackgerrit has quit IRC | 23:22 | |
| *** openstackgerrit has joined #openstack-keystone | 23:22 | |
| kfox1111 | oh. and barbican lets you provision secrets. so generating a ssl certificate on the fly, and keeping it up to date when it expires. | 23:24 |
| ayoung | kfox1111, all you said is true, and yet what I just said is still true | 23:36 |
| kfox1111 | I'm not sure I follow. | 23:37 |
| kfox1111 | If a keystone user is associated with the vm, but on vm delete the instance user is thrown away, the secret is no longer accessable via anything stored in nova's database. therefore, its more secure then simply storing the secret in nova since soft deletes ensure a secret stored in the nova database outlasts the vm's deletion. | 23:38 |
| kfox1111 | someone breaking into the nova database won't find anything useful in the password case, only the stored secret case. | 23:40 |
| lhcheng_ | question, we only set the 'is_admin' in the policy check context for authentication using admin_token right? | 23:41 |
| *** dan is now known as Guest74409 | 23:49 | |
| *** dan_ has joined #openstack-keystone | 23:50 | |
| *** dan_ is now known as Guest68549 | 23:50 | |
| kfox1111 | well, I gota head out. have a great weekend. | 23:58 |
Generated by irclog2html.py 2.14.0 by Marius Gedminas - find it at mg.pov.lt!