[Pacemaker] (LRMD|PCMK)_MAX_CHILDREN?

[Gao,Yan]

On 09/12/13 15:20, Lars Marowsky-Bree wrote:
> On 2013-09-12T16:56:35, Andrew Beekhof <andrew at beekhof.net> wrote:
> 
>>> The most directly equivalent solution would be to number the per-node
>>> in-flight operations similar to what migration-threshold does. (I think
>>> we can safely continue to treat all resources as equal to start with.)
>> Agreed.  Perhaps even repurpose/rename migration-threshold for the task?
>> Or is this typically set much lower than max children?
> 
> It's typically set lower, because migration speed degrades if the
> network becomes overloaded.
> 
> Also, it's slightly different - "migrate_to" already affects the target
> node, while "migrate_from" still affects the source still.
> 
> I think "migrate" is a valid special case, though I think probably some
> code can be shared - so should the need arise to limit, say, specific
> ops of specific types in the future, it can be added in easily. But I
> really don't want to give them that much rope to start with ;-)
> 
> But we could introduce a name change (while still accepting the existing
> one to remain backwards-compatible) to be more consistent.
> 
> 1. Global property: operations-limit, operations-limit-migrate (alias
> 				      for migration-threshold)
How about to keep it "migration-limit", and name the new property
"actions-limit" -- Other global properties use the term "action". And
since "migration" is known as one type of the "actions".

> 2. Can be overriden via a per-node attribute
Makes sense.

> 2.a. How do to that for operations-limit-migrate? Choose the lower of
>      the two node's values.
Matched actions can be counted against the limits respectively for every
node.
(-- Whether the number of migrate_to/migrate_from actions on this node
is reaching the migration-limit. And whether the number of all the
actions on this node is reaching the actions-limit.)

We don't need to alter it internally I think. One of the limits will
just be reached first.

> 
> Name might be a bit too long. And 2.a. might be overdoing it, but while
> we're at it ... ;-)
> 
> 
> This gives me some pain, though, and I'd welcome advise:
> 
>>> Though the transition from an environment variable to a CIB node
>>> attribute (inherited from a cluster-property, I assume) is going to suck
>>> for the upgrade path :-/
> 
> The DC can't read the environment variables, and it's not so easy to
> feed them back to the DC.
> 
> Auto-tuning has a similar problem. The DC just doesn't know the number
> of cores (and 2 * cores is the natural default, with migration-threshold
> perhaps defaulting to cores / 2). The LRM at least could get that from
> the local system (either /proc or sysconfig).
> 
> Should we default the global value to the numbers from the current DC if
> unset?
Probably it's the only feasible way for now.

Regards,
  Gao,Yan
-- 
Gao,Yan <ygao at suse.com>
Software Engineer
China Server Team, SUSE.