[ClusterLabs] Antw: Pacemaker 1.1.16 - Release Candidate 1

[Jehan-Guillaume de Rorthais]

On Mon, 7 Nov 2016 09:31:20 -0600
Ken Gaillot <kgaillot at 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 <kwenning at redhat.com> wrote:
> >>  
> >>> 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>:    
> >> ...  
> >>>>> 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,