Sounds like an interesting idea, think the users of dispatch would be greatly interested. Right now, we are working on managing our lab instances with JSON schema and pushing config out to zookeeper with local agents pushing the config manually to each router.
Jack Gibson eBay - Global Platform Services On 5/22/14, 9:55 AM, "Alan Conway" <[email protected]> wrote: >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: [email protected] >For additional commands, e-mail: [email protected] > --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
