On 11/07/2016 08:41 AM, Ulrich Windl wrote: >>>> Ken Gaillot <kgail...@redhat.com> schrieb am 04.11.2016 um 22:37 in >>>> Nachricht > <27c2ca20-c52c-8fb4-a60f-5ae12f7ff...@redhat.com>: >> On 11/04/2016 02:29 AM, Ulrich Windl wrote: >>>>>> Ken Gaillot <kgail...@redhat.com> schrieb am 03.11.2016 um 17:08 in >>> Nachricht >>> <8af2ff98-05fd-a2c7-f670-58d0ff68e...@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@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 _______________________________________________ Users mailing list: Users@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