Hi Karen,
Comments below...
On 05/20/10 06:53 PM, Karen Tung wrote:
> Hi Jean,
>
> I am confused about the last part of this proposal. Probably you or someone
> else
> at the meeting can provide more details. Please see below for my comments.
>
> On 05/20/10 08:43, jean.mccormack wrote:
>> In order to get closure on this issue, Darren, Sarah, Alok and myself met to
>> resolve the issues.
>> We discussed the need for the transfer module to be a class with IPS/CPIO as
>> sub-classes. The original reason was based upon the belief that we had to
>> register all checkpoints at the top when we wouldn't necessarily know what
>> type of transfer was desired. With some thought and discussion is was decided
>> that we didn't have to register everything at the top so the app could, after
>> user input, know what type of transfer it wanted and register everything to
>> come at that point. This removes the create_transfer method and the transfer
>> class.
>>
>> We discussed where target information would go in the DOC.
>> The decision was that target discovery would place this object in the DOC at
>> a known place. If for some reason there is more than one target discovery
>> object, they will be stored in order.
>>
>>
>> We also discussed where the desired target to be instantiated object would
>> go,
>> that was also decided to be at a known place in the DOC. If for some reason
>> there is more than one desired target object, the objects will be stored in
>> the order upon which they will be needed.
>>
>> Then we talked more about the checkpoint specific information. The DOC has an
>> execution object which has checkpoint objects under it. Each checkpoint will
>> have such an object with checkpoint specific data within it.
> Who creates these execution objects, and when?
The "Execution" object would only have to be created once - who creates it,
would most likely be one of two things:
1) The Application - when it wants to insert the list of checkpoints to be
executed, then it would have to create it, if it didn't already exist.
2) ManifestParser - again, it's in the action of creating the checkpoints,
if there are any in the manifest, it will create the Execution object,
if it doesn't already exist - and then add the checkpoints as children.
For clarity, it may be simplest if the Application always created it first...
>>
>> The client app will do the following:
>> - instantiate the appropriate target/transfer objects
> Are these target/transfer objects checkpoint objects or something else?
Maybe there is a little confusion here for Targets - Targets are mainly just
other pieces of data. Specifically the data to describe the following:
- "discovered" disk layout (usually generated by TD)
- a copy of this (possibly sparse - TBD) to be the "desired" disk layout,
mainly used by TI
But, I think what was meant here, is the checkpoints, in other words:
- TargetDiscovery - which would generate the discovered targets
- TargetIntantiation - would use the discovered, and desired targets to
figure out what to do.
- Transfer (Possibly multiples of these)
>
>> - store the target/transfer objects at a known place
>> in the DOC *in order* of execution
> From this bullet and the following bullet point about registering
> the checkpoints, it seems to hint that the target/transfer objects
> are not checkpoint objects. If that's the case, why is the *order* important?
Order is only important for the checkpoints - as far as I'm aware...
>
>> - register the checkpoints
>> - execute the checkpoints.
>> - the completed flag will be set to True in each checkpoint that
>> has successfully executed.
> The application will set the completed flag? That doesn't sound right.
> Since the engine actually invokes the checkpoints, only the engine
> would have the direct knowledge about whether a checkpoint is completed.
I would think that whatever is best able to, should be the one to set the
completed flag - in general I would think that this should be the checkpoint
itself since it's the one that should know best whether it was a successful
completion or not. I would think that the Engine should only need to look at
this flag, and skip a checkpoint if it's already completed.
Thanks,
Darren.
_______________________________________________
caiman-discuss mailing list
[email protected]
http://mail.opensolaris.org/mailman/listinfo/caiman-discuss
