RE: [sdd] Action item on disagreement over requirement 2.1.7.2

[Christine Draper <cdraper@us.ibm.com>]

Josh,

OK, I withdraw my objection as long as the "self-test" is for verification of "usable" lifecycle state and not an arbitrary "verification of function" test. Also assuming that it is possible to provide verification (for both installation and configuration) which does not involve an active self-test.

Regards,
Christien

Senior Technical Staff Member
IBM, 11501 Burnet Road, Mail Point 901-6B10
Austin, TX 78758
1-512-838-3482 tl 678-3482
"Danielson, Debra J" <Debra.Danielson@ca.com>

"Danielson, Debra J" <Debra.Danielson@ca.com>

03/23/2006 12:20 PM

To	<sdd@lists.oasis-open.org>
cc
Subject	RE: [sdd] Action item on disagreement over requirement 2.1.7.2

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, 11501 Burnet Road, Mail Point 901-6B10
Austin, TX 78758
1-512-838-3482 tl 678-3482
"Josh Allen" <jallen@macrovision.com>

"Josh Allen" <jallen@macrovision.com>

03/17/2006 06:24 PM

To	Christine Draper/Austin/IBM@IBMUS
cc	<sdd@lists.oasis-open.org>
Subject	[sdd] Action item on disagreement over requirement 2.1.7.2

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