Open Stack

On Tue, Jun 5, 2012 at 9:56 AM, Nick Barcet <nick.barcet at canonical.com>wrote:

> Following up on our last meeting, here is a proposal for centrally
> hosting configuration of agents in ceilometer.
>
> The main idea is that all agents of a given type should be sending
> similarly formatted information in order for the information to be
> usable, hence the need to ensure that configuration info is centrally
> stored and retrieved.  This would rule out, in my mind, the idea that we
> could use the global flags object, as distribution of the configuration
> file is left to the cloud implementor and does not lend for easy and
> synchronized updates of agent config.
>
> Configuration format and content is left to the agent's implementation,
> but it is assumed that each meter covered by an agent can be :
>  * enabled or disabled
>  * set to send information at a specified interval.
>

Right now we only have one interval for all polling. Do you think we need
to add support for polling different values at different intervals? Do we
need other per-agent settings, or are all of the settings the same for all
agents? (I had assumed the latter would be all we needed.)


>
> 1/ Configuration is stored for each agent in the database as follow
> +-------------------------------------------------------------------+
> | Field     | Type     | Note                                       |
> +-------------------------------------------------------------------+
> | AgentType | String   | Unique agent type                          |
> | ConfVers  | Integer  | Version of the configuration               |
> | Config    | Text     | JSON Configuration info (defined by agent) |
> +-----------+----------+--------------------------------------------+
>
> 2/ Config is retreived via the messaging queue upon boot once a day
> (this should be defined in the global flags object) to check if the
> config has changed.
>

Updating the config once a day is not going to be enough in an environment
with a lot of compute nodes.


>
> Request sent by the agent upon boot and :
>
>    'reply_to': 'get_config_data',
>    'correlation_id': xxxxx
>    'version': '1.0',
>    'args': {'data': {
>               'AgentType': agent.type,
>               'CurrentVersion': agent.version,
>               'ConfigDefault': agent.default,
>               },
>            },
>

Is this a standard OpenStack RPC call?


>
> Where ConfigDefault are the "sane" default proposed by the agent authors.
>

Why is the agent proposing default settings?


>
> If no config record is found the collector creates the record, sets
> ConfVers to 1 and sends back a normal reply.
>
> Reply sent by the collector:
>    'correlation_id': xxxxx
>    'version': '1.0',
>

Do we need minor versions for the config settings, or are those simple
sequence numbers to track which settings are the "most current"?


>    'args': {'data': {
>               'Result': result.code,
>               'ConfVers': ConfVers,
>               'Config': Config,
>               },
>            },
>    }
>
> Result is set as follow:
>    200  -> Config was retrieved successfully
>    201  -> Config was created based on received default (Config is empty)
>    304  -> Config version is identical to CurrentVersion (Config is empty)
>

Why does the agent need to know the difference between those? Shouldn't it
simply use the settings it is given?


>
> This leaves open the question of having some UI to change the config,
> but I thing we can live with manual updating of the records for the time
> being.
>

Since we're using the service and RPC frameworks from nova elsewhere, we
have the option of issuing commands to all of the agents from a central
server. That would let us, for example, use a cast() call to push a new
configuration out to all of the agents at once, on demand (from a command
line program, for example).

I don't see the need for storing the configuration in the database. It
seems just as easy to have a configuration file on the central server. The
collector could read the file each time it is asked for the agent
configuration, and the command line program that pushes config changes out
could do the same.

Have you given any thought to distributing the secret value used for
signing incoming messages? A central configuration authority does not give
us a secure way to deliver secrets like that. If anyone with access to the
message queue can retrieve the key by sending RPC requests, we might as
well not sign the messages.

Doug
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack/attachments/20120605/3e40a592/attachment.html>