[ClusterLabs] Antw: Pacemaker 1.1.16 - Release Candidate 1

[Ken Gaillot]

On 11/07/2016 12:03 PM, Jehan-Guillaume de Rorthais wrote:
> 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?

Corosync 1 does not support certain reliability guarantees required by
the current attrd, so when building against the corosync 1 libraries,
pacemaker will install "legacy" attrd instead. The difference is mainly
that the current attrd can guarantee atomic updates to attribute values.
attrd_updater actually can set permanent attributes when used with
legacy attrd.

> How and where private attributes are stored?

They are kept in memory only, in attrd. Of course, attrd is clustered,
so they are kept in sync across all nodes.

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

Correct. On startup, attrd registers with CIB to be notified of all changes.

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

I'd expect that to work, if the dampening interval was higher than the
lifetime of the cluster being up.

It's also possible to abuse attrd to create a kind of private attribute
by using a node name that doesn't exist and never will. :) This ability
is intentionally allowed, so you can set attributes for nodes that the
current partition isn't aware of, or nodes that are planned to be added
later, but only attributes for known nodes will be written to the CIB.