Summary from this morning's meeting. a) The DC manifest will have multiple software nodes, each of which require a different destination to be set. How should DC determine which software node should have the appropriate destination?
It was suggested during the meeting that the execution schema can have a reference back to the software node that a given checkpoint consumes. Thinking about this further, it seems that this still doesn't address the issue. Two other ideas being considered are to make software/destination mandatory in the schema and have it set to a DOC path (similar to what DC will do for the User defined checkpoint); or, make the software section a child of execution. Further discussion is needed to close out this issue. b) What is an example of data that goes in the volatile tree vs the persistent tree of the DOC. An example of data that goes in the persistent tree would be the internal state maintained by the engine or target discovery data that may not change in between runs. The manifest data goes in the volatile tree. For the purposes of DC, it makes sense for most of the data to live in the volatile tree since (i) the manifest can change between runs, and (ii) computed data populated by DC in the DOC will always be computed/populated by DC at the start of every run. For common application classes like transfer, they should just be using doc.get_descendents() to get the software node and pick the first node that's returned. c) Who should maintain the checkpoint snapshots in between invocations of DC -- should the engine do it or should the client app like DC do it. The consensus was that the engine should do it (it internally uses 'zfs rollback -r' to do a recursive rollback). d) Unit testing for DC checkpoints -- how should the DC checkpoints unit tested. The idea is for unit tests to not run the entire checkpoint but only execute the necessary subset of it. The unit tests need to be tightly coupled with the checkpoint so that if anything in the checkpoint changes, the changes need to be carried through to the unit test as well. Further discussion on this will happen offline as to what exactly should the checkpoint unit tests cover. Alok _______________________________________________ caiman-discuss mailing list [email protected] http://mail.opensolaris.org/mailman/listinfo/caiman-discuss
