On 05/22/2014 03:55 PM, Alan Conway wrote:
I want to reduce this down to a few configuration primitives so we can
have maximum flexibility with minimum code. I propose the following:

- define configuration as AMQP management actions (messages), define a
   schema
- consider qdrouter.conf files as shorthand for a set of "create"
   actions, so .conf file schema becomes the "create" subset of the
   management schema.
- implement _all_ configuration on the router as executing a management
   action.  E.g. reading a config file is parsing it as "create" actions
   and executing them.
- Get rid of any "startup" assumptions in the config code, so any action
   can be executed by a running router.
- provide a python library with:
   - tools for converting between .conf files, json, python maps and AMQP
     management messages.
   - tools for building configurations programatically (as python maps)
   - agent to send management messages to a remote router

We have most of the pieces:
- tests/system_tests.py: has constructing configs & converting to conf
   files.
- qpid_router_internal/schema, parser: also has conf file conversion &
   construction stuff.
- qdstat tool: has part of the agent functionality (missing the create
   actions)
- router_config.c: has the code to apply configuration, allow it to be
   invoked via management messages, get rid of any startup assumptions.

I would like to refactor the python bits (tests, tools, internals) to
use a commmon library and avoid duplication. I don't think we have the
full management schema written down, I would see that as extending the
existing config schema in python.

Does this seem like a sensible way to go?

Yes, it does to me!


---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]

Reply via email to