qpid-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ted Ross <tr...@redhat.com>
Subject Re: Unified configuration for dispatch
Date Thu, 22 May 2014 16:57:27 GMT


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).

-Ted

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

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


Mime
View raw message