[GSoC 2012, PyAgent] Changes in the configuration of PyAgent

Krzysztof Kwaƛniewski krzykwas at gmail.com
Mon Jul 16 22:47:18 UTC 2012


Hi!

     There are two ideas for future development of PyAgent in terms of 
its configuration. I would like to ask you for your opinions on that.
     The first idea is connected with reducing the flexibility that the 
agent allows for now. The rationale for this is that it can be too 
complicated for a regular user to get accustomed to all the 
possibilities that the agent can provide. Many people won't like to 
spend much time on learning how to configure the agent. Meanwhile much 
of the functionality that the agent will provide won't be used in fact. 
And also the easier the configuration, the less errors will be made.
     Let's assume you just have one source server identified with an 
URI, a name of its resource, an index for choosing one of the instances 
of the resource (for instance the second CPU out of ten) and the 
property of the resource (for a CPU - a clock rate, a load and so on). 
Then you also have the same for the destination resource. You can 
control an update interval for each mapping separately - it is an amount 
of time between two consecutive queries for data at its source - when 
reporting to RHQ, it is the one to decide on the update interval value.
Will you need a possibility of:
1) mapping one resource in the source server (CIM) to many destination 
servers (RHQ)?
2) getting data from multiple source servers (CIM) with a single 
instance of PyAgent?
3) sending gathered data to multiple destination servers (RHQ) with a 
single instance of PyAgent?
4) easily adapting PyAgent to get data from another kind of source (not 
CIM)?
5) easily adapting PyAgent to send data to another kind of destination 
(not RHQ, for instance a file)?
6) configuring the update interval for each single measurement 
separately? Generally RHQ is responsible for managing such an update 
interval, but maybe not all the destination servers will be RHQ instances?
If you don't need some of those options, the configuration may be much 
simpler than it is now.
     The other idea is a completely different approach to the problem of 
having too complicated configuration. For that I can prepare an 
interactive generator that will ask a set of questions and then prepare 
an xml file. My opinion is that it will be time-consuming and error 
prone to prepare a configuration file this way, but maybe you like this 
idea? If yes, what should I especially take into account when preparing 
the generator? Do you have any advice for me?


                               Cheers

                             Krzysiek


More information about the rhq-devel mailing list