Open Stack

Following up on our last meeting and the comments collected on the
mailing list, here is a second version of the proposal for centrally
hosting configuration of meters in ceilometer.

The main idea is that all meters 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.  This proposal is by design
limited to the meter configuration, not to the agent configuration
itself which is still pushed using the global object flags.

Configuration format and content is left to the agent's implementation,
but it is assumed that each meter covered by an agent can be at least
enabled or disabled (and eventually, in a future version of the agents,
set to send information at a meter specific frequency - it is currently
a global value for all meters of an agent).

1/ Configuration is stored for each agent in flat file or DB as follow
+-------------------------------------------------------------------
| Field      | Type     | Note
+-------------------------------------------------------------------
| meter_type | String   | Unique meter type
| conf_vers  | Integer  | Version of the configuration
                        | (simple incremental counter)
| config     | Text     | JSON Configuration info (defined by meter)
+------------+----------+--------------------------------------------+

2/ Config is retreived via the messaging queue upon start of the agent

Request is sent by the agent for each meter upon start to retrieve to
current config version.

If a config is found, it is sent back to the agent, along with conf_vers.
Else the collector creates the record based on default value returned by
the agent/meter plugin installed on the collector, sets conf_vers to 1
and sends back a normal reply.

3/ When the content of the configuration is modified (conf_vers is
updated), a cast is sent to all agents publishing a given meter with the
content of the current configuration for immediate update.

Comments welcome...

Nick




-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 900 bytes
Desc: OpenPGP digital signature
URL: <http://lists.openstack.org/pipermail/openstack/attachments/20120611/87529304/attachment.sig>