Hi Jean / Dave,
Comments inline...
On 05/10/10 06:21 PM, jean.mccormack wrote:
> During the last prototype meeting, Dave and I were tasked with figuring
> out the DOC interface to pass data to the checkpoint modules. We met to
> discuss this last week with Evan and Sanjay attending for portions of
> the meeting to help.
> Input on this proposal is requested from Dermot, Darren, Karen and Sarah
> but anyone else is welcome to respond.
>
>
> There will be a class CheckpointNode that will be an ABC and will
> inherit from DataObject. It will have a name attribute.
> Each type of checkpoint (TI, TD, Transfer etc) will have it's own
> subclass of CheckpointNode that will have attributes
> specific to that type of checkpoint.
>
> The xml that will be generated would look like this:
>
>
> <checkpoint>
> <name>"name of checkpoint"</name>
> <checkpoint specific attributes to be defined by each checkpoint>
> </checkpoint>
Just curious why you are using a tag to specify the name as opposed to an
attribute - I feel that using an attribute is more capable of validation in
DTD, etc. but maybe I'm wrong, so I would think:
<checkpoint <name="name of checkpoint">
<checkpoint specific attributes to be defined by each checkpoint>
</checkpoint>
>
>
> To further explain this I'll use an example of a client that does TD,
> TI, TI, Transfer, Transfer. Note this is not meant
> to be any real code, it's more pseudocode than anything.
>
> Client()
>
> td_node = TD_ChkptNode("TargetDiscovery")
> ti_node1 = TI_ChkptNode("TI_IPS")
> ti_node2 = TI_ChkptNode("TI_CPIO")
> xfer_node1 = Xfer_ChkptNode("XFER_IPS")
> xfer_node2 = Xfer_ChkptNode("XFER_CPIO")
> ...
>
>
> TD = register_checkpoint(td.discover, td_node)
> TI1 = register_checkpoint(ti.instantiate, ti_node1)
> TI2 = register_checkpoint(ti.instantiate, ti_node2)
> Xfer1 = register_checkpoint(xfer.transfer, xfer_node1)
> Xfer2 = register_checkpoint(xfer.transfer, xfer_node2)
>
>
> # Because we bounce out of engine after TD runs we may want to tell TD
where to put things.
> td_node.dst = "Discovered Targets" # TD_ChkptNode has property "dst"
which is just a name.
> # this name is the name it will give
the root node of
> # a tree of nodes, Physical and
Logical that it discoveres.
There are a couple of things that I see here:
- In the above code you seem to be using the same checkpoint, but with
different parameters (TI and Transfer specifically) to do different things.
This doesn't really fit with the Object-Oriented Design approach, where you
would expect to have a class hierarchy like:
TI
/ \
TI_IPS TI_CPIO ...
In other words there is a base-TI class, where all common functionality is,
and then each specialization of this class for specific purposes - using
this the above code would be more like:
TD = register_checkpoint(td.discover)
TI1 = register_checkpoint(ti_ips.instantiate)
TI2 = register_checkpoint(ti_cpio.instantiate)
Xfer1 = register_checkpoint(xfer_ips.transfer)
Xfer2 = register_checkpoint(xfer_cpio.transfer)
# Actually I'm not 100% sure what the .instantiate and .transfer
# methods are meant to be... I would really have expected the
# parameters to register_checkpoint to be simply class objects, e.g.
# TD = register_checkpoint(TargetData)
# TI1 = register_checkpoint(TargetInstantiationIps)
# TI2 = register_checkpoint(TargetInstantiationCpio)
# ...
- Each checkpoint should have a defined "interface" in that it would define
what it takes in (via the DOC) and what it outputs (via the DOC).
As such, I would have thought that setting td_node.dst would be unnecessary
since it would be the default for TD.
In the case of TD, it would have no input parameters, but would, by default,
output a tree of discovered targets into the DOC. This would be a part of
the "well-known and documented" interface.
> td_node.start = "..." # maybe for DC we don't want it to do physical
target discovery...
>
> # Now execute engine just running TD:
> execute(TD)
>
> # And now we need to add information to other nodes
> ti_node1.create = ... # root node of some tree of nodes that the App
> wants
> ti_node2.create = ... # root node of some tree of nodes that the App
> wants
> xfer_node1.src ="http://some/ips/repo:port";
> xfer_node1.dst = "rpool/jean/pkg_imag" # image area for IPS to install
> to.
> xfer_node2.src = "/"
> xfer_node2.dst = "rpool/jean/whatever" # area to cpio to
I'm really wary of objects being used like this - for example, if at anypoint
the application does a roll-back to a previous snapshot, in-process, then the
objects in the DOC will be different to the objects being used above.
As such, the use-case for anything stored in the DOC should be along the lines
of:
ti_node1 = doc.get_child_by_name( "TI_IPS" );
if ti_node1:
ti_node1.create = ...
else:
# handle no entry, by either creating one, and inserting it or raising
# an exception if it should be there.
If you don't do this, then there is a real chance of things not working as
expected.
>
>
> # And execute remaining checkpoints:
> execute(TI1, TI2, Xfer1, Xfer2) #<---- execute the rest of the
> checkpoints.
Thanks,
Darren.
>
_______________________________________________
caiman-discuss mailing list
[email protected]
http://mail.opensolaris.org/mailman/listinfo/caiman-discuss
