Unified configuration and management for dispatch.

[Alan Conway <ac...@redhat.com>]

I've been thinking about dispatch configuration, and have a
proposal. Feedback requested!

First a question: Is anybody working on a standard notation for the AMQP
type system?  I need a notation for management events, JSON seems a good
choice but there may be a better one.

There are many possible configuration scenarios including:
- read a simple config file for initial configuration
- deployment: generate custom startup configurations for many routers in
  some topology.
- dynamic provisioning: modify configuration of running routers
- provisioning repository: central repository for configuration
  - push: repository knows router topology and sends configuration to
    routers.
  - pull: routers contact repository and request configuration

A full-service scenario would be: 
- generate and deploy simple config files with router-ids and
  config-repository location.
- routers request initial config from repo.
- Admin can make config changes at repo which are pushed to routers.

We probably don't know all the possible configuration scenarios yet.

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?

Cheers,
Alan.



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