qpid-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Chuck Rolke (JIRA)" <j...@apache.org>
Subject [jira] [Created] (DISPATCH-311) [Policy] schema object names could be improved
Date Fri, 06 May 2016 14:44:12 GMT
Chuck Rolke created DISPATCH-311:

             Summary: [Policy] schema object names could be improved
                 Key: DISPATCH-311
                 URL: https://issues.apache.org/jira/browse/DISPATCH-311
             Project: Qpid Dispatch
          Issue Type: Improvement
          Components: Policy Engine
    Affects Versions: 0.6.0
            Reporter: Chuck Rolke
            Assignee: Chuck Rolke

The policy schema suffers from some object naming issues that could
stand cleanup. Some are simple renames to make things consistent
but others require new names that better describe the objects being

Another goal of renaming things is to have the names used in logging
be the same as the names used in configuration.

h2. Concept renames

h3. 'application' -> 'virtualhost'

The application name is derived from the hostname field of the AMQP
Open performative. Calling it an application is fine sometimes but
not always. Referring to the Open.hostname field a virtualhost is
always applicable.

h3. Entity 'policyRuleset' -> 'virtualhostRuleset'

The 'policy ruleset' gathers a bunch of different definitions into
one object. Exactly how the name 'policyRuleset' expresses that is
not clear. If the rules apply to one virtualhost then using the name
'virtualhostRuleset' clarifes the intent.

h3. 'ingress' -> 'remote' host definition attributes

Using 'ingress' to describe anything in a messaging system may be
associated more with messages than it would with remote user
connections. Remote hosts are commonly associated with remote
users and that is what the policy definitions are describing.

h2. Logging

Policy logging will of course make all the changes to reflect
concept renames.

Policy code uses a common format for the log messages when policy
allow or deny decisions are rendered. Here is a log message from
the current code:
POLICY (trace) ALLOW AMQP Begin Session. user: anonymous, hostip:, app: (null)

After renaming things the same log will be:

POLICY (trace) ALLOW AMQP Begin Session. user: anonymous, rhost:, vhost: (null)

h2. Specific proposed renames

h3. Config entities

|| Current       || Proposed          ||
|  policy        |  policy             |
|  policyRuleset |  virtualhostRuleset |

h3. policy entity attributes

|| Current            || Proposed          ||
|  maximumConnections |  maxConnections     |
|  enableAccessRules  |  enableAccessRules  |
|  policyFolder       |  policyDir          |

h3. virtualhostRuleset entity attributes

|| Current                || Proposed                  ||
|  applicationName        |  virtualhostName            |
|  maxConnections         |  maxConnections             |
|  maxConnPerUser         |  maxConnectionsPerUser      |
|  maxConnPerHost         |  maxConnectionsPerHost      |
|  userGroups             |  userGroups                 |
|  ingressHostGroups      |  remoteHostGroups           |
|  ingressPolicies        |  connectionsAllowed         |
|  connectionAllowDefault |  connectionAllowUnknownUser |
|  settings               |  settings                   |

This message was sent by Atlassian JIRA

To unsubscribe, e-mail: dev-unsubscribe@qpid.apache.org
For additional commands, e-mail: dev-help@qpid.apache.org

View raw message