[ClusterLabs] Q: Implementing "reload" operation
kgaillot at redhat.com
Thu Mar 19 10:52:31 EDT 2020
On Thu, 2020-03-19 at 08:28 +0100, Ulrich Windl wrote:
> I have a question on my own RA. Consider the following code:
> if validate; then
> if ! status; then
> ocf_log info "$1: restarting $subject"
> if start; then
> ocf_log debug "$1: restarting $subject"
> ocf_exit_reason "$1: failed to restart $subject"
> ocf_log info "$1: $subject active already"
> exit $status
> The crucial point is "status"'s result depends on the current
> parameters: If there was a "reload" due to parameter changes, status
> will have the new parameters and won't see the "old" instance as
> running, thus just starting the new instance. So stopping the old
> instance would require having the old parameters.
> I wonder how the correct code would look like.
Don't implement reload :)
Pacemaker will do a full restart if the parameters change.
If what you're aiming for is deciding reload vs restart based on the
result of a status call, that's not possible with the current code. The
best you could do would be have the reload return an error, in which
case pacemaker will do a full restart, but that will increment the fail
count and show up in status.
> Despite of that the "unique"ness concept has a problem (compare it to
> the primary key of a database table): It's not possible to express
> that a combination of parameters has to be unique (e.g. IP address,
> port number, and protocol). One could merge them into one string, but
> that looks ugly.
Oh yes it has problems :)
There is a perennial effort to update the OCF standard, and we made a
lot of progress a year or so back, but there's always something urgent
that puts it on the back burner yet again. :-(
We had gotten this far:
Unfortunately my backlog of bug investigations/fixes is such that I
don't expect to revisit it anytime soon.
> A similar issue exists for "required"ness of a parameter: Depending
> on another parameter, it could be required, but optional otherwise.
> Again an ugly solution would be to "glue-together" all required
> parameters, but in the end you would end up with one complex
> parameter that is required, and all the parsing and validation
> checking would happen in the RA. An ugly solution!
> (Such issues appear if a resource instance does reflect some kind of
> setting (like a firewall rule) instead of a process that is running)
Ken Gaillot <kgaillot at redhat.com>
More information about the Users