[ClusterLabs] Antw: Pacemaker 1.1.16 - Release Candidate 1

Fri Nov 4 21:37:52 UTC 2016

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.

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.

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.

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.

>> * 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).

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).

There is nothing in node-health-base that is specific to clones; that's
just the most likely use case.

>> * Previously, the OCF_RESKEY_CRM_meta_notify_active_* variables were not
>> properly passed to multistate resources with notification enabled. This
>> has been fixed. To help resource agents detect when the fix is
>> available, the CRM feature set has been incremented. (Whenever the
>> feature set changes, mixed-version clusters are supported only during
>> rolling upgrades -- nodes with an older version will not be allowed to
>> rejoin once they shut down.)
> 
> Where can I find a description of current "CRM feature sets"?
>
> Ulrich
> 
>>
>> * Watchdog-based fencing using sbd now works on remote nodes.
>>
>> * The build process now takes advantage of various compiler features
>> (RELRO, PIE, as-needed linking, etc.) that enhance security and start-up
>> performance. See the "Hardening flags" comments in the configure.ac file
>> for more details.
>>
>> * Python 3 compatibility: The Pacemaker project now targets
>> compatibility with both python 2 (versions 2.6 and later) and python 3
>> (versions 3.2 and later). All of the project's python code now meets
>> this target, with the exception of CTS, which is still python 2 only.
>>
>> * The Pacemaker coding guidelines have been replaced by a more
>> comprehensive addition to the documentation set, "Pacemaker
>> Development". It is intended for developers working on the Pacemaker
>> code base itself, rather than external code such as resource agents. A
>> copy is viewable at
>> http://clusterlabs.org/doc/en-US/Pacemaker/1.1-pcs/html-single/Pacemaker_Dev
> 
>> elopment/index.html
>>
>> As usual, the release includes many bugfixes, including a fix for a
>> serious security vulnerability (CVE-2016-7035). For a more detailed list
>> of changes, see the change log:
>>
>> https://github.com/ClusterLabs/pacemaker/blob/1.1/ChangeLog 
>>
>> Everyone is encouraged to download, compile and test the new release. We
>> do many regression tests and simulations, but we can't cover all
>> possible use cases, so your feedback is important and appreciated. Due
>> to the security fix, I intend to keep this release cycle short, so quick
>> testing feedback is especially appreciated.
>>
>> Many thanks to all contributors of source code to this release,
>> including Andrew Beekhof, Bin Liu, Christian Schneider, Christoph Berg,
>> David Shane Holden, Ferenc Wágner, Yan Gao, Hideo Yamauchi, Jan Pokorný,
>> Ken Gaillot, Klaus Wenninger, Kostiantyn Ponomarenko, Kristoffer
>> Grönlund, Lars Ellenberg, Masatake Yamato, Michal Koutný, Nakahira
>> Kazutomo, Nate Clark, Nishanth Aravamudan, Oyvind Albrigtsen, Ruben
>> Kerkhof, Tim Bishop, Vladislav Bogdanov and Yusuke Iida. Apologies if I
>> have overlooked anyone.
>> -- 
>> Ken Gaillot <kgaillot at redhat.com>