[OCF] Re: [Linux-ha-dev] Adding "reload" to the OCF specification

[Lars Marowsky-Bree]

On 2006-06-15T08:56:00, Alan Robertson <alanr at unix.sh> wrote:

> Many LSB init scripts implement a 'reload' action which permits them to 
> reread their configurations without interrupting service.
> 
> By design, OCF spec is upwards-compatible with the LSB.
> 
> I think it would be good to specifically add the reload operation to the 
> OCF spec.
> 
> Saying something like this:
> ----------------------------------------------------------------------
> The reload operation is an optional operation which can be supported by 
> OCF resource agents.  This operation will cause the resource to examine 
> its parameters and its configuration files, and continue running these 
> new configuration values, without interrupting service in a way which is 
> visible to resources which depend on it.
> 
> If an OCF resource agent wishes to support the reload operation, it is 
> required to list it in the <operations> section of the metadata given by 
> the meta-data operation.
> 
> Even though a resource supports a reload operation, a conforming cluster 
> manager need not make use of it.  Of course, if it does, then service 
> updates can be made with fewer service interruptions, so this is likely 
> to be seen as a desirable feature.
> ----------------------------------------------------------------------
> 
> And as to whether there are resource agents which could make use of this 
> feature - the answer is yes.  I have a customer who would like such a 
> capability today.  At the moment, they go far out of their way to work 
> around not having it.
> 
> As written, this is optional for both resource agents and cluster 
> managers, and it seems like a reasonable addition to the OCF spec.
> 
> My guess is that this would be an easy addition for many cluster 
> managers to support.  Of course, nothing is impossible to he who doesn't 
> have to do it.


1. The administrator of course may not change the parameters so much
that the RA can no longer identify the already running resource
instance. (Do we need to provide hints in the meta data to identify
which parameters are safe to change and which are not?)

2. If reload fails, should the resource be treated as failed, or merely
the reload? (I'm inclined towards the first one, it's easier to code I
think ;-)


3.  You say "without this being visible to the resources depending on
it", but, then, if it is not visible at _all_ (ie, _absolutely_ no
observable change _anywhere_), there wouldn't be a point in reloading
it, would there?

I think in the interest of purity & simplicity, this question could be
phrased as: "If it doesn't have an impact on our view of the cluster,
why do we need to care - can't this be done outside our control then?"

It's somewhat similar to the question as to whether or not we should
have a "yellow" monitor result: Yes, it would go some way to make the
cluster more of a general management tool, but it is also not strictly
necessary; the stance you took back then was that you didn't want that,
if I wasn't mistaken. We left this health monitoring to more dedicated
apps. Continuing that line of thought seems to suggest that we don't
need "reload" either.

I don't want to nit-pick here, but I'd like to understand whether your
thinking has changed in general here, in which case I'd like to re-raise
the point of the yellow "warning" monitor status too ;-) Or in what case
this feature is different?


Sincerely,
    Lars Marowsky-Brée

-- 
High Availability & Clustering
SUSE Labs, Research and Development
SUSE LINUX Products GmbH - A Novell Business	 -- Charles Darwin
"Ignorance more frequently begets confidence than does knowledge"