On Mon, 7 Nov 2016 12:39:32 -0600 Ken Gaillot <kgail...@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 <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? > > 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, _______________________________________________ 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