On 09/15/10 10:52 AM, Alok Aggarwal wrote:
On Wed, 15 Sep 2010, jean.mccormack wrote:
I was just talking with Ginnie about the interface between the
checkpoints and their DOC software nodes. The design specifies that
the checkpoint name must be the same as the software node name that
contains it's input. Unfortunately, this interface is subject to user
error and right now that mistake doesn't get discovered until we're
actually executing the checkpoint which is annoying and not very user
friendly. It would be nice to move this check to prior to checkpoint
execution however, not all checkpoints get input from a DOC software
node.
So in our discussion we came up with a potential solution that I
wanted to pass by people.
- Part of the requirement for checkpoint class would be the inclusion
of an attribute indicating whether or not it gets input from a DOC
software node and should be validated. I'll call that attribute
validate_software_name.
- The engine currently generates a list of checkpoints to be
executed. Prior to the call to execute_checkpoints the engine would
perform a check that would cycle through all the checkpoints on the
execution list and if validate_software_name is True would check to
make sure the DOC has a software node with the same name as the
checkpoint.
How about having the 'validate_software_name' (actually
call it 'validate' instead) be a checkpoint class method instead? The
engine would call this method prior to executing
the checkpoints or even at registration time.
The 'validate' method would do the DOC lookup to validate whatever it
wants. So, in the case of validating a software node, it'll lookup the
software node name.
My thought had been if we really want to validate the name in multiple
places we'd only have to write the code once. But if we think there are
other things to potentially validate, then this would be a plus.
Jean
I think something like this would actually get used at
atleast a couple of places in DC.
Alok
_______________________________________________
caiman-discuss mailing list
[email protected]
http://mail.opensolaris.org/mailman/listinfo/caiman-discuss
