[ClusterLabs] Q: Implementing "reload" operation

[Ken Gaillot]

On Thu, 2020-03-19 at 08:28 +0100, Ulrich Windl wrote:
> Hi!
> 
> I have a question on my own RA. Consider the following code:
> 
>     reload)
>         if validate; then
>             status=$OCF_SUCCESS
>             if ! status; then
>                 ocf_log info "$1: restarting $subject"
>                 if start; then
>                     ocf_log debug "$1: restarting $subject"
>                 else
>                     ocf_exit_reason "$1: failed to restart $subject"
>                     status=$OCF_ERR_GENERIC
>                 fi
>             else
>                 ocf_log info "$1: $subject active already"
>             fi
>         else
>             status=$?
>         fi
>         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:

https://github.com/ClusterLabs/OCF-spec/pull/21

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)
> 
> Regards,
> Ulrich
-- 
Ken Gaillot <kgaillot at redhat.com>