[ClusterLabs] Antw: Pacemaker 1.1.16 - Release Candidate 1

[Jehan-Guillaume de Rorthais]

On Mon, 7 Nov 2016 12:39:32 -0600
Ken Gaillot <kgaillot at redhat.com> wrote:

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

OK, I understand now.

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

OK, that was my guess.

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

Interesting.

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

Again, interesting. I'll do some test on my RA as I need clustered private
attributes and was not able to get them under old stack (Debian < 8 or RHEL <
7).

Thank you very much for your answers!

Regards,