<br><br><div class="gmail_quote">On Tue, Jun 5, 2012 at 10:41 AM, Doug Hellmann <span dir="ltr"><<a href="mailto:doug.hellmann@dreamhost.com" target="_blank">doug.hellmann@dreamhost.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br><br><div class="gmail_quote"><div class="im">On Tue, Jun 5, 2012 at 9:56 AM, Nick Barcet <span dir="ltr"><<a href="mailto:nick.barcet@canonical.com" target="_blank">nick.barcet@canonical.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Following up on our last meeting, here is a proposal for centrally<br>
hosting configuration of agents in ceilometer.<br>
<br>
The main idea is that all agents of a given type should be sending<br>
similarly formatted information in order for the information to be<br>
usable, hence the need to ensure that configuration info is centrally<br>
stored and retrieved. This would rule out, in my mind, the idea that we<br>
could use the global flags object, as distribution of the configuration<br>
file is left to the cloud implementor and does not lend for easy and<br>
synchronized updates of agent config.<br>
<br>
Configuration format and content is left to the agent's implementation,<br>
but it is assumed that each meter covered by an agent can be :<br>
* enabled or disabled<br>
* set to send information at a specified interval.<br></blockquote><div><br></div></div><div>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.)</div>
<div class="im">
<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
1/ Configuration is stored for each agent in the database as follow<br>
+-------------------------------------------------------------------+<br>
| Field | Type | Note |<br>
+-------------------------------------------------------------------+<br>
| AgentType | String | Unique agent type |<br>
| ConfVers | Integer | Version of the configuration |<br>
| Config | Text | JSON Configuration info (defined by agent) |<br>
+-----------+----------+--------------------------------------------+<br>
<br>
2/ Config is retreived via the messaging queue upon boot once a day<br>
(this should be defined in the global flags object) to check if the<br>
config has changed.<br></blockquote><div><br></div></div><div>Updating the config once a day is not going to be enough in an environment with a lot of compute nodes.</div></div></blockquote><div><br></div><div>Two thoughts merged into one sentence there. Need more caffeine. </div>
<div><br>What I was trying to say, was that updating the config once a day might not be enough, and in environments with a lot of compute nodes going around to manually restart the services each time the config changes will be a pain. See below for more discussion of pushing config settings out.</div>
<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="gmail_quote"><div class="im"><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
Request sent by the agent upon boot and :<br>
<br>
'reply_to': 'get_config_data',<br>
'correlation_id': xxxxx<br>
'version': '1.0',<br>
'args': {'data': {<br>
'AgentType': agent.type,<br>
'CurrentVersion': agent.version,<br>
'ConfigDefault': agent.default,<br>
},<br>
},<br></blockquote><div><br></div></div><div>Is this a standard OpenStack RPC call?</div><div class="im"><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
Where ConfigDefault are the "sane" default proposed by the agent authors.<br></blockquote><div><br></div></div><div>Why is the agent proposing default settings?</div><div class="im"><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
If no config record is found the collector creates the record, sets<br>
ConfVers to 1 and sends back a normal reply.<br>
<br>
Reply sent by the collector:<br>
'correlation_id': xxxxx<br>
'version': '1.0',<br></blockquote><div><br></div></div><div>Do we need minor versions for the config settings, or are those simple sequence numbers to track which settings are the "most current"?</div>
<div class="im">
<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
'args': {'data': {<br>
'Result': result.code,<br>
'ConfVers': ConfVers,<br>
'Config': Config,<br>
},<br>
},<br>
}<br>
<br>
Result is set as follow:<br>
200 -> Config was retrieved successfully<br>
201 -> Config was created based on received default (Config is empty)<br>
304 -> Config version is identical to CurrentVersion (Config is empty)<br></blockquote><div><br></div></div><div>Why does the agent need to know the difference between those? Shouldn't it simply use the settings it is given?</div>
<div class="im">
<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
This leaves open the question of having some UI to change the config,<br>
but I thing we can live with manual updating of the records for the time<br>
being.<br></blockquote><div><div><br></div></div></div><div>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).</div>
<div><br>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.</div>
<div><br></div><div>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.</div>
<span class="HOEnZb"><font color="#888888">
<div><br></div><div>Doug</div><div><br></div></font></span></div>
</blockquote></div><br>