On 05/11/10 11:03 AM, Keith Mitchell wrote:
On 05/11/10 09:40 AM, Dermot McCluskey wrote:
Jean,
Comments inline below.
On 05/11/10 16:57, jean.mccormack wrote:
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.
Not in the prototype. register_checkpoint() instantiates the
CheckpointData objects, but not the Checkpoints themselves. They
are not created until CheckpointData.load_checkpoint() is called,
which is shortly before execute() is called.
Keith explained before that he wants to keep it this way, as it's
more efficient, especially in the case where you don't actually
get to run all the registered checkpoints.
It also covers the case where you don't know whether you'll be running
an IPS install or CPIO install until after you've completed a few
checkpoints. That's the primary reason for the delayed creation
execution of an earlier checkpoint can have an effect on what kind of
checkpoint is created.
Yeah. Thanks.
Also, register_checkpoint doesn't return anything in the prototype.
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.
When would you ever need to run several different TDs?
Let's not make assumptions about checkpoints. Just because it doesn't
make sense in the current install model doesn't mean it can't/won't
evolve that way down the road.
Which is why I had called it out. But I'm willing to be a little
flexible here if need be. I would prefer to make
it programmable as it sounds you do. Maybe the ultimate solution is to
have a default location that can
be overridden with an entry in the cache?
Jean
_______________________________________________
caiman-discuss mailing list
[email protected]
http://mail.opensolaris.org/mailman/listinfo/caiman-discuss
