On 2006-07-03T21:34:37, Andrew Beekhof <[EMAIL PROTECTED]> wrote:
> >No no no! The whole _point_ of reload is that _it does not affect
> >resources depending on it_. It is purely local to the given resource.
> to which i would respond "how do we know that?"
>
> we store a hash of the parameters remember... we know "something"
> changed but have no idea what nor if it was important... in which case
> you would have to assume it was.
Uhm, I don't want to be annoying, but did you actually read this thread?
;-)
First, one could assume that for a RA supporting "reload", all changes
are reloadable - and put it into the admins care to not change
attributes which wouldn't be. (This could be done with a hint to the
GUI, but wouldn't require additional smarts in the PE.)
The second alternative was that even the CRM could take a look at, say,
a "reloadable=(yes|no)" flag for the instance parameter/meta
attribute(?) in question (defaults to "no"), and if it is set to "yes",
store it in a different hash. (So we could always tell whether one of
the reloadable or one of the non-reloadable parameters changed.)
Both are "reasonable" to implement, _I think_. Not necessarily now, but
the ability to reduce perceived unnecessary restarts is also important.
I've been whapped on the head by SAP for our current modus operandi ;-)
(Tangent: Who have, in the same way, asked for a way to not apply
unnecessary churn in case several resources are modified one after
another. But, that get's us back into the GUI discussion, which we
should track separately too.)
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"
_______________________________________________________
Linux-HA-Dev: Linux-HA-Dev@lists.linux-ha.org
http://lists.linux-ha.org/mailman/listinfo/linux-ha-dev
Home Page: http://linux-ha.org/
