I agree with Josh and disagree with Christine. I
believe that declarative verification of configuration isn’t sufficient
to insure operational status of a solution, and believe that it is within the
scope to support definition of self-tests for a solution. I think that “live”
tests are key to verification and that verification is incomplete without it.
Regards,
Debra
From: Christine
Draper [mailto:cdraper@us.ibm.com]
Sent: Saturday, March 18, 2006
5:47 PM
To: sdd@lists.oasis-open.org
Subject: Re: [sdd] Action item on
disagreement over requirement 2.1.7.2
Josh,
We already have a requirement about verification of configuration. I'm fine
with that, although as an approach to verification I would encourage something
more declarative, rather than thinking of it as a "test" that gets
executed. In reality, the payload that supports verification of configuration
may have to support scripts that run and *might* even include a
"test" that causes the resource to execute, but I don't think that's
best practice for configuration verification.
Self-test to me implies actually exercising the resource to test its correct
operation. It implies a broader scope than just the correct configuration of
the resource. It seems to me that a "self-managing" resource should
come with the capabilities to self-test, and that these are no different from
any other capability of the resource. So I think self-tests should be installed
as part of the resource (possibly an optional feature), not as separate
external scripts - and should be initiated by some standard self-test interface
on the resource. Even if we did believe there should be a standard for
"self-test packages" which let you specify external tests to run on a
resource, I'd say it was outside of SDD scope.
Regards,
Christine
Senior Technical Staff Member
IBM,
1-512-838-3482 tl 678-3482
"Josh
Allen" <jallen@macrovision.com>
|
"Josh
Allen" <jallen@macrovision.com> 03/17/2006 06:24 PM |
|
Hi Christine,
I've been deputized to address
your disagreement with requirement 2.1.7.2. Julia says your objection is summed
up with the statement “Self-tests are outside of the scope of install.
They should be deployed as part of normal content. This may be a requirement for
another stds org.”
I agree that specific
self-tests are outside the scope - my agreement with this requirement was based
on the understanding that it doesn't call for the SDD to declare specific
self-tests. Rather, I can envision a "Verify" lifecycle operation
whose "payload" are the self-tests - opaque to the SDD - that would
determine if the solution was correctly configured. Does this opacity make you
feel any better about this requirement?
Thanks,
Josh