On 11/07/2016 03:47 AM, Klaus Wenninger wrote: > On 11/07/2016 10:26 AM, Jehan-Guillaume de Rorthais wrote: >> On Mon, 7 Nov 2016 10:12:04 +0100 >> Klaus Wenninger <kwenn...@redhat.com> wrote: >> >>> 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>: >> ... >>>>> 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 >> AFAIK, attrd_updater actually goes to the CIB, unless you set "--private" >> since 1.1.13: >> https://github.com/ClusterLabs/pacemaker/blob/master/ChangeLog#L177 > That prevents values being stored in the CIB. attrd_updater should > always talk to attrd as I got it ...
It's a bit confusing: Both crm_attribute and attrd_updater will ultimately affect both attrd and the CIB in most cases, but *how* they do so is different. crm_attribute modifies the CIB, and lets attrd pick up the change from there; attrd_updater notifies attrd, and lets attrd modify the CIB. The difference is subtle. With corosync 2, attrd only modifies "transient" node attributes (which stay in effect till the next reboot), not "permanent" attributes. So crm_attribute must be used if you want to set a permanent attribute. crm_attribute also has the ability to modify cluster properties and resource defaults, as well as node attributes. On the other hand, by contacting attrd directly, attrd_updater can change an attribute's "dampening" (how often it is flushed to the CIB), and it can (as mentioned above) set "private" attributes that are never written to the CIB (and thus never cause the cluster to re-calculate resource placement). _______________________________________________ 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
