andrew at beekhof
Jul 12, 2011, 10:44 PM
Post #31 of 31
On Tue, Jul 12, 2011 at 9:27 PM, Lars Marowsky-Bree <lmb [at] suse> wrote:
> On 2011-07-11T21:38:11, Andrew Beekhof <andrew [at] beekhof> wrote:
>> > Well, as far as "validate-all" is concerned, I'dn't actually change that
>> > call at all, and not make it mandatory either.
>> best practice != mandatory.
> Right, if you want to call it "BCP", sure, go ahead.
>> I've no problem with it being in the dev guide not the spec.
>> Same way we recommend that many/most people put a monitor loop at the
>> end of the start action.
> Right; we insist that "start" must only return once the service is fully
> up and operational, and for some service,s the loop is the easiest way
> to achieve that.
>> > But it would be awesome if the UIs actually called it - yet, that is
>> > beyond the specification, I see no need for it to be mandatory.
>> So the shell will start calling validate-all too?
> Uhm, how should I know? It probably should, yes, but that's something to
> discuss with Dejan, and not exactly relevant to the specification of
> what "validate-all" does and what implementors must provide and can rely
Well it is.
Since your position was "let the management tools handle it", its
reasonable to ask how the most commonly used tool would do so ;-)
Its also not clear to me how pushing it into the GUIs solves the
problem that validate-all will only work when all resource
dependencies are available.
This is why I was pushing for the cluster (either directly or
indirectly as part of the RA's start action) to be the one to make the
>> >> Its important that validate-all and start return appropriate error
>> >> messages instead of throwing up their hands and chucking out
>> >> OCF_ERR_GENERIC
>> > Right. But that's already required,
>> 10 head
>> 20 desk
>> 30 add
>> 40 goto 10
> Ah, such constructive communication styles abound here! ;-)
>> Yes, but you only get it if start calls validate-all or the checks are
>> You don't want the first and the second is error prone.
> I didn't say I don't want start *internally* to the RA call
Well, you did actually. That was the only reason I mentioned doing it
But if you're happy with it now, then I think we have a path forward :-)
Florian: could you amend the dev guide to recommend start internally
calls validate-all first up?
> clearly, start needs to verify its requirements. I just
> don't want to call it before a start as a separate action, because that
> is just stupid.
I don't think its that big of a deal, but whatever :-)
>> In my mind it will help split the reports into two piles - user error
>> vs. app error.
> But that is already possible; nothing in the spec prevents that. If you
> see "start" fail with OCF_ERR_CONFIGURED, OCF_ERR_ARGS,
> OCF_ERR_INSTALLED those are quite likely "user errors".
> A RA that doesn't return them but sends back "ERR_GENERIC" for
> everything is an *implementation*, not a *specification* problem.
>> > If we were talking about the spec, I'd rather add some way to return a
>> > descriptive _string_ from the RA to the UI in some standard format so
>> > that the UIs can display a meaningful one-line summary, instead of
>> > rendering our machine-parseable rc.
>> > (i.e., have the RA call a "ocf_describe" binary to set that before the
>> > shell script returns, never mind how that is internally implemented for
>> > now.)
>> Interesting idea.
> Actually it might be very valuable, if the CIB status section can take
> ~80 chars per failure. Perhaps that's the way out of this discussion?
> Architect Storage/HA, OPS Engineering, Novell, Inc.
> SUSE LINUX Products GmbH, GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer, HRB 21284 (AG Nürnberg)
> "Experience is the name everyone gives to their mistakes." -- Oscar Wilde
> ha-wg-technical mailing list
> ha-wg-technical [at] lists
ha-wg-technical mailing list
ha-wg-technical [at] lists