| *** henrynash has quit IRC | 00:03 | |
| *** chrisshattuck has quit IRC | 00:06 | |
| *** _cjones_ has joined #openstack-keystone | 00:06 | |
| *** oomichi_ has joined #openstack-keystone | 00:09 | |
| *** marcoemorais has quit IRC | 00:14 | |
| *** dims has quit IRC | 00:15 | |
| *** htruta_ has joined #openstack-keystone | 00:15 | |
| *** dims has joined #openstack-keystone | 00:15 | |
| *** jimhoagland has quit IRC | 00:25 | |
| *** agireud has quit IRC | 00:37 | |
| *** jasondotstar has quit IRC | 00:48 | |
| ayoung | jamielennox, I don't think we are going to have that luxury. Bascially, the format we publish is going to be responsible for revocation events and for policy regardless. We can punt on it for the Token provider if he really wants to, but I don't think that will buy us much; the server will still depend on the client code for the AccessInfo | 00:49 |
|---|---|---|
| jamielennox | ayoung: i'm happy for server to use AccessInfo | 00:49 |
| jamielennox | jsut saying | 00:49 |
| ayoung | jamielennox, really, those are the two use cases I care about anyway. The third will be from unpacking a token and using that data to create another token...but policy will need it in the AccessInfo format | 00:50 |
| ayoung | jamielennox, I'm more concerned that you want to change AccessInfo than anything else | 00:50 |
| jamielennox | yea, i think using accessinfo there is a good thing | 00:51 |
| ayoung | do you have a sense of what it should look like? | 00:51 |
| jamielennox | there are some flaws - but i'm not going to break it | 00:51 |
| jamielennox | so primarily i don't think AccessInfo should inherit dict, keep the internal representation abstract | 00:51 |
| *** jimhoagland has joined #openstack-keystone | 00:51 | |
| jamielennox | I'm not sure if from the server side you need to know what is a v2 or v3 format to handle changing between them | 00:52 |
| ayoung | for policy I think we should coerce V2 into V3 form | 00:53 |
| *** zzzeek has quit IRC | 00:53 | |
| ayoung | and revocation evetns | 00:53 |
| ayoung | events | 00:53 |
| ayoung | Why not inherit dict? Most things need AccessInfo in dict format | 00:54 |
| *** jorge_munoz has quit IRC | 00:55 | |
| jamielennox | The dict format is different between v2 and v3 and it's not 'correct' either | 01:06 |
| jamielennox | it does weird additions | 01:06 |
| *** jimhoagland has quit IRC | 01:09 | |
| *** gyee has quit IRC | 01:18 | |
| morganfainberg | ayoung, i really *dont* want to rely on accessinfo or a similar "hack" | 01:19 |
| morganfainberg | ayoung, my big concern is i don't want an object that needs to be aware of the underlying token formats - that is the wrong direction | 01:19 |
| ayoung | morganfainberg, you have to give me something concrete to work with | 01:19 |
| ayoung | So a builder pattern? | 01:20 |
| morganfainberg | if we're changing how accessinfo works - sure | 01:20 |
| morganfainberg | ayoung, much closer to builder pattern | 01:20 |
| openstackgerrit | Jamie Lennox proposed openstack/keystonemiddleware: Split identity server into v2 and v3 https://review.openstack.org/130534 | 01:20 |
| openstackgerrit | Jamie Lennox proposed openstack/keystonemiddleware: Use real discovery object in auth_token middleware. https://review.openstack.org/130532 | 01:20 |
| morganfainberg | the short is - lets not make the "format" dictate the object. the obejct should be able to get to the format. | 01:21 |
| morganfainberg | the v3 dict is already wrong out the gate for this, - even if we maintain it as a dict, or dict-like-access | 01:21 |
| morganfainberg | but the way accessinfo works *now* is the inverse of how it should be, if that makes sense. | 01:22 |
| morganfainberg | beyond that thinking, i'm not going to really get in the way of implementation | 01:22 |
| *** dims has quit IRC | 01:24 | |
| jamielennox | morganfainberg: i don't think AccessInfo is a problem in that way, yes the dict format is weird but it has a factory builder and the properties are correctly abstracted | 01:24 |
| *** dims has joined #openstack-keystone | 01:24 | |
| ayoung | morganfainberg, ok, so the disconnect as I see it is that the JSON format, which should be usable for all of the things like policy,is normalized. Policy and the like don;t do domain { id} they do domain_id | 01:24 |
| morganfainberg | jamielennox, i think accessinfo is trying to be too smart | 01:24 |
| morganfainberg | jamielennox, it shouldn't care - it should be the end result vs needing to know how to dig the data out | 01:24 |
| ayoung | the JSON format is what, I think the policy etc should be consuming | 01:25 |
| morganfainberg | ayoung, JSON -> Py? | 01:25 |
| ayoung | or rather, what you would get if you parsed the JSON into puthon | 01:25 |
| morganfainberg | ayoung, except we already know that is not the case. | 01:25 |
| ayoung | morganfainberg, yes | 01:25 |
| jamielennox | morganfainberg: not necessarily, depends what you are looking to use it for | 01:25 |
| ayoung | morganfainberg, so...in the policy prep code we had the "flatten" call | 01:25 |
| jamielennox | morganfainberg: you're right it won't work as a context, it works just fine as an abstraction | 01:25 |
| ayoung | which converts the objects into a dotted notation | 01:26 |
| ayoung | due to policy needing everything in key-value-pairs | 01:26 |
| morganfainberg | jamielennox, ok so let me rephrase, i want to prevent people from utilizing the accessinfo as a dict so we can tightly control the data added to it - accidental data inclusion doesn't become a contract or "usable" | 01:26 |
| ayoung | can't you do a read only dics somehow in python? | 01:27 |
| morganfainberg | ayoung, overload __setitem__ | 01:27 |
| morganfainberg | ayoung, but that doesn't solve a "keystone wedged data <X> in unintentionally - or we accidently carried it over" | 01:28 |
| morganfainberg | we can be explicit about the serialized format and work to correct those issues, but if the servers are trying to use things that are there unintentionally - it becomes really really unhappy to fix | 01:29 |
| morganfainberg | i don't expect we should ever break that data in the serialized form, but what if we accidently included something a server wants to use. i'd rether have a bug saying "hey why is this data here and i can't use it" than "oops we used it and it shouldn't have been there" | 01:29 |
| morganfainberg | and if the data is available...someone will start using it (in a project we don't run) | 01:30 |
| * morganfainberg is pessimistic about that fact. | 01:30 | |
| ayoung | morganfainberg, do you have an idea of how to do this? | 01:30 |
| morganfainberg | ayoung, so my thought was AccessInfo instead of being a bunch of @properties that know how to dig into the dict form json becomes a built object | 01:31 |
| jamielennox | morganfainberg: so let me rephrase - i don't mind that AccessInfo is a dict - i mind that it's not a standard token dict | 01:31 |
| morganfainberg | and context can be pulled from that (flattend) even if it's magic like __getitem__ | 01:31 |
| morganfainberg | though i would rather not make "accessinfo" the context objectblobthing | 01:32 |
| jamielennox | and i think that context should be generated seperately from AccessInfo | 01:32 |
| ayoung | so AccessInfoBuilder.add_user.... and when we are done .build() returns a frozen Python object | 01:32 |
| morganfainberg | ayoung, that is my general thought on what any model should be. | 01:32 |
| morganfainberg | token, user, etc | 01:32 |
| ayoung | Favor Immutable Objects | 01:32 |
| jamielennox | ayoung: just AccessInfo.user_id = ... then auth_ref.get_context() or Context.build(auth_ref) | 01:32 |
| jamielennox | we don't need a new builder | 01:33 |
| jamielennox | i just wish that AccessInfo was done right | 01:33 |
| openstackgerrit | Lin Hua Cheng proposed openstack/keystone: Always return the service name in the catalog https://review.openstack.org/135808 | 01:33 |
| ayoung | I don't think it is possible to do right. We are working in Python | 01:33 |
| morganfainberg | ayoung, alternatively - we *could* use something like protobuf. | 01:33 |
| ayoung | We could use a real language. Since we are dreaming, I could use a new house | 01:34 |
| morganfainberg | [there was some chatter on the ML about using that to objectify things away from the db schema] | 01:34 |
| morganfainberg | protobuf has hard-type enforcement etc and is versioned. i don't know if it's worth even considering | 01:34 |
| jamielennox | i don't think that helps here | 01:34 |
| ayoung | jamielennox, the token provider already acts like a Builder...we need something that will let us do the same thing even when we are not producing an official token | 01:35 |
| morganfainberg | jamielennox, it does sortof, because there is a JSON-> protobuf formatter already | 01:35 |
| jamielennox | the problem isn't python, the problem was how it was done | 01:35 |
| *** NM has joined #openstack-keystone | 01:35 | |
| ayoung | Immutable objects don't seem to be considered Pythonic | 01:35 |
| morganfainberg | jamielennox, and you get a full object out of it. not immutable (that is something else we coudl easily layer on top) | 01:35 |
| morganfainberg | anyway | 01:36 |
| ayoung | can you do sometihng that leaves _setattr__ functional until you flip a switch and then it doesn't allow changes? | 01:36 |
| morganfainberg | ayoung, sure | 01:36 |
| jamielennox | i don't see how these help ys | 01:36 |
| morganfainberg | ayoung, http://paste.openstack.org/show/135004/ | 01:37 |
| morganfainberg | jamielennox, my big concern and i don't care if it's accessinfo or something else, is we carefully control the data in the token. | 01:38 |
| morganfainberg | and what can get at that data | 01:38 |
| morganfainberg | i want to make sure we don't have extra cruft landing in the token because it was "conviennt" to put it there (we have had this happen before) | 01:38 |
| jamielennox | morganfainberg: i actually really like extending dict with properties | 01:38 |
| jamielennox | it means people can add whatever you like to the dict - we don't care we only use the properties | 01:39 |
| jamielennox | i know we don't want them to | 01:39 |
| morganfainberg | jamielennox, i prefer real objects that have __iter__ or __getitem__ but that me | 01:39 |
| jamielennox | it just that we don't care | 01:39 |
| morganfainberg | well the point is i don't want them going around our interface to get to those items | 01:39 |
| morganfainberg | if it's a dict, people will *tend* to use the dict[<key>] interface | 01:40 |
| morganfainberg | i would rather force use of the properties. | 01:40 |
| jamielennox | morganfainberg: python won't help you there | 01:40 |
| morganfainberg | jamielennox, X.<thing> = blah | 01:40 |
| jamielennox | just let them use it as much as possible | 01:40 |
| jamielennox | we give them that | 01:41 |
| jamielennox | if they go around it it's not our problem | 01:41 |
| morganfainberg | jamielennox, i disagree whole-heartedly with that | 01:41 |
| morganfainberg | because when we break it, they're going to complain a lot | 01:41 |
| morganfainberg | and we're going to have to unbreak it | 01:41 |
| morganfainberg | even if it means carrying awful things forward and tech debt | 01:41 |
| jamielennox | depends on what you set as the base | 01:42 |
| jamielennox | this is what i meant earlier - i actually like that AccessInfo is a dict | 01:42 |
| morganfainberg | jamielennox, my expectation is "if this is a dict people will use it like a dict" | 01:42 |
| jamielennox | i just hate that somewhere along the line we made it not a standard token dict | 01:42 |
| morganfainberg | and that is the interface we're supporting so why bother. | 01:42 |
| morganfainberg | i think passing things around as plain dicts within code, (even if they have @props for convenience) is really poor design. same feeling about **kwargs | 01:43 |
| morganfainberg | or even *args | 01:43 |
| jamielennox | i think people use them poorly | 01:44 |
| morganfainberg | and yes this is a personal view - i wont hold up everything if everyone else disagrees with me. | 01:44 |
| *** jasondotstar has joined #openstack-keystone | 01:44 | |
| *** jasondotstar has quit IRC | 01:44 | |
| morganfainberg | jamielennox, the problem is they lend themselves to being used poorly | 01:44 |
| jamielennox | python is weird, you have to be really careful not to do the wrong thing | 01:44 |
| morganfainberg | i'd rather encourage "not the wrong thing" rather than "oh don't do that but we don't care cause we use X instead" | 01:45 |
| jamielennox | it's an interesting curve - really easy to get into, the middle bit is much the same as any language, but doing things properly is not helped by the language | 01:45 |
| jamielennox | i think as you get more experienced in python you realize all the things that helped you at the beginning are bad design | 01:45 |
| dstanek | jamielennox: very true | 01:46 |
| morganfainberg | so let me put away my soapbox | 01:46 |
| morganfainberg | if we're going to extend dict, note my dislike of it, and lets move on | 01:46 |
| morganfainberg | and i wont stand in the way of that design if it's really the way to go | 01:47 |
| jamielennox | morganfainberg: AccessInfo is already a standard - we can't do anything | 01:48 |
| jamielennox | the factory method sucks - REALLY BADLY | 01:49 |
| morganfainberg | jamielennox, we could stop using it mark it deprecated let it not get new features | 01:49 |
| jamielennox | however as an abstraction it does an OK job and i'd prefer to have just one place to do things | 01:49 |
| morganfainberg | if we are changing things. | 01:49 |
| jamielennox | keystoneclient v2 | 01:49 |
| *** NM has quit IRC | 01:50 | |
| *** packet has joined #openstack-keystone | 01:51 | |
| morganfainberg | jamielennox, anyway. enough on this. | 01:51 |
| morganfainberg | jamielennox, my vote is we fix whatever it is we're going to use and make it not suck. | 01:51 |
| morganfainberg | more than anything else | 01:51 |
| jamielennox | for a v2 my idea was that i could just fix little things like that, keep the major interfaces the same, fix stupid mistakes - then i remember that was the mantra of python 3 and i just loose all interest | 01:51 |
| morganfainberg | and if it means re-doing accessinfo to not suck as something else... lets do it. | 01:51 |
| *** alex_xu has joined #openstack-keystone | 01:51 | |
| morganfainberg | mark it deprecated and stop using it - no new features and in... uh... $SOMETIME$ it can go away | 01:52 |
| morganfainberg | or provide a better factory for it | 01:52 |
| jamielennox | ok, replace it with what? | 01:53 |
| jamielennox | factory is easy | 01:53 |
| *** _cjones_ has quit IRC | 01:53 | |
| morganfainberg | or whatever. you know, make it better in a non-break-everything way. even if the not-break things is a shim for the old deployments that still use it + new ksc | 01:53 |
| morganfainberg | if we unify things on accessinfo, lets make it not suck - whatever that means | 01:54 |
| jamielennox | ok, let me think about what that means | 01:55 |
| morganfainberg | i'd like to see tech debt and carrying sucky things forward transition away, even if it's a long ways out :) | 01:55 |
| jamielennox | in the mean time i'd say just use it, because the property names won't change | 01:56 |
| morganfainberg | but unifying code on an impl that has real issues, seems like a worse idea. | 01:56 |
| morganfainberg | and all my conversations about accessinfo seemed to revolve around "it sucks but we can't change it" | 01:56 |
| *** radez_g0n3 is now known as radez | 01:56 | |
| morganfainberg | jamielennox, and to be clear i'd support a "fix all the things in keystoneclient-2 or 1.0.0 or...whatever" release and we pivot to it, especially if "session" and the things other clients care about are compatible. | 01:58 |
| morganfainberg | if that is what it takes. | 01:58 |
| *** lhcheng_ has quit IRC | 01:59 | |
| jamielennox | morganfainberg: i'd be fine with that - however nobody has successfuly managed to transition to a new library version - i'd almost say some TC advice on how this should work would be useful | 02:01 |
| morganfainberg | jamielennox, ++ | 02:01 |
| morganfainberg | jamielennox, *mostly* the big peices would need to be compatible (e.g. session) | 02:01 |
| morganfainberg | i think | 02:01 |
| morganfainberg | but other than that, i *think* we could get away with it fairly easily. | 02:02 |
| morganfainberg | OSC and middleware being the big changes, and since OSC does CLI going forward new ksc needs no CLI code | 02:02 |
| morganfainberg | and we could drop middleware from it. | 02:02 |
| jamielennox | morganfainberg: to have any chance at a transition the old and new would need to be parallel installable | 02:03 |
| morganfainberg | jamielennox, totally doable. | 02:03 |
| jamielennox | either we need to create a new pip package | 02:03 |
| ayoung | morganfainberg, OK, so I started with that approach on Revocation events...and also tried to do Don't Repeat Yourself. And...ended up with a bunch of sets of Keys for dictionaries in sets | 02:03 |
| jamielennox | or create a new top level folder in keystoneclient | 02:04 |
| jamielennox | so keystoneclient2 got installed when you installed python-keystoneclient | 02:04 |
| jamielennox | just import keystoneclient2 instead of keystoneclient | 02:04 |
| jamielennox | so we kind of need a better name | 02:04 |
| ayoung | http://git.openstack.org/cgit/openstack/keystone/tree/keystone/contrib/revoke/model.py#n63 | 02:04 |
| morganfainberg | jamielennox, that is a bad approach (trying to do 2 packages from 1 repo) pip, pbr, etc all don't play nice with it | 02:04 |
| morganfainberg | so new repo would be the target | 02:05 |
| ayoung | http://git.openstack.org/cgit/openstack/keystone/tree/keystone/contrib/revoke/model.py#n16 started off with the common attributes, and then each extended their own way | 02:05 |
| jamielennox | morganfainberg: i didn't say 2 packages, i said two top level modules | 02:05 |
| morganfainberg | jamielennox, same thing iirc. | 02:05 |
| morganfainberg | jamielennox, it's a namespace issue then. | 02:06 |
| jamielennox | pip install python-keystoneclient would install keystoneclient and keystoneclient2 | 02:06 |
| *** NM has joined #openstack-keystone | 02:06 | |
| morganfainberg | oh. eh... | 02:06 |
| jamielennox | just there's only 1 version | 02:06 |
| morganfainberg | i *think* that would break some things still | 02:06 |
| jamielennox | i don't see it's an advantage to do it that way | 02:06 |
| morganfainberg | i'd be inclined to make it explicitly different install | 02:07 |
| morganfainberg | that way we can really keep it nice and namespaced. | 02:07 |
| morganfainberg | but i agree keystoneclient2 sounds ... bad? | 02:07 |
| jamielennox | ++ | 02:07 |
| morganfainberg | and new ksc can still use python-keystoneclient-* auth plugins if we want. | 02:08 |
| morganfainberg | hm. | 02:08 |
| jamielennox | yea, i don't know how we do that bit | 02:08 |
| morganfainberg | ayoung, like i said a bit earlier, i've put away my soapbox, if it's the right course its the right course. | 02:09 |
| morganfainberg | ayoung, and i wont stand in the way of it. - even though i may not like it. | 02:09 |
| ayoung | morganfainberg, let me code up what I think you are talking about | 02:10 |
| *** jorge_munoz has joined #openstack-keystone | 02:10 | |
| *** richm has joined #openstack-keystone | 02:12 | |
| morganfainberg | ayoung, sounds good. i'm reviewing henrynashes' split review before i start in on other stuff i need to get done, like code ;) | 02:15 |
| morganfainberg | ayoung, hmm. | 02:19 |
| morganfainberg | ayoung, i think i see a logic issue w/ henry's split review | 02:20 |
| ayoung | ? | 02:20 |
| morganfainberg | i *think* role should be part of assignment | 02:20 |
| morganfainberg | not part of resource | 02:20 |
| morganfainberg | tell me i'm wrong? | 02:20 |
| ayoung | the role definition should be in resource according to how he split it up. I'm not so sure myself. | 02:20 |
| morganfainberg | right it looks to me that role and role assignment should be "assignment" | 02:21 |
| morganfainberg | otherwise the pluggable "assignment" backend may not make sense? i have these role things over -----> here | 02:21 |
| *** NM has quit IRC | 02:21 | |
| morganfainberg | but they don't have bearing in how i do assignment logic? | 02:21 |
| morganfainberg | or is assingment really just the assignment/actor-to-resource-via-role mapping? | 02:22 |
| ayoung | I'm not even certain that splitting this is a good idea at all | 02:22 |
| ayoung | I'm not 100% certain that projects and assignemtns don;t belond together | 02:22 |
| ayoung | but... | 02:22 |
| ayoung | I could see the argument that if domains and projects are in one backend and were read out of, say, ldap | 02:23 |
| ayoung | then assigning users to roles in those projects would be something done by Keystone | 02:23 |
| morganfainberg | thats the general view i saw in this. | 02:23 |
| ayoung | in which case, having roles in the resource backend would be broken | 02:23 |
| ayoung | so, yeah, I think I am leaning your way on this | 02:24 |
| morganfainberg | it also allowed things like a graph-db for assignment (interesting, but not relevant for project/domain storage) | 02:24 |
| morganfainberg | but def. interesting from the RBAC and assignment of role-to-actor-on-resource construct | 02:24 |
| ayoung | I think I am with you on this one | 02:24 |
| ayoung | need to mull it over. | 02:25 |
| ayoung | from a keystone perspective, both users and roles are external to projects | 02:25 |
| morganfainberg | yeah not willing to -1 this *yet* on that front, i think i'll just ask the question. | 02:25 |
| ayoung | they are things you put in the buckets | 02:25 |
| morganfainberg | because other than that, this split looks quite reasonable to me | 02:26 |
| ayoung | I kindof want domains in their own backend | 02:26 |
| morganfainberg | ayoung, domains == projects! | 02:26 |
| ayoung | and then a domain could potentially get populated from LDAP | 02:26 |
| morganfainberg | ;) | 02:26 |
| *** jacorob has quit IRC | 02:26 | |
| morganfainberg | >.> | 02:26 |
| morganfainberg | <.< | 02:26 |
| ayoung | domains are top level projects too | 02:26 |
| ayoung | *too* | 02:26 |
| morganfainberg | right. | 02:26 |
| ayoung | but domains are organizational boundaries | 02:26 |
| morganfainberg | anyway - i'm going to ask the question i think role needs to go with role-assignment | 02:27 |
| ayoung | and being able to pull the project listing for a specific domain from an external source is comparable to doing it for users | 02:27 |
| ayoung | I think it goes it its own backend | 02:27 |
| ayoung | roles are a keystone managed resource that span domains | 02:27 |
| ayoung | even assignments you could see coming from an external source if you squint hard enough | 02:28 |
| morganfainberg | ayoung, not convinced that without roles/assignment doesn't mean "resource" [being largely *just* projects going forward] isn't already there | 02:28 |
| *** richm has left #openstack-keystone | 02:28 | |
| ayoung | richm working the late night in Westford... | 02:28 |
| morganfainberg | we aren't storing extra stuff *in* the project backend that way, we're just looking at the listing of projects - a very different beast than "assignment" being everything-but-users-and-groups | 02:29 |
| ayoung | all our puppet people are working to untangle that mess....decided to work from home for safety and sanity reasons | 02:29 |
| morganfainberg | haha | 02:29 |
| morganfainberg | anyway thanks, wanted the reality check on "am i crazy for asking this" before asking that question | 02:29 |
| ayoung | Yeah. You are still crazy, but not for asking *that* | 02:30 |
| morganfainberg | i resemble that remark | 02:30 |
| *** jorge_munoz has quit IRC | 02:30 | |
| *** packet has quit IRC | 02:30 | |
| ayoung | morganfainberg, we should have nested the roles under the scope for which the roles are assigned | 02:35 |
| *** erkules_ has joined #openstack-keystone | 02:36 | |
| ayoung | instead we pull them out to their own level of the token, and we lose the ability to have one document that specifies roles for multiple scopes | 02:36 |
| morganfainberg | not sure that actually makes anything better | 02:36 |
| morganfainberg | oh in the token? | 02:36 |
| * morganfainberg was still thinking in the backends. | 02:36 | |
| ayoung | https://github.com/openstack/identity-api/blob/master/v3/src/markdown/identity-api-v3.md#authentication-responses | 02:36 |
| ayoung | scroll down a screen or two | 02:37 |
| morganfainberg | sure. we could tightly couple those thigns but i *thought* we made that an explicit design choice. | 02:37 |
| morganfainberg | back in the day | 02:37 |
| morganfainberg | 1 scope per token | 02:37 |
| ayoung | "domain": { | 02:37 |
| ayoung | "id": "1789d1", | 02:37 |
| ayoung | "name": "example.com" | 02:37 |
| ayoung | }, | 02:37 |
| ayoung | "roles": [ | 02:37 |
| morganfainberg | *forsomereasonineverwassureabout* | 02:37 |
| *** jorge_munoz has joined #openstack-keystone | 02:37 | |
| *** erkules has quit IRC | 02:38 | |
| ayoung | it makes it easier to find the role | 02:38 |
| ayoung | but it means that we would not be able to do multi-scope tokens | 02:38 |
| *** jorge_munoz has quit IRC | 02:38 | |
| ayoung | and for nesting it means we don't have a way to represent | 02:38 |
| ayoung | it would be nice if we could do | 02:38 |
| ayoung | domain {project {project {project } } } } | 02:39 |
| ayoung | then inherited roles would be | 02:39 |
| ayoung | domain { roles[], project { roles[] project { roles [] project{roles[] } } } } } | 02:39 |
| morganfainberg | yeah, but that's not what we have today | 02:40 |
| ayoung | I know | 02:40 |
| ayoung | that is what I just said | 02:40 |
| morganfainberg | =/ | 02:40 |
| morganfainberg | i'm agreeing | 02:40 |
| ayoung | would give us a way to do domain roles on a project scoped token for Horizon, too | 02:40 |
| *** oomichi_ has quit IRC | 02:41 | |
| morganfainberg | it also would have been nice if we had done { 'scope': [ {...}, {...}] } instead of "{project:} or {"domain":} | 02:41 |
| ayoung | well...maybe not | 02:41 |
| ayoung | yeah | 02:41 |
| ayoung | I still need to figure out how to request an unscoped token | 02:41 |
| morganfainberg | heh | 02:41 |
| ayoung | "scope": { "none" :"True" }} | 02:41 |
| ayoung | to make sure that if someone requested it of a Keystone server that doesn't support it, it will break | 02:42 |
| morganfainberg | nah, "scope": [] | 02:42 |
| morganfainberg | that is implicitly unscoped | 02:42 |
| morganfainberg | no scope | 02:42 |
| ayoung | lets see what happens when I pass that to an existing keystone server... | 02:42 |
| morganfainberg | you'd get default project back if it exists iirc. | 02:43 |
| morganfainberg | as your scope | 02:43 |
| morganfainberg | otherwise you get a token w/o "domain" or "project" | 02:43 |
| morganfainberg | *i think* | 02:43 |
| morganfainberg | which is unscoped. but it's not clear that it's the case because scope is a top-level that could be in one of two places in the token | 02:43 |
| * morganfainberg takes a break. so i don't go back to dislike token format convo | 02:44 | |
| ayoung | {"error": {"message": "Expecting to find project, domain, or OS-TRUST:trust in scope - the server could not comply with the request since it is either malformed or otherwise incorrect. The client is assumed to be in error.", "code": 400, "title": "Bad Request"}}[ayoung@f20 ~]$ | 02:44 |
| ayoung | I think you have nailed it | 02:44 |
| ayoung | lets see what happens with scope : {} | 02:45 |
| ayoung | same thing | 02:45 |
| ayoung | so either is acceptable to me | 02:46 |
| *** yasu_ has joined #openstack-keystone | 02:47 | |
| *** htruta_ has quit IRC | 02:50 | |
| *** KanagarajM has joined #openstack-keystone | 02:56 | |
| *** tellesnobrega has joined #openstack-keystone | 03:05 | |
| *** dims has quit IRC | 03:08 | |
| *** dims has joined #openstack-keystone | 03:08 | |
| openstackgerrit | Merged openstack/keystone: Move base64 unit tests to keystone/tests/unit dir https://review.openstack.org/134043 | 03:09 |
| *** yasu_ has quit IRC | 03:10 | |
| openstackgerrit | Merged openstack/keystone: Increase test coverage of test_base64utils.py https://review.openstack.org/134044 | 03:10 |
| ayoung | morganfainberg, jamielennox http://paste.openstack.org/show/135032/ | 03:12 |
| openstackgerrit | Merged openstack/keystone: Doc about specifying domains in domains specific backends https://review.openstack.org/132143 | 03:12 |
| openstackgerrit | Merged openstack/keystone: Increase test coverage of test_versions.py https://review.openstack.org/134365 | 03:12 |
| openstackgerrit | Merged openstack/keystone: Move injection unit tests to keystone/tests/unit https://review.openstack.org/134010 | 03:13 |
| jamielennox | ayoung: i think its unecssary, we dont need to stop people shooting themselves in the fooyt | 03:13 |
| *** yasu_ has joined #openstack-keystone | 03:14 | |
| *** HenryG has quit IRC | 03:15 | |
| ayoung | jamielennox, that expression has two meanings. One is someone is trying to do a quick draw, and pulls the trigger while the pistol is still in the holster. The second is someone trying to get out of combat and puts a bullet through their own foot intentionally. | 03:16 |
| jamielennox | new a guy in primary school that actually managed to shoot himself in the foot | 03:16 |
| ayoung | I would argue both are due to people being in situations which are over their head | 03:16 |
| jamielennox | went on to play football professionally, so no lasting effects | 03:16 |
| jamielennox | knew | 03:17 |
| ayoung | Nu? | 03:17 |
| ayoung | jamielennox, anyway, I tend to code defensively, which is what I think morganfainberg is aiming for here. If it makes it easier to document, so much the better. I think it would be easy to make a builder using that pattern, and a single call to set immutable on all contained objects would ensure correct usage for the most part | 03:18 |
| *** HenryG has joined #openstack-keystone | 03:18 | |
| ayoung | we'd probably have to grandfather in a few of the flattened attributes like user_id | 03:19 |
| ayoung | to keep policy working | 03:19 |
| *** tellesnobrega has quit IRC | 03:45 | |
| *** yasu_ has quit IRC | 03:59 | |
| *** chrisshattuck has joined #openstack-keystone | 04:04 | |
| *** radez is now known as radez_g0n3 | 04:12 | |
| *** jdennis has quit IRC | 04:17 | |
| *** tellesnobrega has joined #openstack-keystone | 04:20 | |
| *** stevemar has joined #openstack-keystone | 04:29 | |
| *** ChanServ sets mode: +v stevemar | 04:29 | |
| *** erkules_ is now known as erkules | 04:35 | |
| *** jdennis has joined #openstack-keystone | 04:35 | |
| *** Nakato_ is now known as Nakato | 04:58 | |
| *** henrynash has joined #openstack-keystone | 05:05 | |
| *** ChanServ sets mode: +v henrynash | 05:05 | |
| *** tellesnobrega has quit IRC | 05:12 | |
| *** chrisshattuck has quit IRC | 05:17 | |
| *** alex_xu has quit IRC | 05:19 | |
| *** alex_xu has joined #openstack-keystone | 05:29 | |
| *** jdennis has quit IRC | 05:30 | |
| *** chrisshattuck has joined #openstack-keystone | 05:32 | |
| *** henrynash has quit IRC | 05:54 | |
| *** ajayaa has joined #openstack-keystone | 05:57 | |
| *** chrisshattuck has quit IRC | 06:02 | |
| *** chrisshattuck has joined #openstack-keystone | 06:05 | |
| *** chrisshattuck has quit IRC | 06:07 | |
| *** alex_xu has quit IRC | 06:12 | |
| *** alex_xu has joined #openstack-keystone | 06:19 | |
| *** oomichi has joined #openstack-keystone | 06:22 | |
| *** amcrn has quit IRC | 06:24 | |
| *** harlowja is now known as harlowja_away | 06:31 | |
| *** k4n0 has joined #openstack-keystone | 06:33 | |
| *** jimhoagland has joined #openstack-keystone | 06:42 | |
| *** afazekas has quit IRC | 06:55 | |
| marekd | morning | 06:56 |
| *** oomichi__ has joined #openstack-keystone | 07:01 | |
| *** oomichi has quit IRC | 07:02 | |
| *** pc-m has quit IRC | 07:08 | |
| *** pc-m has joined #openstack-keystone | 07:08 | |
| *** ukalifon1 has joined #openstack-keystone | 07:19 | |
| *** afazekas has joined #openstack-keystone | 07:45 | |
| *** ukalifon1 has quit IRC | 07:47 | |
| *** stevemar has quit IRC | 07:47 | |
| *** redrobot has quit IRC | 07:52 | |
| *** abelity has joined #openstack-keystone | 07:52 | |
| abelity | hi | 07:53 |
| abelity | just wanted to check if anyone has implemented keystone CAS as the identity provider | 07:53 |
| abelity | w/ CAS as the identity provider | 07:54 |
| abelity | should i us shibboleth or just plain mod_auth_cas?? | 07:55 |
| *** redrobot has joined #openstack-keystone | 07:55 | |
| *** redrobot is now known as Guest27879 | 07:55 | |
| openstackgerrit | Marek Denis proposed openstack/keystone-specs: Service Provider for K2K https://review.openstack.org/135604 | 08:01 |
| marekd | abelity: what is CAS? | 08:02 |
| *** links has joined #openstack-keystone | 08:11 | |
| *** oomichi_ has joined #openstack-keystone | 08:12 | |
| *** oomichi__ has quit IRC | 08:12 | |
| *** oomichi_ has quit IRC | 08:14 | |
| openstackgerrit | Marek Denis proposed openstack/keystone-specs: Service Provider for K2K https://review.openstack.org/135604 | 08:18 |
| *** ukalifon1 has joined #openstack-keystone | 08:20 | |
| abelity | @marekd CAS = Central Authentication Server | 08:22 |
| marekd | abelity: so CAS is also a protocol, right? | 08:25 |
| marekd | abelity: or it uses SAML as a transport layer? | 08:25 |
| *** circ-user-vj7sB has joined #openstack-keystone | 08:28 | |
| circ-user-vj7sB | what happen "WARNING:keystoneclient.httpclient:Failed to retrieve management_url from token" | 08:28 |
| marekd | bdossant: welcome! | 08:28 |
| bdossant | marekd: yello | 08:29 |
| circ-user-vj7sB | i run keystone but WARNING:keystoneclient.httpclient:Failed to retrieve management_url from token | 08:30 |
| *** circ-user-vj7sB is now known as xiaozhi | 08:37 | |
| xiaozhi | How to solve "WARNING:keystoneclient.httpclient:Failed to retrieve management_url from token" | 08:38 |
| *** xiaozhi_ has joined #openstack-keystone | 08:44 | |
| *** xiaozhi has quit IRC | 08:46 | |
| *** uvirtbot has quit IRC | 09:00 | |
| ajayaa | xiaozhi, Check if you have setup proper endpoints in keystone. | 09:07 |
| ajayaa | circ-user-vj7sB ^^ | 09:07 |
| xiaozhi_ | thanks I found a mistake | 09:08 |
| *** NM has joined #openstack-keystone | 09:10 | |
| *** alex_xu has quit IRC | 09:14 | |
| *** uvirtbot has joined #openstack-keystone | 09:17 | |
| abelity | @marekd yes CAS uses SAML as the transport layer | 09:20 |
| openstackgerrit | Andrey Pavlov proposed openstack/keystone: Handle SSL termination proxies for version list https://review.openstack.org/132235 | 09:22 |
| marekd | abelity: so if shibboleth works well you can try it out :-) | 09:27 |
| marekd | abelity: but currently it needs to handle ECP (Enhanced client or proxy) extension | 09:27 |
| *** oomichi has joined #openstack-keystone | 09:27 | |
| abelity | but was just checking is there is reference implementation you know of CAS backends | 09:31 |
| samuelms | morning | 09:35 |
| *** lhcheng has joined #openstack-keystone | 09:38 | |
| *** uvirtbot has quit IRC | 09:53 | |
| *** NM has quit IRC | 10:00 | |
| *** lhcheng_ has joined #openstack-keystone | 10:00 | |
| marekd | elo | 10:01 |
| marekd | abelity: i don't | 10:01 |
| *** lhcheng has quit IRC | 10:03 | |
| *** arif-ali has quit IRC | 10:05 | |
| *** uvirtbot has joined #openstack-keystone | 10:05 | |
| *** aix has joined #openstack-keystone | 10:08 | |
| *** arif-ali has joined #openstack-keystone | 10:16 | |
| *** uvirtbot has quit IRC | 10:31 | |
| *** nellysmitt has joined #openstack-keystone | 10:36 | |
| openstackgerrit | Marcos Fermín Lobo proposed openstack/keystone: Split the assignments manager/driver. https://review.openstack.org/130954 | 10:37 |
| openstackgerrit | Marcos Fermín Lobo proposed openstack/keystone: Implement group related methods for LDAP backend https://review.openstack.org/102244 | 10:37 |
| *** uvirtbot has joined #openstack-keystone | 10:38 | |
| samuelms | marekd, do you know Marcos Fermín Lobo from cern? | 10:45 |
| *** xiaozhi has joined #openstack-keystone | 10:45 | |
| marekd | y | 10:46 |
| marekd | he sites next to me | 10:46 |
| marekd | what's up? | 10:46 |
| samuelms | marekd, just a sec | 10:47 |
| *** xiaozhi_ has quit IRC | 10:47 | |
| *** diegows has joined #openstack-keystone | 10:50 | |
| samuelms | marekd, https://review.openstack.org/#/c/130954/ | 10:51 |
| samuelms | marekd, take a look at the comment I just added at the end | 10:52 |
| openstackgerrit | Lin Hua Cheng proposed openstack/keystone: Always return the service name in the catalog https://review.openstack.org/135808 | 10:52 |
| *** uvirtbot has quit IRC | 10:52 | |
| samuelms | marekd, wait .. | 10:56 |
| samuelms | marekd, it looks like he only rebased the patch .. let me confirm | 10:56 |
| marekd | ok | 10:58 |
| *** dims has quit IRC | 11:01 | |
| *** dims has joined #openstack-keystone | 11:01 | |
| *** uvirtbot has joined #openstack-keystone | 11:02 | |
| *** uvirtbot has quit IRC | 11:03 | |
| samuelms | marekd, if you have a patch .. and you need to do a rebase to master .. | 11:03 |
| samuelms | marekd, the changes from master should not appear on your patch set, right? | 11:04 |
| samuelms | marekd, forget .. I'm confusing myself .. and confusing you | 11:05 |
| samuelms | haha | 11:05 |
| samuelms | marekd, he just rebased .. false alarm from me | 11:06 |
| marekd | samuelms: well, that's strange that henry's patch got a new version too, but i guess it's simply because of conf files being regenerated or sth | 11:07 |
| *** diegows has quit IRC | 11:07 | |
| marekd | the juicy meat is not changed. | 11:07 |
| samuelms | marekd, exctly | 11:07 |
| samuelms | marekd, I thought it was wrong .. because Marcos came like .. arriving by parachute on that and sending a new patch set | 11:07 |
| openstackgerrit | Marek Denis proposed openstack/keystone: Adds dynamic checking for mapped tokens https://review.openstack.org/133130 | 11:08 |
| samuelms | marekd, I was like .. lol | 11:08 |
| *** aix has quit IRC | 11:11 | |
| openstackgerrit | Marek Denis proposed openstack/keystone: Rename openid to oidc in test_auth_plugins.conf https://review.openstack.org/133494 | 11:16 |
| openstackgerrit | Marek Denis proposed openstack/keystone: Rename openid to oidc in test_auth_plugins.conf https://review.openstack.org/133494 | 11:17 |
| openstackgerrit | Marek Denis proposed openstack/keystone: Rename openid to oidc in test_auth_plugins.conf https://review.openstack.org/133494 | 11:18 |
| *** aix has joined #openstack-keystone | 11:42 | |
| openstackgerrit | Rodrigo Duarte proposed openstack/keystone: Adds dynamic checking for mapped tokens https://review.openstack.org/133130 | 11:45 |
| *** radez_g0n3 is now known as radez | 11:59 | |
| *** uvirtbot has joined #openstack-keystone | 12:04 | |
| *** KanagarajM has quit IRC | 12:18 | |
| *** uvirtbot has quit IRC | 12:22 | |
| *** eglynn-office is now known as eglynn-nick | 12:25 | |
| *** designate has joined #openstack-keystone | 12:26 | |
| *** designated has quit IRC | 12:28 | |
| *** xiaozhi has quit IRC | 12:28 | |
| *** oomichi has quit IRC | 12:31 | |
| openstackgerrit | David Stanek proposed openstack/keystone-specs: Adds a spec for fixing Keystone's DI https://review.openstack.org/135931 | 12:33 |
| *** links has quit IRC | 12:35 | |
| *** amakarov_away is now known as amakarov | 12:42 | |
| openstackgerrit | Marek Denis proposed openstack/keystone: Rename openid to oidc in test_auth_plugins.conf https://review.openstack.org/133494 | 12:45 |
| *** links has joined #openstack-keystone | 12:54 | |
| dstanek | marekd: morning! | 12:55 |
| *** bdossant_ has joined #openstack-keystone | 13:07 | |
| *** bdossant has quit IRC | 13:10 | |
| *** bdossant_ has quit IRC | 13:12 | |
| *** afazekas has quit IRC | 13:13 | |
| *** richm has joined #openstack-keystone | 13:15 | |
| *** nellysmitt has quit IRC | 13:16 | |
| *** nellysmitt has joined #openstack-keystone | 13:17 | |
| *** nellysmitt has quit IRC | 13:28 | |
| *** afazekas has joined #openstack-keystone | 13:29 | |
| *** Divya has joined #openstack-keystone | 13:30 | |
| Divya | Hi , I am trying to figure out if there are going to be any auditing enhancements in OpenStack Kilo. | 13:32 |
| *** nellysmitt has joined #openstack-keystone | 13:32 | |
| *** k4n0 has quit IRC | 13:38 | |
| rodrigods | Divya, you may refer to pycadf (https://launchpad.net/pycadf) | 13:38 |
| *** afazekas has quit IRC | 13:39 | |
| *** gordc has joined #openstack-keystone | 13:42 | |
| *** nellysmitt has quit IRC | 13:43 | |
| *** nellysmitt has joined #openstack-keystone | 13:46 | |
| *** miqui has joined #openstack-keystone | 13:46 | |
| *** jdennis has joined #openstack-keystone | 13:46 | |
| Divya | rodrigods , thanks will take a look | 13:47 |
| *** richm has quit IRC | 13:50 | |
| *** jdennis has quit IRC | 13:50 | |
| *** miqui_ has joined #openstack-keystone | 13:50 | |
| *** jdennis has joined #openstack-keystone | 13:51 | |
| *** henrynash has joined #openstack-keystone | 13:51 | |
| *** ChanServ sets mode: +v henrynash | 13:51 | |
| *** miqui__ has joined #openstack-keystone | 13:52 | |
| *** ajayaa has quit IRC | 13:53 | |
| *** miqui___ has joined #openstack-keystone | 13:54 | |
| zhiyan | morganfainberg: hi! would you mind give me two more mins to talk about oslo-inc policy module with you ?) | 13:55 |
| *** richm has joined #openstack-keystone | 13:55 | |
| *** miqui____ has joined #openstack-keystone | 13:55 | |
| *** Divya has quit IRC | 13:55 | |
| *** miqui___ has quit IRC | 13:56 | |
| *** miqui___ has joined #openstack-keystone | 13:57 | |
| raildo | zhiyan, rodrigods are working with this, maybe he can answer your questions | 13:58 |
| zhiyan | raildo: good to know. thanks | 13:58 |
| *** miqui__ has quit IRC | 13:58 | |
| *** miqui has quit IRC | 13:58 | |
| *** miqui____ has quit IRC | 13:58 | |
| *** miqui_ has quit IRC | 13:58 | |
| *** miqui___ has quit IRC | 13:58 | |
| zhiyan | rodrigods: may I ..? | 13:58 |
| rodrigods | zhiyan, go ahead =) | 13:59 |
| rodrigods | raildo, thanks | 13:59 |
| zhiyan | rodrigods: hey! :) | 13:59 |
| *** miqui has joined #openstack-keystone | 13:59 | |
| raildo | :) | 13:59 |
| zhiyan | rodrigods: this one https://review.openstack.org/#/c/128881/2 | 13:59 |
| rodrigods | zhiyan, looking | 14:00 |
| zhiyan | rodrigods: i'm handling glance oslo related works now. weeks ago, when i try to syncup latest oslo-inc.policy module to glance, i found there's a limitation for glance exiting ProtectProperty feature | 14:00 |
| rodrigods | zhiyan, can you paste the rule? | 14:01 |
| zhiyan | rodrigods: so I did a hurmless change for policy.py, as you seen, very small one | 14:01 |
| zhiyan | i can paste some glance built-in rules, but operator could config it as deployment needed.. | 14:02 |
| *** jistr has joined #openstack-keystone | 14:02 | |
| zhiyan | rodrigods: https://github.com/openstack/glance/blob/master/etc/property-protections-policies.conf.sample and https://github.com/openstack/glance/blob/master/etc/property-protections-roles.conf.sample | 14:02 |
| *** zzzeek has joined #openstack-keystone | 14:03 | |
| *** jistr is now known as jistr|mtg | 14:04 | |
| rodrigods | zhiyan, hmm, so you need those rules to not me overwritten by the ones in policy.json | 14:04 |
| zhiyan | rodrigods: sorry, don't followed.. | 14:05 |
| openstackgerrit | OpenStack Proposal Bot proposed openstack/keystone: Updated from global requirements https://review.openstack.org/134770 | 14:06 |
| openstackgerrit | OpenStack Proposal Bot proposed openstack/keystonemiddleware: Updated from global requirements https://review.openstack.org/135965 | 14:06 |
| zhiyan | rodrigods: actually glance build rules based on image property and these configuration in code, and set them into Enforcer object.. | 14:06 |
| *** nellysmitt has quit IRC | 14:06 | |
| *** ajayaa has joined #openstack-keystone | 14:06 | |
| rodrigods | zhiyan, to not be overwritten* | 14:06 |
| rodrigods | zhiyan, good, reading the code now | 14:07 |
| zhiyan | rodrigods: these rule could be overwritten | 14:07 |
| zhiyan | rodrigods: ok.. | 14:07 |
| openstackgerrit | OpenStack Proposal Bot proposed openstack/pycadf: Updated from global requirements https://review.openstack.org/135982 | 14:11 |
| openstackgerrit | OpenStack Proposal Bot proposed openstack/python-keystoneclient: Updated from global requirements https://review.openstack.org/134794 | 14:12 |
| openstackgerrit | OpenStack Proposal Bot proposed openstack/python-keystoneclient-federation: Updated from global requirements https://review.openstack.org/133570 | 14:12 |
| openstackgerrit | OpenStack Proposal Bot proposed openstack/python-keystoneclient-kerberos: Updated from global requirements https://review.openstack.org/135986 | 14:12 |
| rodrigods | zhiyan, I just didn't get why the "if flag" doesn't work in glance side | 14:13 |
| zhiyan | "if flag"? | 14:14 |
| *** miqui has quit IRC | 14:14 | |
| rodrigods | zhiyan, regarding the comments julien left | 14:14 |
| *** miqui has joined #openstack-keystone | 14:14 | |
| zhiyan | rodrigods: oh which one? | 14:15 |
| *** miqui_ has joined #openstack-keystone | 14:15 | |
| *** afazekas has joined #openstack-keystone | 14:15 | |
| zhiyan | rodrigods: you mean removing the "if reloaded" check? | 14:15 |
| *** diegows has joined #openstack-keystone | 14:16 | |
| *** jimhoagland has quit IRC | 14:17 | |
| *** miqui_ has quit IRC | 14:17 | |
| rodrigods | zhiyan, yep | 14:17 |
| *** nellysmitt has joined #openstack-keystone | 14:17 | |
| zhiyan | rodrigods: ok, | 14:17 |
| *** david-lyle has quit IRC | 14:18 | |
| zhiyan | rodrigods: if i remove that condition, only one left it "not self.rules", but in glance before do that code patch, self.rules may could has content | 14:18 |
| zhiyan | because glance code build some dynamic rules for protect property stuff | 14:19 |
| rodrigods | zhiyan, hmm | 14:19 |
| zhiyan | rodrigods: any details you want to know? | 14:20 |
| zhiyan | rodrigods: no worries, pls let me know your thoughts ) | 14:21 |
| *** nkinder has quit IRC | 14:21 | |
| rodrigods | zhiyan, just a sec =) | 14:22 |
| zhiyan | rodrigods: no rush! | 14:22 |
| *** joesavak has joined #openstack-keystone | 14:24 | |
| rodrigods | zhiyan, yeah, makes sense to me. Since we want to make it as generic as possible once it will graduate (this is already helps in the effort). I'll +1 it | 14:24 |
| zhiyan | rodrigods: thanks! | 14:25 |
| zhiyan | rodrigods: good man | 14:25 |
| zhiyan | rodrigods: i just want to make it fit into glance, btw. so i'd like to make it as harmless and sample as possible. | 14:25 |
| rodrigods | zhiyan, ++ | 14:27 |
| rodrigods | ayoung, ^^ can you please review it as well? https://review.openstack.org/#/c/128881/ | 14:27 |
| *** sigmavirus24 has joined #openstack-keystone | 14:30 | |
| *** bdossant has joined #openstack-keystone | 14:30 | |
| *** zzzeek has quit IRC | 14:30 | |
| zhiyan | ayoung: hi! look forwawrd to see your ideas on the revew, if you have any idea pls let me know it. thanks. | 14:43 |
| *** r-daneel has joined #openstack-keystone | 14:47 | |
| *** links has quit IRC | 14:48 | |
| *** ukalifon3 has joined #openstack-keystone | 14:49 | |
| *** ukalifon1 has quit IRC | 14:49 | |
| *** links has joined #openstack-keystone | 14:51 | |
| openstackgerrit | Merged openstack/python-keystoneclient-kerberos: Updated from global requirements https://review.openstack.org/135986 | 14:51 |
| *** Ctina has joined #openstack-keystone | 14:54 | |
| *** miqui has quit IRC | 15:00 | |
| *** miqui has joined #openstack-keystone | 15:05 | |
| *** topol has joined #openstack-keystone | 15:08 | |
| *** ChanServ sets mode: +v topol | 15:08 | |
| *** nkinder has joined #openstack-keystone | 15:10 | |
| *** nellysmitt has quit IRC | 15:17 | |
| *** miqui has quit IRC | 15:25 | |
| morganfainberg | zhiyan: pong | 15:27 |
| morganfainberg | Reading the scrollback now. | 15:27 |
| zhiyan | morganfainberg: cool! | 15:29 |
| *** jacorob has joined #openstack-keystone | 15:31 | |
| *** miqui has joined #openstack-keystone | 15:31 | |
| *** miqui has quit IRC | 15:32 | |
| *** miqui has joined #openstack-keystone | 15:34 | |
| *** miqui has quit IRC | 15:35 | |
| openstackgerrit | Lance Bragstad proposed openstack/keystone: Move test_utils to keystone/tests/unit/ https://review.openstack.org/133989 | 15:38 |
| morganfainberg | zhiyan: I might need coffee before I can score the patch. | 15:42 |
| topol | morganfainberg, does storyboard do the bug management as well? | 15:42 |
| zhiyan | morganfainberg: :) no worries/rush | 15:42 |
| morganfainberg | zhiyan: I'm reading it and I think I need to be more awake. Rules and enforcement is dense stuff :) | 15:42 |
| morganfainberg | topol: afaik, yes | 15:42 |
| topol | I was poking around on it but did not see any bugs | 15:42 |
| topol | cool | 15:43 |
| morganfainberg | henrynash: commented on your split patch last night. | 15:43 |
| zhiyan | morganfainberg: :)) | 15:43 |
| henrynash | morganfainberg: yep - saw that…replied to the general point a little earlier | 15:43 |
| morganfainberg | topol: I think bugs / bps are mostly the same. But infra and Michael kroscheck (sp?) can five more info | 15:44 |
| topol | it looks awesome. when do we get it? | 15:44 |
| *** abelity has quit IRC | 15:45 | |
| *** jorge_munoz has joined #openstack-keystone | 15:45 | |
| morganfainberg | henrynash: so I'm just concerned that the role and role assignment are very tightly intertwined. | 15:46 |
| morganfainberg | And the assignment backend will be difficult to manage / develop for being that roles are external. | 15:47 |
| openstackgerrit | Lance Bragstad proposed openstack/keystone: Remove XML support https://review.openstack.org/125738 | 15:47 |
| morganfainberg | Like I said in my comment, I don't think your proposal is wrong, just a tough split. | 15:48 |
| morganfainberg | lbragstad: woot. No more crummy xml support! | 15:48 |
| lbragstad | note to everyone who +2 the XML removal stuff yesterday ^^. The patch was in merge conflict so I repushed a new revision | 15:48 |
| morganfainberg | topol: maybe next cycle? | 15:48 |
| lbragstad | morganfainberg: also, the tempest patch made it through the gate | 15:49 |
| henrynash | morganfainberg: it’s a fair discussion point….although it certainly didn’t feel alien in the spli to have it in resource….in fact it felt easier that assignment is a pure mapper | 15:49 |
| lbragstad | so we should have an accurate run at tempest testing this patch set | 15:49 |
| morganfainberg | henrynash: that is the reason I didn't -1 | 15:50 |
| morganfainberg | topol: I want to be done with LP asap. | 15:50 |
| topol | morganfainberg. Me too :-). Its horrible :-) | 15:51 |
| morganfainberg | henrynash: ok so let's talk through what we gain / lose moving role into assignment. | 15:52 |
| morganfainberg | I think that'll help me resolve any dissonance here | 15:52 |
| *** henrynash has quit IRC | 15:52 | |
| marekd | dstanek: hey! | 15:53 |
| morganfainberg | marekd: hello! | 15:53 |
| *** bdossant has quit IRC | 15:55 | |
| morganfainberg | dolphm: ping re: venue for mid cycle. Is it safe to make the announcement of the space were using in San Antonio? | 15:55 |
| morganfainberg | And/or hotel. | 15:55 |
| dolphm | morganfainberg: not yet - i haven't received a response yet. they were *really* slow last time around too | 15:55 |
| morganfainberg | Ahh. | 15:55 |
| topol | morganfainberg, fungi just pointed out to me I didnt read the whole email and storyboard isnt yet ready for the rest of openstack | 15:55 |
| morganfainberg | topol: like I said. Maybe next cycle. | 15:56 |
| morganfainberg | topol: I had already asked ;) | 15:56 |
| dolphm | morganfainberg: give me like a week :-/ | 15:56 |
| topol | morganfainberg, I bet | 15:56 |
| morganfainberg | dolphm: works for me. Will bug you next week. ;) | 15:56 |
| *** henrynash has joined #openstack-keystone | 15:57 | |
| *** ChanServ sets mode: +v henrynash | 15:57 | |
| henrynash | morganfainberg: if were to imagine pluggin in an arbritary access control engine, I’m not sure why it owning roles wold help…imagine it’s some ABAC thing…it would, I assume, hold a bunch of other attributes tagged against existing objects, have its own rules that reference these attributes, but still result in just expressing what these mean in terms idenity_id X, project_id Y and role_id Z. | 15:57 |
| morganfainberg | Barbican might do SA as well now. | 15:57 |
| marekd | morganfainberg: good morning! | 15:58 |
| bknudson | did folks attend the barbican sessions at the summit? | 15:59 |
| bknudson | there was one for getting other projs to use barbican | 15:59 |
| morganfainberg | bknudson: there was an overlap every time. So I had to skip :(. | 15:59 |
| bknudson | essentially they have a credentials API and keystone has one, too | 16:00 |
| morganfainberg | Yes and I want ours to proxy to theirs | 16:00 |
| bknudson | also other projects are looking to use barbican... they said it was required for incubation | 16:00 |
| morganfainberg | At least as the transition point. (Or be able to at least) | 16:00 |
| bknudson | so I'd be interested to know if they're planning to be integrated | 16:01 |
| morganfainberg | henrynash: so whatever that engine is needs to be aware of the resource backend. | 16:01 |
| *** ukalifon3 has quit IRC | 16:01 | |
| morganfainberg | henrynash: hmm. | 16:02 |
| *** bdossant has joined #openstack-keystone | 16:02 | |
| *** david-lyle has joined #openstack-keystone | 16:02 | |
| bknudson | there was also talk about adding a certificate issuance API (so they can talk to your CA, or have an openssl-based sample CA) | 16:02 |
| morganfainberg | bknudson: also a good thing for them to do. | 16:03 |
| henrynash | morganfainberg: it needs to know what entity types (and their IDs) between which it must externally express all relationships …but teh rules and basis for those relationships are matter for its internals | 16:03 |
| bknudson | those were the 2 sessions I got to... not sure if I missed any. | 16:03 |
| ayoung | zhiyan I'll have to think about it...what it implies | 16:03 |
| morganfainberg | ayoung: that is why I am deferring until post coffee. | 16:04 |
| ayoung | ++ | 16:04 |
| morganfainberg | It is actually a very interesting approach. | 16:04 |
| zhiyan | ayoung: thanks. | 16:05 |
| zhiyan | morganfainberg: ayoung btw, current change didn't change any original logic with default params | 16:05 |
| morganfainberg | henrynash: so, then last question, what would a custom backend look like that isn't doing the sql mapping we are doing now? (LDAP isnt different enough to show what I am asking). | 16:06 |
| morganfainberg | I am trying to figure out what it actually looks like. | 16:07 |
| morganfainberg | I am for the split for a number of reasons, but I'm trying to make sure we're not backed into a different corner than we are now. If that makes sense. | 16:09 |
| *** thedodd has joined #openstack-keystone | 16:10 | |
| *** stevemar has joined #openstack-keystone | 16:13 | |
| *** ChanServ sets mode: +v stevemar | 16:13 | |
| rodrigods | morganfainberg, 2 rechecks in https://review.openstack.org/#/c/117786/ -> same tests failing =( | 16:14 |
| *** chrisshattuck has joined #openstack-keystone | 16:15 | |
| dstanek | marekd: at lunch now. I had a question about one of your reviews so it can wait | 16:16 |
| henrynash | morganfainberg: so imagine one that would store a bunch for additional attributes about users and projects (it would provide its’ own API to store these attributes), and then provide an API tp enable you to create relationships between these attributes (e.g. any user over the age of 18 has the role ok_to_by_tickets on project cinema). It would then dynamically interret its rules when asked “what roles do | 16:17 |
| henrynash | Henry have on project cinema”. This new attribute-based mapping would wrok just fine within today’s openstack…with the rest of teh system being oblivious to that fact that we have effectively ABAC running as an assignments model | 16:17 |
| dstanek | morganfainberg: the mid-cycle dates are firm right? I wasn't too get a plane ticket since they are currently cheap | 16:18 |
| *** __TheDodd__ has joined #openstack-keystone | 16:18 | |
| marekd | dstanek: ok | 16:18 |
| marekd | i will be here another ~1hour | 16:18 |
| morganfainberg | dstanek: yes. | 16:18 |
| morganfainberg | dstanek: we are just waiting for confirm of using geekdom or Rackspace. | 16:18 |
| dstanek | marekd: cool, thx | 16:19 |
| morganfainberg | Which directs what hotels were recommending. | 16:19 |
| *** thedodd has quit IRC | 16:19 | |
| *** sigmavirus24 is now known as sigmavirus24_awa | 16:19 | |
| dstanek | morganfainberg: works for me | 16:20 |
| ayoung | zhiyan, why reload in the first place? | 16:25 |
| *** nellysmitt has joined #openstack-keystone | 16:26 | |
| zhiyan | ayoung: sorry more details? | 16:27 |
| ayoung | zhiyan, why is glance reloading policy rules? | 16:27 |
| *** Ctina has quit IRC | 16:27 | |
| ayoung | zhiyan, what is the workflow that leads to there being multiple policy files? | 16:28 |
| *** Ctina has joined #openstack-keystone | 16:28 | |
| *** afazekas has quit IRC | 16:28 | |
| *** sigmavirus24_awa is now known as sigmavirus24 | 16:29 | |
| zhiyan | ayoung: normally, glance only reload policy.json when it get changed. | 16:30 |
| zhiyan | ayoung: actually in glance there's no multi-policy files | 16:30 |
| zhiyan | ayoung: but glance has feature called ProtectProperty | 16:30 |
| ayoung | what does that do? | 16:31 |
| *** _cjones_ has joined #openstack-keystone | 16:31 | |
| zhiyan | ayoung: which could gen policies in code based on configurations (which is not policies) and image properties. | 16:31 |
| ayoung | I need more information | 16:32 |
| zhiyan | ayoung: ok, in glance, there are some 'layers' | 16:32 |
| ayoung | are they using it for something other than policy checks? Is this a case of a singleton approach preventing the policy engine from being use for something else? | 16:32 |
| zhiyan | yes, finally code do checking just use only one policy enforcer object | 16:33 |
| zhiyan | that enforcer including all rules: policy.json and the ones protectproperty code added | 16:33 |
| ayoung | OK...so we really want different enforcer objects? | 16:34 |
| openstackgerrit | Merged openstack/pycadf: Updated from global requirements https://review.openstack.org/135982 | 16:34 |
| zhiyan | ayoung: no, teachnically it could work, but for glance is not sensible.. | 16:34 |
| *** __TheDodd__ has quit IRC | 16:34 | |
| *** jorge_munoz has quit IRC | 16:34 | |
| ayoung | what is ProtectProperty doing? | 16:35 |
| zhiyan | ayoung: i also mentioned the glance current design on this in comments as well | 16:35 |
| zhiyan | protectproperty do works in a 'layer' with in glance, it base on configurations and image properties(metadata) to gen policies | 16:36 |
| zhiyan | (and set these rules into one enforcer obj) | 16:36 |
| *** bdossant has quit IRC | 16:36 | |
| ayoung | are these policies enforced on api calls just like the policy.json file ? | 16:37 |
| zhiyan | 1 sec | 16:38 |
| zhiyan | ayoung: not so much | 16:39 |
| zhiyan | ayoung: they controls if enduser/request could crud on image property | 16:40 |
| ayoung | zhiyan, ok, so the problem is that they are autogenerating rules, but then when the API attempts to enforce policy, triggering a load_rules call, it wipes out the autogenerated rules, and both sets of rules should be evaluated together? | 16:47 |
| zhiyan | ayoung: yes | 16:47 |
| ayoung | zhiyan, ok, so the current code flushes all old rules upon load? | 16:48 |
| zhiyan | ayoung: yes | 16:48 |
| ayoung | with your code, if a new definition comes in for an existing rule, what happens? | 16:48 |
| zhiyan | "new definition" means? | 16:49 |
| zhiyan | ayoung: ^ | 16:49 |
| ayoung | zhiyan, for example, if is_admin: "role:admin" is currently defined, and on reload we get | 16:50 |
| ayoung | is_admin: "role:admin and project_id = {%project_id}" | 16:50 |
| ayoung | or whatever the format | 16:50 |
| zhiyan | ayoung: ok, it will be overwrite | 16:51 |
| ayoung | what would the end state of is_admin be? | 16:51 |
| zhiyan | i mean new loaded 'definition' will replace existing rule. | 16:51 |
| ayoung | So rules that are not explicitly states will be left untouched, but the explict rules will get their valus from the new file | 16:51 |
| zhiyan | just like original logic | 16:51 |
| ayoung | we have tests showing that? | 16:51 |
| zhiyan | yes, i think | 16:51 |
| zhiyan | in glance ProtectProperty feature, there's no new definition | 16:52 |
| ayoung | hmmm, don't like how were are writing the test conditions | 16:52 |
| ayoung | checking against what is in the enforcer is not specific enough | 16:53 |
| ayoung | zhiyan, can you do me a favor? Instead of lines likethis | 16:53 |
| ayoung | self.assertEqual('is_admin', self.enforcer.rules['admin'].kind) | 16:53 |
| ayoung | do something more like this | 16:53 |
| ayoung | rules = { ... what you have now } | 16:53 |
| ayoung | self.enforcer.set_rules(rules) | 16:54 |
| ayoung | and then | 16:54 |
| ayoung | run things through the test that should pass in one instance and fail in the other? | 16:54 |
| ayoung | Or at least check what the active rule is set in the enforcer, and that it matches the value from rules | 16:55 |
| ayoung | so | 16:55 |
| ayoung | assertIsEqual(rules['admin'], self.enforcer.rules['admin']) | 16:55 |
| *** marcoemorais has joined #openstack-keystone | 16:57 | |
| ayoung | zhiyan what I would like to see is this | 16:57 |
| ayoung | set the rules engine with one rule | 16:57 |
| ayoung | use the update mechanism | 16:58 |
| ayoung | see the new version of the rule | 16:58 |
| ayoung | also see that a rule that was not modified is still there in the origianl state | 16:58 |
| zhiyan | ayoung: ok, let me try to update the testcases | 16:59 |
| ayoung | zhiyan, bascially, I am saying more tests...test the assumptions and make them explicit | 16:59 |
| ayoung | sounds good. I'll put this feedback in the review | 16:59 |
| zhiyan | ayoung: thanks! | 17:00 |
| rodrigods | ayoung, good to see that wasn't wrong in thinking that the change makes sense :P | 17:02 |
| openstackgerrit | Marek Denis proposed openstack/keystone: Adds dynamic checking for mapped tokens https://review.openstack.org/133130 | 17:03 |
| marekd | stevemar: ^^ | 17:03 |
| *** Guest27879 is now known as redrobot | 17:04 | |
| *** zzzeek has joined #openstack-keystone | 17:07 | |
| *** henrynash has quit IRC | 17:08 | |
| openstackgerrit | Marek Denis proposed openstack/keystone-specs: Service Provider for K2K https://review.openstack.org/135604 | 17:09 |
| marekd | stevemar: ^^ | 17:09 |
| openstackgerrit | Marek Denis proposed openstack/keystone: Rename openid to oidc in test_auth_plugins.conf https://review.openstack.org/133494 | 17:09 |
| openstackgerrit | Marek Denis proposed openstack/keystone: Rename openid to oidc in test_auth_plugins.conf https://review.openstack.org/133494 | 17:09 |
| *** uvirtbot has joined #openstack-keystone | 17:13 | |
| *** uvirtbot has quit IRC | 17:14 | |
| *** uvirtbot has joined #openstack-keystone | 17:16 | |
| *** uvirtbot has quit IRC | 17:17 | |
| *** nellysmitt has quit IRC | 17:19 | |
| *** gyee has joined #openstack-keystone | 17:20 | |
| *** gyee has quit IRC | 17:24 | |
| *** gyee has joined #openstack-keystone | 17:24 | |
| *** Viswanath has joined #openstack-keystone | 17:24 | |
| *** gyee has quit IRC | 17:25 | |
| *** gyee has joined #openstack-keystone | 17:26 | |
| *** gyee has quit IRC | 17:26 | |
| *** gyee has joined #openstack-keystone | 17:26 | |
| *** ChanServ sets mode: +v gyee | 17:26 | |
| *** Viswanath has quit IRC | 17:27 | |
| *** marekd is now known as marekd|away | 17:30 | |
| morganfainberg | ayoung, zhiyan, so if i'm reading this correctly it's strictly a "user can change some aspects of permissions and therefore we need to support rloading but not replace the new custom perms"? | 17:34 |
| zhiyan | morganfainberg: yes, you r correct | 17:36 |
| morganfainberg | zhiyan, hm. i need to mull this one over but i'm not strictly opposed to it | 17:37 |
| morganfainberg | i do agree w/ ayoung about the better testing | 17:37 |
| ayoung | morganfainberg, It almost feels like we should be maintaining the origianl sources, and then layering them each time | 17:38 |
| zhiyan | morganfainberg: ok, i will do two more cases for positive and negative versions work | 17:38 |
| morganfainberg | ayoung: that is my feeling. | 17:38 |
| ayoung | morganfainberg, if it were two files, clear and then scanning each would make sense. Its is only because these rules are in memory only that will not work here | 17:38 |
| morganfainberg | But I was still looking over things before is made that statement more directed. | 17:39 |
| ayoung | I'm also a little concerned about what will happen when the base policy file is fetched from Keystone | 17:39 |
| ayoung | still, I think that this mechanism as is is probably the correct local approach | 17:39 |
| ayoung | and we should not prevent it from going forward just due to the future work | 17:39 |
| rodrigods | morganfainberg, did you see my message regarding the tests in the HM patch? | 17:44 |
| morganfainberg | rodrigods: yeah. I was trying to look at them but phone was too small | 17:44 |
| zhiyan | morganfainberg: rodrigods, ayoung pls ping if you have any ideas, gtg. thanks for your support! | 17:44 |
| rodrigods | morganfainberg, ah, ok... in the laptop already? | 17:45 |
| morganfainberg | rodrigods: waiting for a firmware update and I'll be looking more in depth at them. | 17:45 |
| rodrigods | morganfainberg, thx | 17:45 |
| ayoung | morganfainberg, if you are going to be PTL on the go I think you need a tablet | 17:45 |
| morganfainberg | ayoung: wouldn't have helped much. | 17:45 |
| openstackgerrit | Lin Hua Cheng proposed openstack/keystone: Always return the service name in the catalog https://review.openstack.org/135808 | 17:45 |
| morganfainberg | Laptop rebooted automatically into firmware update mode (missed the *no dont* click). | 17:46 |
| morganfainberg | annnnd back to laptop | 17:47 |
| morganfainberg | ooh pycharm 4. | 17:47 |
| morganfainberg | this ought to be "fun" ;) | 17:47 |
| *** aix has quit IRC | 17:51 | |
| openstackgerrit | Merged openstack/keystone: Updated from global requirements https://review.openstack.org/134770 | 17:53 |
| ayoung | morganfainberg, did my quick-and-dirty version of the Token model align with what you were thinking? | 17:58 |
| morganfainberg | ayoung, let me re-read it. | 17:59 |
| morganfainberg | ayoung, i *think* it did. | 17:59 |
| *** harlowja_away is now known as harlowja | 18:02 | |
| morganfainberg | the spec lines up with my thoughts | 18:04 |
| ayoung | morganfainberg, how about the code sample? | 18:05 |
| morganfainberg | ayoung, sure. i generally like that approach | 18:05 |
| morganfainberg | ayoung, i much prefer that to a bunch of @property magic. | 18:06 |
| ayoung | yeah, me too | 18:06 |
| *** RichardRaseley has joined #openstack-keystone | 18:06 | |
| ayoung | I tend to favor immutable objects. I'm thinking along these lines: 1 get a good set of objects that can be made immutable. 2. Define a builder interface to those objects. 3. Have Directors for the common means of building the model: From token data and from direct database calls | 18:07 |
| ayoung | When we get a new token format, it will get its own director | 18:07 |
| *** marcoemorais has quit IRC | 18:08 | |
| *** marcoemorais has joined #openstack-keystone | 18:08 | |
| morganfainberg | ayoung, ++ i think you've extracted out waht i've been thinking | 18:08 |
| morganfainberg | and if you look at how the token_model in keystone is being used, that was the direction i was aiming to head | 18:09 |
| ayoung | I think I had to accept that I was trying too hard to think Pythonically | 18:09 |
| morganfainberg | i just needed a stepping stone | 18:09 |
| *** amakarov is now known as amakarov_away | 18:09 | |
| morganfainberg | in fact... i even had an immutable version of that model | 18:09 |
| morganfainberg | at one point | 18:09 |
| morganfainberg | but it was too big a leap to do in one fell swoop | 18:09 |
| morganfainberg | i think the best plan is be pythonic in python... until it doesn't make sense | 18:10 |
| morganfainberg | then stop. | 18:10 |
| morganfainberg | rodrigods, huh | 18:10 |
| morganfainberg | rodrigods, interesting looks like user/project creation isn't working as expected | 18:11 |
| morganfainberg | rodrigods, http://logs.openstack.org/87/117787/33/check/check-tempest-dsvm-full/ebe0835/logs/devstacklog.txt.gz#_2014-11-19_13_14_23_172 | 18:11 |
| *** links has quit IRC | 18:11 | |
| morganfainberg | something specific about "create swift accounts" | 18:11 |
| rodrigods | morganfainberg, yeah... saw that | 18:12 |
| ayoung | morganfainberg, OK. So I am thinking that I should start with the code in token_models ? | 18:12 |
| ayoung | rework it in this fashion, and make things use that? | 18:12 |
| rodrigods | couldn't figure out what we might being doing wrong, so thought about the rebase possibility | 18:12 |
| morganfainberg | ayoung, yeah i think that is where i'd start | 18:12 |
| ayoung | morganfainberg, I should probably document this approach in the spec: will update first | 18:13 |
| morganfainberg | ayoung, i am going to start for the provider cleanup on the needed scaffolding to handle a very strictly enforced interface (StrictABC) | 18:13 |
| morganfainberg | ayoung, then work on the issuance code / formatters. | 18:13 |
| morganfainberg | a lot of shell games going to happen in this refactor i think | 18:13 |
| rodrigods | morganfainberg, hmm this was a sensitive change I've made https://review.openstack.org/#/c/117786/32..33/keystone/auth/controllers.py | 18:14 |
| ayoung | morganfainberg, so long as the model objects are not abstract, I think I'm good with that. | 18:15 |
| morganfainberg | ayoung, nah. | 18:15 |
| morganfainberg | ayoung, this is the provider interface | 18:15 |
| *** amcrn has joined #openstack-keystone | 18:16 | |
| ayoung | So the relationship between a token and the AccessInfo is... | 18:16 |
| ayoung | AccessInfo is the data, token is an assertion about that data? | 18:16 |
| morganfainberg | ayoung, the provider interface [issue, validate, etc] just needs to be very strict - down to the method signature | 18:16 |
| morganfainberg | ayoung, hm. | 18:16 |
| morganfainberg | ayoung, yes i think that is the right relationship | 18:17 |
| *** david-lyle has quit IRC | 18:17 | |
| morganfainberg | rodrigods, i'm trying to figure out why only the swift user creation is failing... | 18:17 |
| morganfainberg | rodrigods, or is swift jus tthe first one... | 18:18 |
| morganfainberg | ah just the first one | 18:18 |
| morganfainberg | rodrigods, so yeah something you've introduced in the HM code has broken how swift sets up it's users (probably user creation across the board) | 18:18 |
| rodrigods | morganfainberg, hmm | 18:19 |
| rodrigods | morganfainberg, thanks, will debug it here | 18:19 |
| morganfainberg | and it is something between patchset 32 and 33 | 18:19 |
| morganfainberg | 32 passes | 18:19 |
| rodrigods | yep | 18:19 |
| morganfainberg | https://review.openstack.org/#/c/117786/32..33/keystone/auth/controllers.py this might be it. | 18:20 |
| rodrigods | morganfainberg, exactly... just put it in the base classes | 18:20 |
| morganfainberg | it *may* also be the create hierarchy code | 18:20 |
| morganfainberg | https://review.openstack.org/#/c/117786/32..33/keystone/tests/test_backend.py | 18:20 |
| morganfainberg | oh wait | 18:21 |
| morganfainberg | no that's tests | 18:21 |
| morganfainberg | derp | 18:21 |
| rodrigods | morganfainberg, self.griver.get_project() -> self.get_project()? :o | 18:21 |
| morganfainberg | yeah looking at that as well | 18:21 |
| *** jorge_munoz has joined #openstack-keystone | 18:22 | |
| rodrigods | morganfainberg, was pretty sure we had a Manager call to it =( | 18:22 |
| morganfainberg | oh it should pass through | 18:22 |
| morganfainberg | even if you do't have an explicit manager method for it | 18:22 |
| rodrigods | morganfainberg, ++ | 18:22 |
| morganfainberg | more magic runtime *stuff* [ugh] | 18:22 |
| rodrigods | morganfainberg, must be the get_auth_context part | 18:23 |
| morganfainberg | the self.get_project *shouldn't* be an issue | 18:23 |
| morganfainberg | rodrigods, yep | 18:26 |
| morganfainberg | http://logs.openstack.org/86/117786/33/check/check-tempest-dsvm-postgres-full/55b13ec/logs/screen-key.txt.gz#_2014-11-20_09_47_46_295 | 18:26 |
| morganfainberg | the auth context stuff is an issue | 18:26 |
| openstackgerrit | Lance Bragstad proposed openstack/keystone: Remove XML support https://review.openstack.org/125738 | 18:27 |
| rodrigods | morganfainberg, hmm strange, thought the user_id would always be present | 18:27 |
| morganfainberg | rodrigods, well there is the reason things are failing | 18:28 |
| morganfainberg | not sure what change caused that. | 18:28 |
| morganfainberg | but... my guess is auth_context stuff | 18:28 |
| morganfainberg | without digging in further | 18:28 |
| rodrigods | morganfainberg, yeah, I'm getting the user_id in get_project() so we can use it to list_projects_for_user() in the subtree/parents call | 18:28 |
| rodrigods | morganfainberg, getting from the context | 18:29 |
| rodrigods | since it is not present in the URL | 18:29 |
| morganfainberg | dolphm, ayoung, anything we've landed recently in middleware/client that needs a release/ | 18:29 |
| morganfainberg | ? | 18:29 |
| *** radez is now known as radez_g0n3 | 18:29 | |
| ayoung | morganfainberg, not that I know of. I think we want jamielennox 's changes to support v3 soonest, but those are still pending | 18:29 |
| dolphm | morganfainberg: doesn't work for features, but run the release script without --release and see if there are any High bugs committed | 18:29 |
| dolphm | for blueprints* (works for wishlist, obviously) | 18:30 |
| morganfainberg | dolphm, ah right | 18:30 |
| rodrigods | morganfainberg, line 419: https://review.openstack.org/#/c/117786/33/keystone/assignment/controllers.py | 18:30 |
| morganfainberg | dolphm, thanks :) i forgot about that script | 18:30 |
| rodrigods | morganfainberg, I might ask if this seems the right approach, too :) | 18:30 |
| rodrigods | morganfainberg, thanks for helping debuging this, btw | 18:30 |
| *** vhoward has left #openstack-keystone | 18:31 | |
| morganfainberg | stevemar, ping re: OIDC | 18:31 |
| morganfainberg | stevemar, anything elft outstanding on that BP? | 18:31 |
| *** vhoward has joined #openstack-keystone | 18:33 | |
| *** marcoemorais has quit IRC | 18:36 | |
| *** marcoemorais has joined #openstack-keystone | 18:36 | |
| dstanek | lbragstad: what happened in that XML patch? just merge resolutions? | 18:37 |
| lbragstad | dstanek: yeah, merge conflicts | 18:37 |
| dstanek | lbragstad: cool. looking again then. how close is the tempest change to being accepted | 18:38 |
| lbragstad | dstanek: it's merged | 18:38 |
| lbragstad | dstanek: https://review.openstack.org/#/c/126564/ | 18:38 |
| dstanek | nice | 18:38 |
| stevemar | morganfainberg, just the client side work | 18:39 |
| morganfainberg | stevemar, ok marked as implemented and targeted to K1 | 18:39 |
| stevemar | yay | 18:39 |
| morganfainberg | the client stuff isn't affected then. | 18:39 |
| * morganfainberg does relmgmt stuff today. | 18:39 | |
| *** marcoemorais has quit IRC | 18:40 | |
| *** marcoemorais has joined #openstack-keystone | 18:41 | |
| *** ajayaa has quit IRC | 18:41 | |
| *** uvirtbot has joined #openstack-keystone | 18:41 | |
| stevemar | dstanek, ah good to know i wasn't the only one who thought that about is_* https://review.openstack.org/#/c/133130/14..15/keystone/token/providers/common.py | 18:41 |
| *** uvirtbot has quit IRC | 18:41 | |
| dstanek | stevemar: yeah :-) | 18:42 |
| gyee | ayoung, just occur to me, if we make AccessInfo a requirement for auth context, it would be tough to do tokenless authz | 18:43 |
| ayoung | gyee, Hah, actually, just the opposite! | 18:43 |
| ayoung | gyee, tokenless will have a builder that creates AccessInfo from the authentication info | 18:44 |
| gyee | but it may not have all the required info | 18:44 |
| gyee | like expiration date, roles, etc | 18:44 |
| gyee | unless those are optional | 18:45 |
| morganfainberg | dstanek, http://specs.openstack.org/openstack/keystone-specs/specs/kilo/tests-on-rdbmses.html has a typo in the spec, we should fix the link | 18:47 |
| dstanek | morganfainberg: i'll get that fixed up | 18:48 |
| dstanek | morganfainberg: typo besides the link? | 18:48 |
| morganfainberg | dstanek, yeah nbd, just figured we should get that fixed. | 18:48 |
| morganfainberg | nah, just the link is busted | 18:48 |
| morganfainberg | looks like a typo in the rst probably to blame | 18:48 |
| openstackgerrit | ayoung proposed openstack/keystone-specs: Access Info https://review.openstack.org/135774 | 18:48 |
| rodrigods | morganfainberg, think this gonna work now: https://review.openstack.org/#/c/117786/34/keystone/assignment/controllers.py | 18:49 |
| rodrigods | morganfainberg, thanks again! | 18:49 |
| morganfainberg | rodrigods, cool. | 18:49 |
| morganfainberg | rodrigods, np | 18:49 |
| openstackgerrit | David Stanek proposed openstack/keystone-specs: Fixes link to spec blueprint https://review.openstack.org/136090 | 18:54 |
| gyee | ayoung, I like they way you describe the alternatives, "Do nothing and suffer for it" | 18:54 |
| ayoung | :) | 18:54 |
| gyee | how about "the sky will rain endlessly"? | 18:54 |
| dstanek | gyee: ayoung: i said something similar in the spec i submitted this morning. it's an attention grabber | 18:55 |
| ayoung | rodrigods, I the way my IRC client wrapped you line, I just read trollers.py | 18:55 |
| gyee | dstanek, nice, might as well | 18:55 |
| ayoung | 40 years of darkness. The dead arising from the grave | 18:55 |
| ayoung | dstanek, actually, I was interested in your feedback | 18:55 |
| ayoung | You like the general approach I posted last night? | 18:56 |
| dstanek | ayoung: on which one? access info? | 18:56 |
| ayoung | dstanek, yeah, the sample code | 18:56 |
| ayoung | I send in an email, but also had a paste. | 18:56 |
| gyee | no issue there | 18:56 |
| ayoung | http://paste.openstack.org/show/135032/ dstanek | 18:56 |
| dstanek | ayoung: jas - looking | 18:56 |
| dstanek | ah thx | 18:56 |
| morganfainberg | 2014.2 = stable/juno right? | 18:57 |
| ayoung | morganfainberg, that is my interpretation, yes | 18:57 |
| ayoung | "second stable release of 2014" | 18:57 |
| dstanek | ayoung: why do the assert_class at all? | 18:57 |
| ayoung | dstanek, so you know that the contained objects meet the contract | 18:58 |
| ayoung | IE, you can't put junk into the domain field | 18:58 |
| ayoung | it has to have domain.id and domain.name | 18:58 |
| ayoung | its called type safty, and I miss it terribly | 18:59 |
| ayoung | sniff | 18:59 |
| dstanek | ayoung: also you want the objects to be accessible using dictionary syntax? | 18:59 |
| ayoung | dstanek, yeah..that is one of the main uses | 19:00 |
| *** Viswanath has joined #openstack-keystone | 19:00 | |
| ayoung | policy is enforced on a dictionary | 19:00 |
| ayoung | and a bunch of other things assume a dictionary, too | 19:00 |
| ayoung | don;t want to have to rewrite every consumer, just provide the proper interface | 19:00 |
| morganfainberg | we should probably backport all the inherited role stuff to juno | 19:00 |
| morganfainberg | that henryfixed | 19:00 |
| ayoung | dstanek, I was also going to put some Date operations in there, but hadn't yet figured out what the right abstraction was | 19:01 |
| dstanek | ayoung: to save execution speed can __setattr__ just raise an exception alway? if you don't want the object to be immutable just don't subclass it | 19:02 |
| ayoung | dstanek, no | 19:02 |
| ayoung | dstanek, it needs to support setting the properites up to a point | 19:02 |
| ayoung | and then lock the object | 19:02 |
| ayoung | dstanek, what happens if you do that, and try to set the properties in the __init__? I thought that wouldn't work anyway | 19:03 |
| dstanek | ayoung: the way i've done it in the past is called the super's __setattr__ from the __init__ | 19:04 |
| dstanek | at least that's what i currently remember. that was old, old Python 1.52 code | 19:04 |
| *** marcoemorais has quit IRC | 19:04 | |
| *** marcoemorais has joined #openstack-keystone | 19:05 | |
| *** Viswanath has quit IRC | 19:07 | |
| openstackgerrit | Merged openstack/keystone-specs: Fixes link to spec blueprint https://review.openstack.org/136090 | 19:08 |
| ayoung | dstanek, ah... | 19:09 |
| ayoung | let me try that out | 19:09 |
| ayoung | dstanek, so...anything could do that? | 19:09 |
| ayoung | like if I had an immutable object o, I could do | 19:10 |
| ayoung | s = o.super | 19:10 |
| ayoung | or somewierdness like that? | 19:10 |
| dstanek | super(Class, self).__setattr__('name', 'value') - should do it | 19:12 |
| ayoung | dstanek, so it is not possible to make an object immutable? | 19:12 |
| ayoung | there is always the "appeal to the parent class" bypass? | 19:12 |
| dstanek | ayoung: not really - you can make it not obvious | 19:12 |
| *** chrisshattuck has quit IRC | 19:13 | |
| ayoung | dstanek, is this a side effect of descending from object? | 19:13 |
| dstanek | ayoung: Python is all about trust | 19:13 |
| ayoung | I'm not | 19:13 |
| *** chrisshattuck has joined #openstack-keystone | 19:14 | |
| ayoung | I'm all about the distrust | 19:14 |
| *** chrisshattuck has quit IRC | 19:14 | |
| *** chrisshattuck has joined #openstack-keystone | 19:15 | |
| ayoung | dstanek, what if immutable did not descend from object? Would that prevent access to the parent __setattr__? | 19:16 |
| dstanek | ayoung: still no dice and in Python 3 you have no choice | 19:16 |
| ayoung | yeah, I read that | 19:16 |
| dstanek | ayoung: you're fighting the language and culture now | 19:17 |
| ayoung | dstanek, yeah, but knwoing the limits is valuable | 19:17 |
| ayoung | besides, dstanek you act like I have a choice about using Python. I don't. | 19:19 |
| ayoung | I'm not going to throw out all of the lessons I've learned just to conform | 19:20 |
| dstanek | ayoung: no, i just think it would be easier to give in :-P | 19:20 |
| ayoung | dstanek, but you know me so much better than that | 19:20 |
| dstanek | ayoung: the easiest way to get around the immutability would be to just access the __dict__ directly | 19:20 |
| ayoung | http://www.yegor256.com/2014/06/09/objects-should-be-immutable.html | 19:21 |
| ayoung | ok, that does it. I'm going implement in C and use FFI | 19:21 |
| ayoung | oh, wait.. | 19:21 |
| dstanek | i actually agree to an extent | 19:22 |
| ayoung | dstanek, what happens if I do self.__slots__ == () | 19:24 |
| ayoung | or something along those lines? | 19:24 |
| ayoung | or is that for tuples only? | 19:24 |
| dstanek | ayoung: you can't add other properties, but you can still change the ones you list in slots | 19:24 |
| dstanek | ayoung: it's a memory optimization | 19:24 |
| ayoung | dstanek, so if I remove all values from slots, is the object immutable? | 19:25 |
| dstanek | ayoung: i'm not sure what would happen with slots and your custom setattr | 19:25 |
| ayoung | Let me try playing with that | 19:25 |
| dstanek | yes | 19:25 |
| dstanek | ayoung: the right way to do it would be to not have any public properties | 19:26 |
| ayoung | dstanek, um...no. Need to have public properties. Its like the number one thing these classes need | 19:27 |
| ayoung | the only language I've seen that does this close to right is C++ | 19:28 |
| ayoung | Java is close, but Null pointers kindof force you to have code that checks you are not setting a property to Null | 19:28 |
| *** rwsu has quit IRC | 19:32 | |
| *** marcoemorais has quit IRC | 19:33 | |
| *** rwsu has joined #openstack-keystone | 19:33 | |
| *** marcoemorais has joined #openstack-keystone | 19:33 | |
| *** marcoemorais has quit IRC | 19:33 | |
| *** marcoemorais has joined #openstack-keystone | 19:33 | |
| dstanek | ayoung: yes, i like the null object pattern instead of ever using null | 19:34 |
| ayoung | ++ | 19:34 |
| openstackgerrit | Rodrigo Duarte proposed openstack/keystone: Adds dynamic checking for mapped tokens https://review.openstack.org/133130 | 19:37 |
| rodrigods | stevemar, dstanek ^ | 19:38 |
| stevemar | ty | 19:38 |
| openstackgerrit | Rodrigo Duarte proposed openstack/keystone: Adds dynamic checking for mapped tokens https://review.openstack.org/133130 | 19:41 |
| *** radez_g0n3 is now known as radez | 19:44 | |
| rodrigods | stevemar, the list turns to something like | 19:45 |
| rodrigods | methods=external,saml2,oidc | 19:45 |
| *** chrisshattuck has quit IRC | 19:45 | |
| rodrigods | stevemar, without the [], didn't understand why put [] in the first place | 19:45 |
| stevemar | rodrigods, i'm confused, what file/line are you specifically talking about :) | 19:46 |
| ayoung | dstanek, setting __slots__ does not seem to be something that can be done after the object is created | 19:47 |
| rodrigods | stevemar, sorry... https://review.openstack.org/#/c/133130/16/keystone/common/config.py | 19:47 |
| ayoung | or, at least it has no effect | 19:47 |
| morganfainberg | https://launchpad.net/keystone/+milestone/kilo-1 that looks better. | 19:48 |
| dstanek | ayoung: yes, it has to be there before the __new__ is called because it changes the way Python constructs the object | 19:48 |
| ayoung | rodrigods, What are you guys doing? Why do you need to call out which are the mapped methods? | 19:48 |
| bknudson | rodrigods: stevemar: if it's a listopt then in the config file it's strings separated by , | 19:48 |
| bknudson | so saml2,oidc | 19:49 |
| rodrigods | bknudson, ++ | 19:49 |
| ayoung | ok, this is for if 'saml2' in method_names or 'oidc' in method_names | 19:49 |
| ayoung | and we use that to limi control to | 19:49 |
| raildo | morganfainberg, I can't assignee me to the HM bp :( https://blueprints.launchpad.net/keystone/+spec/hierarchical-multitenancy | 19:49 |
| ayoung | self._handle_federation_tokens( | 19:50 |
| *** uvirtbot has joined #openstack-keystone | 19:50 | |
| ayoung | and what does that do.... | 19:50 |
| rodrigods | ayoung, so if we add a new mapped method, we would only need to add it to the config file, not to the "if" in the issue_v3_ part | 19:50 |
| morganfainberg | raildo, fixed | 19:50 |
| raildo | morganfainberg :D | 19:50 |
| ayoung | federation.FEDERATION: { | 19:50 |
| ayoung | 'identity_provider': {'id': idp}, | 19:50 |
| ayoung | 'protocol': {'id': protocol} | 19:50 |
| ayoung | } | 19:50 |
| ayoung | so...this is backwards | 19:51 |
| ayoung | rodrigods, can you hold off on this...I think the right solution is to have the data set up front by the mapped plugin, not to make it a config option | 19:51 |
| ayoung | it really should not be a config option | 19:51 |
| *** packet has joined #openstack-keystone | 19:52 | |
| rodrigods | ayoung, we discussed about listing all protocols and than checking, but since we *must* add those configs, don't really see the problem here | 19:52 |
| ayoung | rodrigods, nope, that is wrong, too | 19:53 |
| rodrigods | ayoung, but that is how is done today | 19:53 |
| ayoung | the mapped plugin should know what protocol it is supporting | 19:53 |
| ayoung | so what. we are gods among men here | 19:53 |
| ayoung | we can make it as we can imagine! | 19:53 |
| ayoung | :) | 19:54 |
| ayoung | ok, that might be a bit grandiose | 19:54 |
| *** chrisshattuck has joined #openstack-keystone | 19:54 | |
| rodrigods | ayoung, haha | 19:54 |
| ayoung | rodrigods, http://git.openstack.org/cgit/openstack/keystone/tree/keystone/token/providers/common.py#n431 | 19:55 |
| rodrigods | ayoung, so you're saying the protocols should be a list inside the mapping engine and I ask "can you handle X?" | 19:55 |
| ayoung | rodrigods, when I configure a mapped method, I should be able to extract from the context what protocol/mapping is in effect | 19:56 |
| ayoung | we don't carry that forward | 19:56 |
| ayoung | so the toiken provider doesn't know it, but there is no reason that it could not | 19:56 |
| ayoung | keying of the method names is the wrong approach, it should be something like: | 19:57 |
| ayoung | ok..one thing you could do is : for method in method_names: if config[auth][method] == ..mapped | 19:58 |
| ayoung | and get the same effect: lookup to see if the config option points to the mapped plugin | 19:58 |
| ayoung | now, that approach sucketh, as well | 19:58 |
| ayoung | cuz maybe you subclass the mapped auth plugin | 19:58 |
| ayoung | instead, the auth plugin should add the data required to the context being used to build the token....lets see | 19:59 |
| *** marcoemorais has quit IRC | 19:59 | |
| ayoung | rodrigods, why do we not just look at the value of idp = auth_context[federation.IDENTITY_PROVIDER] | 19:59 |
| ayoung | if there is something there, always put in the federation.FEDERATION: { block? | 20:00 |
| rodrigods | ayoung, idp and protocol | 20:01 |
| rodrigods | ayoung, makes sense to me | 20:01 |
| ayoung | right | 20:01 |
| rodrigods | need to get some input from stevemar and marekd|away though | 20:01 |
| ayoung | if one is missing but the other is there, it means something is wrong and broken, right? | 20:01 |
| rodrigods | ayoung, right | 20:01 |
| rodrigods | ayoung, we need both | 20:01 |
| *** nkinder has quit IRC | 20:02 | |
| *** stevemar has quit IRC | 20:03 | |
| *** stevemar has joined #openstack-keystone | 20:03 | |
| *** ChanServ sets mode: +v stevemar | 20:03 | |
| ayoung | rodrigods, ok...going to -1 this until sorted | 20:04 |
| rodrigods | ayoung, ok | 20:04 |
| stevemar | ayoung, rodrigods if you have another solution put it in the bug, the proposed one works, nkinder and i hashed it out | 20:05 |
| ayoung | stevemar, posting | 20:06 |
| ayoung | stevemar, if auth_context[federation.IDENTITY_PROVIDER] is set, then it should be in the token data, no? | 20:07 |
| ayoung | stevemar, it should not be keyed off of the method name, and should not require an explicit config option. What am I missing? | 20:08 |
| lbragstad | dstanek: looks like some of the other clients in tempest are using Keystone XML clients :( | 20:13 |
| dstanek | ha ha, that sucks | 20:14 |
| *** chrisshattuck has quit IRC | 20:33 | |
| *** _cjones_ has quit IRC | 20:39 | |
| samuelms | hi, recently we have had some discussions on how we use rbac for access control on OS | 20:40 |
| samuelms | role-groups and hierarchical roles are some ideas that have appeared | 20:40 |
| samuelms | I think we feel that we need to improve our access control experience | 20:40 |
| samuelms | I had some ideas and I've already discussed them with henrynash, who thinks it's an interesting proposal | 20:40 |
| samuelms | I'd like to share it with you all and then get your feedback | 20:40 |
| samuelms | https://etherpad.openstack.org/p/role-capabilities-policy | 20:41 |
| samuelms | I'd be glad to have other core opinions on there | 20:42 |
| samuelms | dolphm, morganfainberg, ayoung, bknudson, dstanek, gyee, jamielennox, lbragstad, stevemar, topol ^ | 20:43 |
| ayoung | samuelms, looking | 20:45 |
| ayoung | samuelms, so that basically is what I proposed, modulo I want the groups to be public and shorthand for the atomic roles | 20:46 |
| ayoung | otherwise, we end up putting each and every capability into the token | 20:46 |
| ayoung | samuelms, those capabilites are what you were basically collecting up in the git repo with the unified policy file | 20:47 |
| samuelms | ayoung, yes .. we could do that way .. an alternative would be having a list_capabilities on every service | 20:47 |
| *** _cjones_ has joined #openstack-keystone | 20:47 | |
| ayoung | samuelms, what does that mean? | 20:48 |
| samuelms | ayoung, read Prosposed Change section 3 | 20:48 |
| samuelms | ayoung, 3.1.1 talks about list_capabilities . 3.1.2 would be reading up the policy (the unified one :)) | 20:49 |
| ayoung | samuelms, ok...yeah, those are the options as I see them as well | 20:49 |
| ayoung | So either expand when generating the token or create a shorthand that the server pre-fetches | 20:49 |
| ayoung | policy file is the shorthand | 20:49 |
| *** MasterPiece has joined #openstack-keystone | 20:50 | |
| ayoung | samuelms, we could do the bitmapped approach for enumerating all capabilities, but I would not advocate that. It's fragile and hard to read | 20:50 |
| samuelms | ayoung, yeah .. that's interest .. but not human-readable | 20:51 |
| samuelms | ayoung, feel free to add comments in there :-) | 20:51 |
| ayoung | samuelms, seems like something that git could solve | 20:51 |
| *** _cjones_ has quit IRC | 20:52 | |
| samuelms | ayoung, should I submit a spec review? | 20:52 |
| ayoung | samuelms, no | 20:52 |
| ayoung | samuelms, we have two specs, and I think they cover the range of options | 20:52 |
| samuelms | ayoung, ok .. in fact that are a bunch of ideas .. (that cover those 2 specs ) | 20:53 |
| samuelms | ayoung, then it doesnt make sense to create another one | 20:53 |
| ayoung | samuelms, it comes down to "expand in the token" or "expand in policy" and I think there are reasons for both | 20:54 |
| samuelms | ayoung, do you think the list_capabilities api call could be considered? | 20:57 |
| samuelms | ayoung, that should be implemented by all services .. | 20:57 |
| ayoung | samuelms, yes | 20:57 |
| ayoung | samuelms, but only by keystone, not the services | 20:58 |
| ayoung | there should be a registered set of capabilites | 20:58 |
| samuelms | ayoung, if only keystone implement that .. how we would register capabilities fro mother services? | 20:59 |
| samuelms | from other* | 20:59 |
| samuelms | reading up the policy file? | 20:59 |
| samuelms | ayoung, think the way we do this should be the same for all services | 21:00 |
| ayoung | yep | 21:00 |
| samuelms | ayoung, yes for doing the same way for all services? | 21:00 |
| samuelms | ayoung, if we have that api call in all services .. they could register themselves and then keystone would get available capabilities :) | 21:01 |
| ayoung | nah | 21:01 |
| ayoung | too much | 21:01 |
| samuelms | ayoung, all on the fly | 21:01 |
| samuelms | ayoung, I think that is the best solution .. but not for now .. I don't believe we can convince other services and then have this quickly .. | 21:03 |
| ayoung | samuelms, I think the impetus is on the services to call to keystone to register their capabilites, not for keystone to query them | 21:03 |
| ayoung | that can be done statically, too | 21:03 |
| *** jorge_munoz has quit IRC | 21:03 | |
| samuelms | ayoung, how does it work for endpoints? | 21:04 |
| ayoung | samuelms, ok, here's what I would suspect | 21:05 |
| samuelms | ayoung, once a new endpoint for a new service appears on keystone .. keystone asks for the capabilities | 21:05 |
| ayoung | when I create a new endpoint, and I want a customer policy file, I register my rules with keystone. Those will override the default rules for those capabilites explicitly listed | 21:05 |
| samuelms | ayoung, but I don't know how that endpoint registering occurs | 21:05 |
| stevemar | ayoung, https://review.openstack.org/#/c/133130/ | 21:06 |
| stevemar | commented | 21:06 |
| *** edmondsw has joined #openstack-keystone | 21:06 | |
| ayoung | stevemar, yes, that is what I was suggesting | 21:06 |
| * stevemar agrees with ayoung then | 21:07 | |
| stevemar | :) | 21:07 |
| richm | stevemar: ping - is "openstack token issue" the same as "keystone token-get"? | 21:08 |
| stevemar | richm, should be | 21:08 |
| stevemar | richm, that one has been buggy because of changes in the auth layer of keystoneclient and openstackclient, but that is the goal | 21:08 |
| richm | stevemar: ok - I'm writing the puppet/ruby code for this - it uses keystone token-get to see if the given password is working | 21:09 |
| richm | if there is an easier way to check if a password works, that would be fine too | 21:09 |
| richm | also related to passwords - how do I do "keystone user-password-update"? | 21:10 |
| stevemar | richm, are you using osc from master or from pypi (0.4) ? | 21:10 |
| richm | stevemar: let me see | 21:10 |
| stevemar | richm, that should be openstack user update --password blah | 21:10 |
| richm | I'm using 0.4.1 from fedora package | 21:10 |
| richm | stevemar: ok - thanks | 21:10 |
| samuelms | ayoung, in that approach, IF we have list_capabilities for each service .. it's like we don't need policy FILE anymore (as it is today).. do you agree? | 21:10 |
| samuelms | ayoung, as henrynash replied your dynamic policy email | 21:11 |
| samuelms | ayoung, henrynash: Eventually (as pointed out by samuelmz) the policy "file" could even simply become the definition of the service capabilities (and whether each capability is "open", "closed" or "is a role")...maybe just registered and stored in the service entity the keystone DB (allowing dynamic service registration). | 21:11 |
| ayoung | samuelms, well, each capability would need to be able to specify what rule it follows, which might be more than just "role:blah" | 21:11 |
| stevemar | richm, cool, might be worth pulling down the master one and playing... we plan on cutting a 1.0 very soon (cc dtroyer) | 21:11 |
| *** david-lyle has joined #openstack-keystone | 21:11 | |
| ayoung | samuelms, there are some rules that are more complext | 21:11 |
| samuelms | ayoung, ex ? | 21:11 |
| richm | stevemar: ok - thanks | 21:11 |
| stevemar | dtroyer, i'm spreading the word! | 21:12 |
| ayoung | samuelms, got a link to your git repo handy? | 21:12 |
| *** david-lyle has quit IRC | 21:12 | |
| ayoung | I'll show you in there | 21:12 |
| dtroyer | stevemar: the next unblocking review is nearing merge: https://review.openstack.org/136018 | 21:12 |
| dtroyer | then it's a mad rush to merge all that do stuff ;) | 21:12 |
| stevemar | dtroyer, ugh | 21:12 |
| stevemar | dtroyer, what do we want to do about OS_USER/PROJECT_DOMAIN_ID/NAME | 21:12 |
| samuelms | ayoung, why not use the ehterpad ? :p | 21:12 |
| stevemar | it's bad to use default, we all agree, i think we should just doc it somewhere that those are req'd for v3 and be done with it | 21:13 |
| dtroyer | my head is deep inside devstack and specs ATM, is the current situation livable or will we break it to fix it? | 21:13 |
| ayoung | samuelms, cuz you were looking for an example and I don't know it off the top of my head and want to make you do the work | 21:13 |
| *** david-lyle has joined #openstack-keystone | 21:13 | |
| samuelms | ayoung, aaa.. you talk about the repo I created yesterday .. 1 sec | 21:13 |
| ayoung | yeah | 21:13 |
| samuelms | https://github.com/samuel-ms/os.unified.policy | 21:14 |
| samuelms | ayoung, ^ | 21:14 |
| stevemar | dtroyer, i think it's livable, just export 2 more variables, we could make devstack export the 2 to default as a starter | 21:15 |
| ayoung | samuelms, https://github.com/samuel-ms/os.unified.policy/blob/master/src/policy.json#L626 | 21:15 |
| samuelms | ayoung, what does that mean ? :p | 21:16 |
| dtroyer | stevemar: ok, let's leave it alone in OSC and teach devstack the Right Thing | 21:16 |
| ayoung | samuelms, it means that neutron is doing unspeakable things with policy | 21:19 |
| *** topol has quit IRC | 21:19 | |
| ayoung | best we not pry too closely | 21:19 |
| openstackgerrit | David Stanek proposed openstack/keystone: Moves hacking tests to unit directory https://review.openstack.org/136125 | 21:20 |
| openstackgerrit | David Stanek proposed openstack/keystone: Make the mutable default arg check very strict. https://review.openstack.org/136126 | 21:20 |
| samuelms | ayoung, hm .. | 21:21 |
| samuelms | ayoung, I think one of the best things of that approach is that : instead of defining for what roles a capability is allowed .. | 21:22 |
| samuelms | ayoung, we express that as : what capabilities a role has .. :) | 21:22 |
| ayoung | we need the enumerations of capabilites, yes | 21:22 |
| samuelms | ayoung, and the domain admin has no need to touch the policy FILE | 21:23 |
| ayoung | some of them require no role | 21:23 |
| samuelms | ayoung, and has fine grained access control | 21:23 |
| *** htruta_ has joined #openstack-keystone | 21:23 | |
| samuelms | ayoung, did you take a look at Proposed Change 4. ? | 21:24 |
| ayoung | is that not the current policy language? | 21:24 |
| samuelms | ayoung, sort of .. .just the context constraints .. | 21:25 |
| samuelms | ayoung, like project_id:%(project_id)s that we have today | 21:25 |
| ayoung | samuelms, maybe. I was thinking more like this: | 21:26 |
| ayoung | start with the global policy file | 21:26 |
| ayoung | one by one, replace the complex rules next to each capability with a rule that reflects the lowest level role | 21:26 |
| ayoung | so instead of admin_or_owner it would be Rule:member and that would be | 21:27 |
| ayoung | autogenerated | 21:27 |
| ayoung | so the projects would then each be responsible for keeping up their set of rules | 21:28 |
| ayoung | which would, for the most part be consuming thingslike rule:ROLE_MEMBER | 21:28 |
| ayoung | and they could update what the base level role is that passes a specific policy check | 21:29 |
| *** fifieldt__ has joined #openstack-keystone | 21:31 | |
| samuelms | ayoung, so different domains what tell what rule:ROLE_MEMBER stands for ? | 21:32 |
| ayoung | samuelms, that would be defined by the hierarchical roles | 21:33 |
| ayoung | I don't think that would be per domain | 21:33 |
| *** jorge_munoz has joined #openstack-keystone | 21:34 | |
| samuelms | ayoung, we also can implement hierarchical roles using composition of domain-roles .. u agree? | 21:34 |
| ayoung | nope | 21:34 |
| ayoung | domain roles are different | 21:34 |
| *** fifieldt_ has quit IRC | 21:34 | |
| ayoung | hierarchical ones are going to be global | 21:35 |
| ayoung | domain roles will have to be expanded on the server | 21:35 |
| samuelms | ayoung, but the cloud admin can set default domain-roles .. that can be reused by domains | 21:35 |
| samuelms | ayoung, I think if a put an example showing how the whole thing would work with that proposal could help people to understand that | 21:37 |
| samuelms | ayoung, will add on that etherpad | 21:37 |
| ayoung | yeah | 21:37 |
| dstanek | samuelms: ++ | 21:37 |
| samuelms | ayoung, dstanek :-) | 21:37 |
| samuelms | ayoung gotta go home now (-: almost dinner time here in Brazil | 21:38 |
| ayoung | here, too | 21:38 |
| ayoung | same time zone on the east coast | 21:39 |
| samuelms | 18:39? | 21:39 |
| samuelms | ayoung, ^ in fact we have 4 timezones in Brazil lo | 21:40 |
| samuelms | ayoung, see you | 21:41 |
| ayoung | Ah, only 16:40 here | 21:41 |
| samuelms | ayoung, and you said that it was almost dinner time there where you are .. \o/ | 21:41 |
| ayoung | almost...actually, my wife decided that the Slow cooker needed to be in my office today. I've been hungry for hours | 21:42 |
| samuelms | ayoung, looks like just coffee break time haha | 21:42 |
| samuelms | ayoung, haha .. see you | 21:43 |
| *** samuelms is now known as samuelms-away | 21:43 | |
| *** nkinder has joined #openstack-keystone | 21:46 | |
| *** _cjones_ has joined #openstack-keystone | 21:49 | |
| *** _cjones_ has quit IRC | 21:50 | |
| *** _cjones_ has joined #openstack-keystone | 21:50 | |
| *** edmondsw has quit IRC | 21:54 | |
| openstackgerrit | Jamie Lennox proposed openstack/python-keystoneclient: Make keystoneclient use an adapter https://review.openstack.org/97681 | 22:04 |
| *** radez is now known as radez_g0n3 | 22:12 | |
| *** rwsu has quit IRC | 22:12 | |
| *** RichardRaseley has quit IRC | 22:13 | |
| *** radez_g0n3 is now known as radez | 22:14 | |
| *** Ctina has quit IRC | 22:15 | |
| *** rwsu_ has joined #openstack-keystone | 22:15 | |
| *** stevemar2 has joined #openstack-keystone | 22:17 | |
| *** ChanServ sets mode: +v stevemar2 | 22:17 | |
| *** stevemar has quit IRC | 22:17 | |
| *** stevemar2 has quit IRC | 22:18 | |
| *** stevemar2 has joined #openstack-keystone | 22:19 | |
| *** ChanServ sets mode: +v stevemar2 | 22:19 | |
| *** rwsu_ has quit IRC | 22:19 | |
| *** packet has quit IRC | 22:20 | |
| *** kashyap has joined #openstack-keystone | 22:20 | |
| *** jistr|mtg has quit IRC | 22:27 | |
| *** henrynash has joined #openstack-keystone | 22:34 | |
| *** ChanServ sets mode: +v henrynash | 22:34 | |
| *** NM has joined #openstack-keystone | 22:36 | |
| *** MasterPiece has quit IRC | 22:37 | |
| *** henrynash has quit IRC | 22:39 | |
| *** RichardRaseley has joined #openstack-keystone | 22:43 | |
| *** NM has quit IRC | 22:47 | |
| kashyap | With current DevStack git, I see stack.sh exiting saying 'keystone did not start', when I reconnect to the screen session ('key-access') | 22:51 |
| kashyap | I _guess_ it's because it can't access /var/log/httpd/keystone_access.log? | 22:52 |
| kashyap | Is it correct? It's currently owned by root: | 22:52 |
| kashyap | However, in my another working DevStack setup, I don't notice neither keystone_access.log nor keystone.log in /var/log/httpd. Am I missing something here? | 22:53 |
| * kashyap tried to delete the files keystone_access.log and keystone.log and re-ran ./stack.sh to no avail - the file was recreated with root as the owner | 22:54 | |
| kashyap | Okay, I see a slightly old commit in DevStack git that changed Keystone's access log to /var/log/httpd/keystone_acess.log and that's expected. | 22:57 |
| *** chrisshattuck has joined #openstack-keystone | 23:01 | |
| *** vhoward has left #openstack-keystone | 23:03 | |
| *** RichardRaseley has quit IRC | 23:06 | |
| crinkle | stevemar2: you mentioned that openstackclient has caching capabilities to help speed things up? is that this: https://blueprints.launchpad.net/python-openstackclient/+spec/local-cache | 23:07 |
| *** dtturner has joined #openstack-keystone | 23:08 | |
| stevemar2 | crinkle, that's still to-do, but if you create an interactive session it shouldn't go back to keystone everytime | 23:11 |
| stevemar2 | so if you just type 'openstack' it'll start an interactive session | 23:11 |
| stevemar2 | and you can either type in a bunch of commands or pass in a file (iirc... *cough* dtroyer) | 23:12 |
| *** dims has quit IRC | 23:12 | |
| stevemar2 | crinkle, though marekd|away *really* wants some token caching, so we might have to do that very soon | 23:12 |
| crinkle | hrm I don't really think we can do that programmatically | 23:12 |
| dtroyer | commands are read from stdin, so via output redir, pipe or here document | 23:12 |
| openstackgerrit | Lance Bragstad proposed openstack/keystone-specs: Authenticated Encryption Tokens https://review.openstack.org/130050 | 23:12 |
| crinkle | okay, we might be able to do that | 23:14 |
| crinkle | or maybe just wait till the caching is implemented | 23:14 |
| richm | stevemar2: dtroyer: using the openstack client, how do I list the projects given a user name/id? e.g. the api /v3/users/$id/projects ? | 23:15 |
| richm | where $id is the user's id | 23:15 |
| stevemar2 | richm, there is not command for that in v3 (on the server side) ayoung just said this yesterday actually | 23:16 |
| stevemar2 | no* | 23:16 |
| *** NM has joined #openstack-keystone | 23:16 | |
| *** joesavak has quit IRC | 23:16 | |
| richm | ? | 23:16 |
| stevemar2 | richm, that's kinda like asking ... list all the projects that a user has at least one role for | 23:17 |
| richm | That's odd - because I'm using it and it is working | 23:17 |
| stevemar2 | for 2.0 it should | 23:17 |
| richm | I'm using /v3/users/$id/projects | 23:17 |
| stevemar2 | errr, you are right, i'm forgetting the endpoints | 23:17 |
| richm | and it gives me a list of projects | 23:18 |
| richm | so does that mean, no, you can't do that with the openstack client? | 23:18 |
| stevemar2 | richm, you are correct, thats a bug | 23:20 |
| stevemar2 | can you file it | 23:20 |
| stevemar2 | and i'll toss a patch now | 23:20 |
| stevemar2 | there are too many list permutations :( | 23:20 |
| richm | https://bugs.launchpad.net/python-openstackclient/+bug/1394793 | 23:23 |
| uvirtbot | Launchpad bug 1394793 in python-openstackclient "support the keystone api /v3/users/$userid/projects" [Undecided,New] | 23:23 |
| richm | no worries - I can keep using my json rpc code in the meantime | 23:24 |
| openstackgerrit | Steve Martinelli proposed openstack/keystone: test some websso stuff https://review.openstack.org/136177 | 23:27 |
| openstackgerrit | Brant Knudson proposed openstack/keystone: Fix tests using extension drivers https://review.openstack.org/124603 | 23:28 |
| openstackgerrit | Brant Knudson proposed openstack/keystone: Avoid multiple instances for a provider https://review.openstack.org/124599 | 23:28 |
| stevemar2 | richm, thanks for playing with it - this is exactly what dtroyer and i need, most folks playing around with it and finding bugs, theres only so much the two of us can do :) | 23:30 |
| stevemar2 | crinkle, same goes for you! :) | 23:31 |
| crinkle | :) | 23:31 |
| richm | oh, just wait until we find you some really nasty bugs . . . | 23:32 |
| openstackgerrit | Rodrigo Duarte proposed openstack/keystone: Adds dynamic checking for mapped tokens https://review.openstack.org/133130 | 23:34 |
| rodrigods | stevemar2, dip and protocol approach ^ | 23:34 |
| rodrigods | ayoung, ^ | 23:34 |
| rodrigods | stevemar2, removed the tests, though :x ... Not sure how to test this behavior since the federated_authentication method receives both idp and protocol | 23:35 |
| *** gordc has quit IRC | 23:35 | |
| openstackgerrit | Rodrigo Duarte proposed openstack/keystone: Adds dynamic checking for mapped tokens https://review.openstack.org/133130 | 23:37 |
| stevemar2 | richm, i'll be even happier when that happens | 23:37 |
| openstackgerrit | Brant Knudson proposed openstack/python-keystoneclient: Cleanup exception logging https://review.openstack.org/131295 | 23:39 |
| *** _cjones_ has quit IRC | 23:42 | |
| stevemar2 | richm, https://review.openstack.org/136183 | 23:43 |
| stevemar2 | dtroyer, you too ^ | 23:43 |
| *** _cjones_ has joined #openstack-keystone | 23:45 | |
| openstackgerrit | Rodrigo Duarte proposed openstack/keystone: Adds dynamic checking for mapped tokens https://review.openstack.org/133130 | 23:49 |
| bknudson | so it's been a while since we split out the assignment backend -- | 23:52 |
| bknudson | can we get rid of the code to calculate the default assignment backend? http://git.openstack.org/cgit/openstack/keystone/tree/keystone/assignment/core.py#n68 | 23:53 |
| bknudson | hmm... we never seem to have documented it as deprecated. | 23:54 |
| stevemar2 | richm, http://paste.openstack.org/show/135565/ | 23:59 |
Generated by irclog2html.py 2.14.0 by Marius Gedminas - find it at mg.pov.lt!