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 <[email protected]> _______________________________________________ Manage your subscription: https://lists.clusterlabs.org/mailman/listinfo/users ClusterLabs home: https://www.clusterlabs.org/
