lmb at suse
Jul 12, 2011, 4:43 AM
Views: 507
Permalink
|
|
Re: AutoSetting (was Re: Two git patchs for resource-agents)
[In reply to]
|
|
On 2011-07-11T13:57:53, Florian Haas <florian.haas [at] linbit> 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 [at] lists
https://lists.linux-foundation.org/mailman/listinfo/ha-wg-technical
|
Re: AutoSetting (was Re: Two git patchs for resource-agents)