Mailing List Archive

AutoSetting (was Re: Two git patchs for resource-agents)
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
Re: AutoSetting (was Re: Two git patchs for resource-agents) [ In reply to ]
On 2011-07-11T13:57:53, Florian Haas <florian.haas@linbit.com> wrote:

> > 2. Create a new agent: AutoSetting, it detects system parameters, such
> > as cpu, memory, and put them into

I think the name could be improved. How about folding this into the
SystemHealth agent?

> > 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.

Horrible to configure, to be frank. I can see that as an additional hook
mechanism, but most people want CPU and memory capacity (perhaps network
and disk, one day); having standard short-cuts for these is
unavoidable.

> 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.

Well, a library of capacity functions to populate is obviously a good
idea.

The SystemHealth RA could then eventually advertise a list of them to
select from + activate, once we get that capability. For the time being,
hard-coding both memory and cpu fields makes sense.


Regards,
Lars

--
Architect Storage/HA, OPS Engineering, Novell, Inc.
SUSE LINUX Products GmbH, GF: Jeff Hawn, Jennifer Guild, Felix Imend├Ârffer, HRB 21284 (AG N├╝rnberg)
"Experience is the name everyone gives to their mistakes." -- Oscar Wilde

_______________________________________________
ha-wg-technical mailing list
ha-wg-technical@lists.linux-foundation.org
https://lists.linux-foundation.org/mailman/listinfo/ha-wg-technical