qpid-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From c...@apache.org
Subject qpid-dispatch git commit: Add policy to-do list.
Date Fri, 01 Apr 2016 20:35:53 GMT
Repository: qpid-dispatch
Updated Branches:
  refs/heads/crolke-DISPATCH-188-1 3f42fa4fb -> d90348f8e

Add policy to-do list.

Project: http://git-wip-us.apache.org/repos/asf/qpid-dispatch/repo
Commit: http://git-wip-us.apache.org/repos/asf/qpid-dispatch/commit/d90348f8
Tree: http://git-wip-us.apache.org/repos/asf/qpid-dispatch/tree/d90348f8
Diff: http://git-wip-us.apache.org/repos/asf/qpid-dispatch/diff/d90348f8

Branch: refs/heads/crolke-DISPATCH-188-1
Commit: d90348f8efc0650b53adfb91227d7b3b9d65633b
Parents: 3f42fa4
Author: Chug <chug@apache.org>
Authored: Fri Apr 1 16:35:28 2016 -0400
Committer: Chug <chug@apache.org>
Committed: Fri Apr 1 16:35:28 2016 -0400

 doc/notes/qdr-policy-todo.md | 56 +++++++++++++++++++++++++++++++++++++++
 1 file changed, 56 insertions(+)

diff --git a/doc/notes/qdr-policy-todo.md b/doc/notes/qdr-policy-todo.md
new file mode 100644
index 0000000..b765121
--- /dev/null
+++ b/doc/notes/qdr-policy-todo.md
@@ -0,0 +1,56 @@
+.. Licensed to the Apache Software Foundation (ASF) under one
+   or more contributor license agreements.  See the NOTICE file
+   distributed with this work for additional information
+   regarding copyright ownership.  The ASF licenses this file
+   to you under the Apache License, Version 2.0 (the
+   "License"); you may not use this file except in compliance
+   with the License.  You may obtain a copy of the License at
+     http://www.apache.org/licenses/LICENSE-2.0
+   Unless required by applicable law or agreed to in writing,
+   software distributed under the License is distributed on an
+   KIND, either express or implied.  See the License for the
+   specific language governing permissions and limitations
+   under the License.
+Policy TODO List
+# Ruleset schema
+- Should relesets be able to share definitions? The rulesets are self contained. Rulesets
uniquely define policy for one application. Redefinition of a ruleset will have no effect
on other applications. The implication is that if one ruleset has a large definition of users,
user groups, or policy settings then these definitions can not be shared with other rulesets
and *they must be repeated*.
+- Are the policy settings adequate? Do they provide enough controls over AMQP?
+    - One place this is an issue is with management. The policy can allow or deny access
to source/target **$management**. But once that access is granted the user can do anything
to any object on any router. Finer control over management is desirable.
+- Are white list (allow rules only) rules enough? Having only white list rules makes them
easier to comprehend and easier to generate. The code to process them is also easier to write
and to test.
+- Policy adds map schema objects. The schema processor verifies that the objects are maps
but does not look into the map to see if it makes any sense for policy. Policy code thoroughly
validates the maps but it would be better if the maps were specified in the management schema
and verified there.
+    - Schema map objects forced modifying the config processor to allow .json files in addition
to the existing .conf files.
+# Policy service
+- Current policy is local only. Certainly policy rulesets are manageable entities and may
be loaded through normal management channels. There is an opportunity to develop a policy
service where routers could open a channel to **$policy** for user lookup and policy settings.
Then each router would not need to maintain local policy in its current form.
+# Implementation
+- Error log levels need to be rationalized now that the code is maturing.
+- Locking. Needs review.
+- Memory pool for policy settings. Uses alloc/free for each connection for small setting
structs. Low priority.
+- Add default 'default settings'. In the absence of policy settings or in the presence of
policies without some settings dispatch router needs to insert hard coded values into AMQP
fields. Where are these defined?
+# Usual suspects
+- Improve documentation. Make is useful as a sales tool.
+- Improve self tests. Lead by example.

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

View raw message