On Tue, Jun 5, 2012 at 10:41 AM, Doug Hellmann <[email protected]>wrote:
> > > On Tue, Jun 5, 2012 at 9:56 AM, Nick Barcet <[email protected]>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. > Two thoughts merged into one sentence there. Need more caffeine. 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. > > >> >> 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 > >
_______________________________________________ Mailing list: https://launchpad.net/~openstack Post to : [email protected] Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
