Hello,
On 2011-07-11 13:01, John Shi wrote:
> 2. Create a new agent: AutoSetting, it detects system parameters, such
> as cpu, memory, and put them into
> utilization of node, it runs on every node as clone resource. please
> see fate 310115.
> I implemented 3 ocf parameters:
> - dynamic
> - utilization_cpu
> - utilization_memory
The AutoSetting patch I am not so sure of, to be honest. As with
VirtualDomain, I believe we could use a more generic solution here.
Here's my suggestion: Think of a resource agent named, say "attribute",
with the following configuration parameters:
- name (required)
- value (optional)
- value_hook (optional)
"name" would be the name of a transitional node attribute that the agent
manages.
"value" would be a static value assigned to the attribute (just for
completeness' sake). For example, the agent might be cloned, and might
set the attribute "foo" to "bar" on all nodes where a clone instance
runs. You obviously realize that this is a contrived example, but it may
be useful nonetheless.
"value_hook" could call out to a script that is expected to output a
value, which is then applied to the attribute. This script would be
called during the recurring monitor operation, so the attribute is
continuously updated with current values.
The agent would set the attribute on resource (instance) start, and
remove it on resource (instance) stop.
Just in case the idea of calling out to an arbitrary script from a
resource agent makes you cringe: it's also conceivable that this
"agent" would merely be a collection of functions that a real agent,
potentially with a hard-coded value_hook, can source.
Your thoughts on this would be much appreciated.
Cheers,
Florian
On 2011-07-11 13:01, John Shi wrote:
> 2. Create a new agent: AutoSetting, it detects system parameters, such
> as cpu, memory, and put them into
> utilization of node, it runs on every node as clone resource. please
> see fate 310115.
> I implemented 3 ocf parameters:
> - dynamic
> - utilization_cpu
> - utilization_memory
The AutoSetting patch I am not so sure of, to be honest. As with
VirtualDomain, I believe we could use a more generic solution here.
Here's my suggestion: Think of a resource agent named, say "attribute",
with the following configuration parameters:
- name (required)
- value (optional)
- value_hook (optional)
"name" would be the name of a transitional node attribute that the agent
manages.
"value" would be a static value assigned to the attribute (just for
completeness' sake). For example, the agent might be cloned, and might
set the attribute "foo" to "bar" on all nodes where a clone instance
runs. You obviously realize that this is a contrived example, but it may
be useful nonetheless.
"value_hook" could call out to a script that is expected to output a
value, which is then applied to the attribute. This script would be
called during the recurring monitor operation, so the attribute is
continuously updated with current values.
The agent would set the attribute on resource (instance) start, and
remove it on resource (instance) stop.
Just in case the idea of calling out to an arbitrary script from a
resource agent makes you cringe: it's also conceivable that this
"agent" would merely be a collection of functions that a real agent,
potentially with a hard-coded value_hook, can source.
Your thoughts on this would be much appreciated.
Cheers,
Florian