[ClusterLabs] Antw: Pacemaker 1.1.16 - Release Candidate 1

[Ulrich Windl]

>>> Ken Gaillot <kgaillot at redhat.com> schrieb am 04.11.2016 um 22:37 in Nachricht
<27c2ca20-c52c-8fb4-a60f-5ae12f7ffc64 at redhat.com>:
> On 11/04/2016 02:29 AM, Ulrich Windl wrote:
>>>>> Ken Gaillot <kgaillot at redhat.com> schrieb am 03.11.2016 um 17:08 in
>> Nachricht
>> <8af2ff98-05fd-a2c7-f670-58d0ff68ee55 at redhat.com>:
>>> ClusterLabs is happy to announce the first release candidate for
>>> Pacemaker version 1.1.16. Source code is available at:
>>>
>>> https://github.com/ClusterLabs/pacemaker/releases/tag/Pacemaker-1.1.16-rc1 
>>>
>>> The most significant enhancements in this release are:
>>>
>>> * rsc-pattern may now be used instead of rsc in location constraints, to
>>> allow a single location constraint to apply to all resources whose names
>>> match a regular expression. Sed-like %0 - %9 backreferences let
>>> submatches be used in node attribute names in rules.
>>>
>>> * The new ocf:pacemaker:attribute resource agent sets a node attribute
>>> according to whether the resource is running or stopped. This may be
>>> useful in combination with attribute-based rules to model dependencies
>>> that simple constraints can't handle.
>> 
>> I don't quite understand this: Isn't the state of a resource in the CIB 
> status
>> section anyway? If not, why not add it? So it would be readily available for
>> anyone (rules, constraints, etc.).
> 
> This (hopefully) lets you model more complicated relationships.
> 
> For example, someone recently asked whether they could make an ordering
> constraint apply only at "start-up" -- the first time resource A starts,
> it does some initialization that B needs, but once that's done, B can be
> independent of A.

Is "at start-up" before start of the resource, after start of the resource, or parallel to the start of the resource ;-)
Probably a "hook" in the corresponding RA is the better approach, unless you can really model all of the above.

> 
> For that case, you could group A with an ocf:pacemaker:attribute
> resource. The important part is that the attribute is not set if A has
> never run on a node. So, you can make a rule that B can run only where
> the attribute is set, regardless of the value -- even if A is later
> stopped, the attribute will still be set.

If a resource is not running on a node,, it is "stopped"; isn't it?

> 
> Another possible use would be for a cron that needs to know whether a
> particular resource is running, and an attribute query is quicker and
> easier than something like parsing crm_mon output or probing the service.

crm_mon reads parts of the CIB; crm_attribute also does, I guess, so besides of lacking options and inefficient implementation, why should one be faster than the other?

> 
> It's all theoretical at this point, and I'm not entirely sure those
> examples would be useful :) but I wanted to make the agent available for
> people to experiment with.

A good product manager should resist the attempt to provide any feature the customers ask for, avoiding bloat-ware. That is to protect the customer from their own bad decisions. In most cases there is a better, more universal solution to the specific problem.


> 
>>> * Pacemaker's existing "node health" feature allows resources to move
>>> off nodes that become unhealthy. Now, when using
>>> node-health-strategy=progressive, a new cluster property
>>> node-health-base will be used as the initial health score of newly
>>> joined nodes (defaulting to 0, which is the previous behavior). This
>>> allows cloned and multistate resource instances to start on a node even
>>> if it has some "yellow" health attributes.
>> 
>> So the node health is more or less a "node score"? I don't understand the 
> last
>> sentence. Maybe give an example?
> 
> Yes, node health is a score that's added when deciding where to place a
> resource. It does get complicated ...
> 
> Node health monitoring is optional, and off by default.
> 
> Node health attributes are set to red, yellow or green (outside
> pacemaker itself -- either by a resource agent, or some external
> process). As an example, let's say we have three node health attributes
> for CPU usage, CPU temperature, and SMART error count.
> 
> With a progressive strategy, red and yellow are assigned some negative
> score, and green is 0. In our example, let's say yellow gets a -10 score.
> 
> If any of our attributes are yellow, resources will avoid the node
> (unless they have higher positive scores from something like stickiness
> or a location constraint).
> 

I understood so far.

> Normally, this is what you want, but if your resources are cloned on all
> nodes, maybe you don't care if some attributes are yellow. In that case,
> you can set node-health-base=20, so even if two attributes are yellow,
> it won't prevent resources from running (20 + -10 + -10 = 0).

I don't understand that: "node-health-base" is a global setting, but what you want is an exception for some specific (clone) resource.
To me the more obvious solution would be to provide an exception rule for the resource, not a global setting for the node.

[...saving independent bits from being retransmitted...]

Ulrich