On Thu, 2014-05-22 at 16:07 +0000, Gibson, Jack wrote: > 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. >
Are you talking about dispatch config here? I'd be interested to know a bit more about your setup to see if its something that could be made easier by this approach or built right into dispatch. > > > 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] > --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
