On Thu, 2014-05-22 at 12:57 -0400, Ted Ross wrote: > > On 05/22/2014 12:22 PM, Gordon Sim wrote: > > 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! > > I like it too. > > Getting rid of _all_ the startup assumptions may be tricky, but there's > value in trying it. For example, the configuration currently controls > the number of threads that are started in the server. Perhaps this > needs to be made dynamically settable (i.e. start with one thread, get > 'configured' later to run multiple threads).
Agreed, I think the router and container sections might be special cases. However I'd like to make the special cases as small as possible - ideally 100% defaulted so its possible to start up something useful with no config at all. And even if we need some minimal config to get started (e.g. a defaulted router & container) I think it should still be possible to update that configuration via management, e.g. change the number of threads or the router-id. --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
