On Mon, 7 Nov 2016 09:31:20 -0600 Ken Gaillot <kgail...@redhat.com> wrote:
> 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 why "--private" is not compatible with corosync 1.x as attrd_updater only set "transient" attributes anyway? How and where private attributes are stored? > 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). Interesting, thank you for the clarification. As I understand it, it resumes to: crm_attribute -> CIB <-(poll/notify?) attrd attrd_updater -> attrd -> CIB Just a quick question about this, is it possible to set a "dampening" high enough so attrd never flush it to the CIB (kind of private attribute too)? Regards, _______________________________________________ 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
