Mailing List Archive: VirtualDomain patch for utilization (was Re: Two git patchs for resource-agents)

Hello,

I'm taking the liberty to split this into two separate sub-threads.

> Hi,
>
> 1. Add a functionality that modifies utilization of resource
> automatically, please see fate 310117.
>
> I added 3 ocf parameters:
> - dynamic_utilization, if set, the utilization parameter of resource
> will be reset if there are
> difference between resource parameters and system parameters when agent
> monitor.
> Otherwise, the resource parameters will be set once when agent start.
> - set_utilization_cpu, enable setting cpu of utilization.
> - set_utilization_memory, enable setting memory of utilization.

Thanks for the contribution. As for the patch to VirtualDomain, I
believe it has excellent merit, however I unfortunately have no time
putting this to any proper testing for at least this week and next, so I
would much appreciate if someone could run this patch through some tests
and provide feedback to this list.

Assuming everything works, I'd still ask Andrew to weigh in on this
before we merge this. The patch highlights an important issue for which
we might want a more generic resolution: a resource agent being able to
report "the resource is currently using this much memory, that much CPU,
that much network traffic, that much disk space", etc. Pacemaker could
then use this dynamic information for resource placement, the way it
already does statically.

Cheers,
Florian

On 2011-07-11T13:57:26, Florian Haas <florian.haas@linbit.com> wrote:

Hi all,

responding to Florian since he already split up the submission into two
distinct parts, which makes a lot of sense. (John, please also remember
that FATE references are meaningless to non-SUSE folks; a bit more
context is usually helpful. Thanks!)

> > 1. Add a functionality that modifies utilization of resource
> > automatically, please see fate 310117.
> >
> > I added 3 ocf parameters:
> > - dynamic_utilization, if set, the utilization parameter of resource
> > will be reset if there are
> > difference between resource parameters and system parameters when agent
> > monitor.

Can this happen with attrd? That would allow us to dampen the
fluctuation of, say, the CPU requirements as the load changes.

> > Otherwise, the resource parameters will be set once when agent start.
> > - set_utilization_cpu, enable setting cpu of utilization.
> > - set_utilization_memory, enable setting memory of utilization.

And I fear "start" is the wrong place to set this; at that time, it's
basically already too late.

The probe (monitor_0) may be the better time to reset these parameters.
Downside is that it would be called on several nodes; but that could be
avoided by "am I running on the lowest nodeid" or something.

More problematic is that the fs that holds the configuration may not be
mounted yet. Hrm.

If we call it in start, and - on noticing that the utilization settings
were initialized or modified - don't go ahead starting the guest,
instead bail out with OCF_NOT_RUNNING, so that the PE gets a chance to
recalculate ...?

Alas, not perfect. Do we need a pre-start notification? A "prepare"
command? Or is the former good enough?

> Assuming everything works, I'd still ask Andrew to weigh in on this
> before we merge this. The patch highlights an important issue for which
> we might want a more generic resolution: a resource agent being able to
> report "the resource is currently using this much memory, that much CPU,
> that much network traffic, that much disk space", etc. Pacemaker could
> then use this dynamic information for resource placement, the way it
> already does statically.

Well, this is similar to crm_master (except that there we have the neat
distinction that we _can_ reasonably call it in start, since promote is
a separate operation).

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

Mailing List Archive

Mailing List Archive

Attached Files: