[ClusterLabs] Antw: Pacemaker 1.1.16 - Release Candidate 1

Mon Nov 7 09:12:04 UTC 2016

On 11/07/2016 08:41 AM, Ulrich Windl wrote:
>>>> 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?

attrd_updater doesn't go for the CIB
 
>
>> 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
>
>
> _______________________________________________
> Users mailing list: Users at clusterlabs.org
> http://clusterlabs.org/mailman/listinfo/users
>
> Project Home: http://www.clusterlabs.org
> Getting started: http://www.clusterlabs.org/doc/Cluster_from_Scratch.pdf
> Bugs: http://bugs.clusterlabs.org