ClusterLabs
Fix ACL rule mapping to xpaths
From a discussion upstream:
https://github.com/ClusterLabs/pacemaker/commit/94d528b223856c5f43a65a487a5f2d362770f3a3#commitcomment-10012335
We should probably rewrite the ACL code to always generate xpaths as @beekhof suggests.
We should probably rewrite the ACL code to always generate xpaths as @beekhof suggests.
All acl_shortcuts expand to xpaths. Or do you mean something else?
Anyway, I'd say that it is still better to have shorter and more readable CIBs and let the pacemaker do the dirty work of translating stuff into xpaths. I'm not sure if we show shortcuts when parsing the ACL rules?
No, I mean not to translate anything to the object-type or attribute attributes on acl_permission, and instead translate directly to xpath.
On Wed, May 06, 2015 at 10:19:11AM -0700, Kristoffer Grönlund wrote:
No, I mean not to translate anything to the
object-typeorattributeattributes on acl_permission, and instead translate directly toxpath.
I guess then that this is about the new ACL stuff? Don't know anything about what the changes comprise.
Are acl_shortcuts obsolete in v1.1.12?
I'd just like to stress again that it is in general easier for users (i.e. people who may not be as technically savvy as some of us are) to comprehend concepts (or objects, if you will) as names rather then the same concept spelled out as xpath. The latter typically involve various CIB attributes/elements which also may not be easy to follow. After all, one of the major roles of crmsh is to help hide the arcana :)
I guess then that this is about the new ACL stuff? Don't know anything about what the changes comprise. Are acl_shortcuts obsolete in v1.1.12?
Yes, the only tag that is valid in 1.1.12 is acl_permission.
I'd just like to stress again that it is in general easier for users (i.e. people who may not be as technically savvy as some of us are) to comprehend concepts (or objects, if you will) as names rather then the same concept spelled out as xpath. The latter typically involve various CIB attributes/elements which also may not be easy to follow. After all, one of the major roles of crmsh is to help hide the arcana :)
Right, so that's why we provide a more friendly interface on top of the XML to begin with. But that also means that it shouldn't really matter what the XML we generate looks like, we'll just keep providing an understandable interface to it.
I guess one thing we could do is generate a description for the ACL rule that expresses what it means in a more human-friendly way?
On the flip-side, I have to say that for me it is easier to understand an xpath string than to figure out what a particular combination of object-type and attribute settings mean. :)
On Thu, May 07, 2015 at 02:36:16AM -0700, Kristoffer Grönlund wrote:
Right, so that's why we provide a more friendly interface on top of the XML to begin with. But that also means that it shouldn't really matter what the XML we generate looks like, we'll just keep providing an understandable interface to it.
It does matter when we cannot show the original input. I'm not sure what's the situation re acls in that respect.
I guess one thing we could do is generate a description for the ACL rule that expresses what it means in a more human-friendly way?
That'd be great.
On the flip-side, I have to say that for me it is easier to understand an xpath string than to figure out what a particular combination of object-type and attribute settings mean. :)
Well, I assume that you're a bit of an out of ordinary user in that respect :) However, I cannot really say anything without seeing some examples first.