On 05/11/10 07:44 AM, Dermot McCluskey wrote:
Jean,
I think this is a very useful exercise:
What I don't see in this proposal in the interaction with the cache.
I'd like to see that, even in pseudo-code form, so I'm sure we're on
the same page.
Yes. Let's take it that step further.
I don't understand why you pass 2 params into register_checkpoint, which
seem to consist of a function pointer and an object which is a sub-class
of DataObject. If you've added this object to the cache, you should not
need to pass it around as a param - it should only be accessed via the
cache.
Yes. The more I thought about this last night the less I liked that too.
I'm thinking we don't need it. The data is in the cache and we can
access that
so we should do so. register_checkpoint should be as it was:
register_checkpoint(name, func)
Further comments in-line below.
On 05/10/10 18: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>
Is this just for illustration? In reality, these checkpoints would
not be shown in the manifest, and therefore would not generate any
XML, right?
Not sure. They are in the DOC, whether they get written to the manifest
is not really part of this proposal. Now it could be useful debug
information
but I would leave that decision up to whomever (you?) is doing that work.
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)
What type of entity is the return value from register_checkpoint
(TD, TI1, etc)? From the prototype, I recall that the engine
does not instantiate the actual checkpoint objects until it's
ready to execute them, so the checkpoint objects don't exist
at this stage.
I believe register checkpoint does instantiate the object.
But the call to register_checkpoint should not be as indicated above,
but rather
as the prototype did, name and function.
# 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"
I would have expected that the name of the root node where TD stores
targets is a global constant, rather than a value that needs to be
stored and passed around.
It should be programmable for the reason that if you have 2 TD modules
being
executed then you probably wouldn't want the 2nd tromping on the first's
output.
This would also make debug easier in the case of multiple TD's, you'd
have the
output from both checkpoints available.
However, this is an interface that Dave needs to design yet so it's a
bit squishy.
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...
I don't understand the above line?
Just setting a fake td specific attribute.
# 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
So here we would need to make sure the data is actually getting into the
cache.
This is missing from this example. Maybe something like:
ti_node1.add_data_to_cache()
ti_node2.add_data_to_cache()
xfer_node1.add_data_to_cache()
xfer_node2.add_data_to_cache()
# And execute remaining checkpoints:
execute(TI1, TI2, Xfer1, Xfer2) #<---- execute the rest of the
checkpoints.
I'd like to see an example that shows data being retrieved from the cache
within a checkpoint.
OK. Let's take Xfer. The execute for the transfer module would get the
cache via
doc = DataObject.get_instance()
node = doc.get_child_by_name(self.name)
And then pull the appropriate transfer specific information from this node.
Of course you were probably confused here because the write to the cache was
missing from the example.
Does this help?
Jean
Thanks,
- Dermot
Jean& Dave
_______________________________________________
caiman-discuss mailing list
[email protected]
http://mail.opensolaris.org/mailman/listinfo/caiman-discuss
_______________________________________________
caiman-discuss mailing list
[email protected]
http://mail.opensolaris.org/mailman/listinfo/caiman-discuss
