openstack team mailing list archive

[Nick Barcet <nick.barcet@xxxxxxxxxxxxx>]

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.

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.

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,
               },
            },

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

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',
    '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)

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.

Comments welcome...

Nick

Attachment: signature.asc
Description: OpenPGP digital signature