On 2011-07-09T17:23:04, Andrew Beekhof <andrew@beekhof.net> wrote:
> > As a somewhat silly example, consider validate-all checking that
> > "tmpdir" is non-empty and a valid directory. Consider that start removes
> > it. Consider what will happen if something goes wrong with the
> > parameter, or one of our users manages to call "start" manually. (You
> > know they will.)
> >
> > The operation and the validation for the parameters that operation takes
> > belong in _one_ execution context, not split into two.
>
> So you're arguing that validate-all should go away?
Uh? No. validate-all makes perfect sense for an UI or so that wants to
validate the resource agents parameters without actually starting or
stopping it.
> > It is not. But if parameters are incorrect, start will fail,
> Without doubt. However not all failures (and error codes) are created equal.
Incorrect. They are at least _created_ equal. ;-) But indeed, they might
not always check all the same things.
> A "somewhat more detailed failure" is the part I care about.
> How many "it doesn't start" emails/reports do we get? Far too many to count.
That's a systematic problem though that won't be solved by calling two
actions. They will still not get it - so the cluster calls two
operations instead of one, what are the chances that they'll read the
messages from "validate-all" when they currently don't read "start"? ;-)
> I think having the cluster abort before that point would make all our
> lives easier as it would be more obvious that the error is related to
> the config or install.
Right, the UI should actually make use of validate-all - because then
the errors will be reported _when the user actually configures it_, that
makes sense. And hopefully they'll get it then.
(Sure, that doesn't always make sense when they're using a huge shadow
CIB commit, but there's always something.)
How about a phrasing like this in the validate-all description:
"User interfaces should make appropriate use of this operation to
validate the resource's settings prior to adding it to the cluster
configuration."?
Regards,
Lars
--
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@lists.linux-foundation.org
https://lists.linux-foundation.org/mailman/listinfo/ha-wg-technical
> > As a somewhat silly example, consider validate-all checking that
> > "tmpdir" is non-empty and a valid directory. Consider that start removes
> > it. Consider what will happen if something goes wrong with the
> > parameter, or one of our users manages to call "start" manually. (You
> > know they will.)
> >
> > The operation and the validation for the parameters that operation takes
> > belong in _one_ execution context, not split into two.
>
> So you're arguing that validate-all should go away?
Uh? No. validate-all makes perfect sense for an UI or so that wants to
validate the resource agents parameters without actually starting or
stopping it.
> > It is not. But if parameters are incorrect, start will fail,
> Without doubt. However not all failures (and error codes) are created equal.
Incorrect. They are at least _created_ equal. ;-) But indeed, they might
not always check all the same things.
> A "somewhat more detailed failure" is the part I care about.
> How many "it doesn't start" emails/reports do we get? Far too many to count.
That's a systematic problem though that won't be solved by calling two
actions. They will still not get it - so the cluster calls two
operations instead of one, what are the chances that they'll read the
messages from "validate-all" when they currently don't read "start"? ;-)
> I think having the cluster abort before that point would make all our
> lives easier as it would be more obvious that the error is related to
> the config or install.
Right, the UI should actually make use of validate-all - because then
the errors will be reported _when the user actually configures it_, that
makes sense. And hopefully they'll get it then.
(Sure, that doesn't always make sense when they're using a huge shadow
CIB commit, but there's always something.)
How about a phrasing like this in the validate-all description:
"User interfaces should make appropriate use of this operation to
validate the resource's settings prior to adding it to the cluster
configuration."?
Regards,
Lars
--
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@lists.linux-foundation.org
https://lists.linux-foundation.org/mailman/listinfo/ha-wg-technical