[ClusterLabs] Best way to create a floating identity file

[Reid Wahl]

If there will only ever be one value (e.g., "httpserver") in the file,
then yet another possibility is to use an ocf:heartbeat:symlink
resource. You could set up a file on each node (say,
/var/local/project/cluster-node-real) with "httpserver" as its
contents. Then create a symlink resource with options
`link=/var/local/project/cluster-node
target=/var/local/project/cluster-node-real`, and add that symlink
resource to your resource group. When it starts, the
/var/local/project/cluster-node file gets created as a symlink to
/var/local/project/cluster-node-real; when the resource stops, the
symlink gets removed.

If I read your email correctly, this would make the cron script work as-is.

On Wed, Dec 16, 2020 at 10:43 AM Ken Gaillot <kgaillot at redhat.com> wrote:
>
> On Wed, 2020-12-16 at 04:46 -0500, Tony Stocker wrote:
> > On Tue, Dec 15, 2020 at 12:29 PM Ken Gaillot <kgaillot at redhat.com>
> > wrote:
> > >
> > > On Tue, 2020-12-15 at 17:02 +0300, Andrei Borzenkov wrote:
> > > > On Tue, Dec 15, 2020 at 4:58 PM Tony Stocker <
> > > > akostocker at gmail.com>
> > > > wrote:
> > > > >
> > >
> > > Just for fun, some other possibilities:
> > >
> > > You could write your script/cron as an OCF RA itself, with an
> > > OCF_CHECK_LEVEL=20 monitor doing the actual work, scheduled to run
> > > at
> > > whatever interval you want (or using time-based rules, enabling it
> > > to
> > > run at a particular time). Then you can colocate it with the
> > > workload
> > > resources.
> > >
> > > Or you could write a systemd timer unit to call your script when
> > > desired, and colocate that with the workload as a systemd resource
> > > in
> > > the cluster.
> > >
> > > Or similar to the crm_resource method, you could colocate an
> > > ocf:pacemaker:attribute resource with the workload, and have your
> > > script check the value of the node attribute (with attrd_updater
> > > -Q) to
> > > know whether to do stuff or not.
> > > --
> >
> > All three options look interesting, but the last one seems the
> > simplest. Looking at the description I'm curious to know what happens
> > with the 'inactive_value' string. Is that put in the 'state' file
> > location whenever a node is not the active one? For example, when I
> > first set up the attribute and it gets put on the active node
> > currently running the resource group with the 'active_value' string,
> > will the current backup node automatically get the same 'state' file
> > created with the 'inactive_value'? Or does that only happen when the
> > resource group is moved?
> >
> > Secondly, does this actually create a file with a plaintext entry
> > matching one of the *_value strings? Or is it simply an empty file
> > with the information stored somewhere in the depths of the PM config?
>
> The state file is just an empty file used to determine whether the
> resource is "running" or not (since there's no actual daemon process
> kept around for it).
>
> > Finally (for the moment), what does the output of 'attrd_updater -Q'
> > look like? I need to figure out how to utilize the output for a cron
> > 'if' statement similar to the previous one:
> >
> > if [ -f /var/local/project/cluster-node ] && [ `cat
> > /var/local/project/cluster-node` = "distroserver" ]; then ...
>
> First you need to know the node attribute name. By default this is
> "opa-" plus the resource ID but you can configure it as a resource
> parameter (name="whatever") if you want something more obvious.
>
> Then you can query the value on the local node with:
>
>     attrd_updater -Q -n <attribute-name>
>
> It's possible the attribute has not been set at all (the node has never
> run the resource). In that case there will be an error return and a
> message on stderr.
>
> If the attribute has been set, the output will look like
>
>     name="attrname" host="nodename" value="1"
>
> Looking at it now, I realize there should be a --quiet option to print
> just the value by itself, but that doesn't exist currently. :) Also, we
> are moving toward having the option of XML output for all tools, which
> is more reliable for parsing by scripts than textual output that can at
> least theoretically change from release to release, but attrd_updater
> hasn't gained that capability yet.
>
> That means a (somewhat uglier) one-liner test would be something like:
>
>   [ "$(attrd_updater -Q -n attrname 2>/dev/null | sed -n -e 's/.* value="\(.*\)".*/\1/p')" = "1" ]
>
> That relies on the fact that the value will be "1" (or whatever you set
> as active_value) only if the attribute resource is currently active on
> the local node. Otherwise it will be "0" (if the resource previously
> ran on the local node but no longer is) or empty (if the resource never
> ran on the local node).
>
> > since the cron script is run on both nodes, I need to know how the
> > output can be used to determine which node will run the necessary
> > commands. If the return values are the same regardless of which node
> > I
> > run attrd_updater on, what do I use to differentiate?
> >
> > Unfortunately right now I don't have a test cluster that I can play
> > with things on, only a 'live' one that we had to rush into service
> > with a bare minimum of testing, so I'm loath to play with things on
> > it.
> >
> > Thanks!
> --
> Ken Gaillot <kgaillot at redhat.com>
>
> _______________________________________________
> Manage your subscription:
> https://lists.clusterlabs.org/mailman/listinfo/users
>
> ClusterLabs home: https://www.clusterlabs.org/
>


-- 
Regards,

Reid Wahl, RHCA
Senior Software Maintenance Engineer, Red Hat
CEE - Platform Support Delivery - ClusterHA