Hi Jean,
First, I want to make sure I understand the problem this proposal solves.
Are we trying to solve the problem of explicitly "tagging" certain data
in the data cache so multiple invocation of the *same* checkpoint would
know which data is meant for which invocation?
Assuming the above is true, please see my other
questions/comments inline.
On 05/10/10 10:21, 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>
So, the CheckpointNode object is intended to be the central location to
putting all the input parameters for the "named" checkpoint? What about
the case where 2 different invocations of the same checkpoint
are adding data to the cache, will each add their data to their "own"
CheckpointNode area?
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")
...
This just creates the objects, who will add them to the cache?
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)
I assume here, the engine just passes the nodes as an argument to
the checkpoint, and it is up to the checkpoint to do whatever is
necessary with the nodes?
# 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.
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
# And execute remaining checkpoints:
execute(TI1, TI2, Xfer1, Xfer2) #<---- execute the rest of the
checkpoints.
The above works well since the application created all the CheckpointNode.
If one checkpoint wants to give some input to another checkpoint, how will
they look up the other checkpoint's CheckpointNode? If checkpoint 1
searches
the cache for the other checkpoint's CheckpointNode by name, that means
checkpoint 1 would have to know about the other checkpoints, which the
architecture
does not allow. My understanding of the architecture is that each
checkpoint
should operate using data from the cache independently without knowing
other checkpoints.
I have the following suggestion that can solve the problem. It is also
consistent
with the architecture. Taking your previous checkpoints as an example:
The application registers the checkpoints.
engine.register_checkpoint("discovery", td.discover)
engine.register_checkpoint("ti-1", ti.instantiate)
engine.register_checkpoint("ti-2", ti.instantiate)
engine.register_checkpoint("xfer-1", xfer.transfer)
engine.register_checkpoint("xfer-2", xfer.transfer)
The checkpoints ti.instantiate and xfer.transfer will define
public interfaces about what input it expects, and where in the
cache is expects to find those input.
For example, ti.instantiate checkpoint implementation defines that it
will look for
the value(s) referenced by the predefined key "DIRS-TO-CREATE".
xfer.transfer checkpoint implementation defines that it will look for
values(s) in the predefined values SRC, and DST.
Since the application knows all about the different checkpoints, and it is
in "central-command", after it registers all the checkpoints,
it can first set the DIRS-TO-CREATE value in the cache to a particular
value.
Then, it execute the checkpoints discovery and ti-1.
Then, it resets the DIRS-to-CREATE to a different value that will be
consumed
by ti-2, and execute ti-2. Now, the SRC and DST for xfer-1 can be set,
if it hasn't
been set already, then, execute xfer-1, and pause. Reset values for SRC
and DST
and execute xfer-2.
With the above approach, each checkpoint presents a public input interface
of what values it expects to consume, and we just need to ensure that
those input values are set before calling that checkpoint.
Thanks,
--Karen
_______________________________________________
caiman-discuss mailing list
[email protected]
http://mail.opensolaris.org/mailman/listinfo/caiman-discuss
