Hi Darren,
Please see my response inline.
On 05/25/10 02:54, Darren Kenny wrote:
Hi Karen,
On 05/24/10 09:49 PM, Karen Tung wrote:
Page 24, Use Case #2
I am completely confused by this example, it seems to contradict
with the current engine design in quiet a few areas.
Below is my understanding of use case #2.
I want to make sure we are on the same page before I make further comments.
My understanding of use case #2 is that information about each of the
checkpoints the application wants to execute will be store in
ExecutionCheckpoints objects. The application will create these
objects and add them to the DOC.
Not quite, there is only 1 ExectutionCheckpoints object. It then contains, as
children, the Checkpoints[1], which are objects that describe a checkpoint,
it's parameters, and any data required to create the real checkpoint.
So you would have a tree in the DOC something like:
DOC
ExecutionCheckpoints
Checkpoints sub-class (e.g. TD)
Checkpoints sub-class (e.g. TI)
...
Checkpoints sub-class (e.g. TransferCPIO)
Checkpoints sub-class (e.g. TransferIPS)
The UML diagram on page 25 attempts to describe this.
OK, ExecutionCheckpoints will the root of sub-tree that contains all
the checkpoints information, sounds good to me.
Cool :)
When the application calls execute(), the engine search the DOC for
the list of un-executed ExecutionCheckpoint objects,
and initialize the checkpoints and execute them. Therefore, we will
*not* need to have the engine.register_checkpoing() functionality??
That depends on how the Engine implements it - this is only a use-case, and
one possible solution.
The Engine design could still prefer to use the register_checkpoints() method,
which would make the Engine the one to do the insertion in to the DOC, taking
the place of the Application in terms of the manipulation of the DOC in this
use-case.
Either is possible really, but the hope is that the end-result would be the
same.
Well, the end result of what will appear in the DOC could be the same.
However, the register_checkpoints() must go through the engine.
If we allow the application or other checkpoints to manipulate
the checkpoints list, we will run into many problems. For example,
What to do with the following situation if the registration
does not go through the engine?
1) Application "registers" the following checkpoints to the DOC directly.
a, b, c, d, e, f
2) Application request for engine to run checkpoints, a, b, c, d
3) Engine runs the 4 checkpoints successfully
4) Application "registers" the checkpoint b1, and explicitly specify
for it to be after the b, so, the list will become: a, b, b1, c, d, e, f
5) Now, the application tells the engine to execute all un-executed
checkpoints starting at b1.
What should the engine do in this case? checkpoints c and d has
already been executed. Will they get executed again? Do we rollback
somehow?
That's certainly a good point, and I'm not really sure what the expected
behaviour should be in that case - but this is possibly something that could
even happen with DC - if for example the user edited the manifest after
running as far as 'd'.
For DC today, and even in the future, this situation will not happen.
When the user supplies a manifest with the DC command, content of
that manifest at that moment in time will be loaded into memory,
and that content will be used. If the user edits the manifest, that
change will not be seen by the DC until next time DC is invoked.
The list of finalizer scripts/checkpoints will be fixed upon being loaded,
because the manifest only gets read once at the beginning of a DC run.
So it is valid that the user do this, as long as they don't try to resume
beyond 'b'.
If we run DC using the modified manifest the next time around, the insertion
of b1 is allowed. However, that is another invocation of DC.
In the example above, I am talking about different components updating
the checkpoint list in the SAME process, and problems would result in
that case.
On the other hand, if the registration is required to go through the
engine, the engine will check and refuse to register b1 in that spot.
So that would mean, and I think it's a good thing, that the case of DC should
be taken care of if the Engine rejects the addition of 'b1' and produces an
error for the user - this error will only be generated if the user attempts to
resume using a snapshot of the DOC *after* b, since only after that will 'c'
and 'd' be seen to have already run.
If the registration goes through the engine, the engine will reject
the registration of "b1" at real time if it has already executed
checkpoint "c".
For the case of resume, the registration of b1 is always allowed, it
just means resuming past b1 is not allowed.
I think that works best... Cool.
This use-case is based on the recent discussions with Jean and Sarah
One of the reasons for it being like this is that the ManifestParser
functionality, for DC at least, may insert Checkpoints in to the cache based
on the contents of the XML (e.g. finalizers).
I understand that for DC, we might need to allow additional checkpoints
to be registered after the manifest is parsed. So, we can not
have restriction that no checkpoint can be registered
after the engine start to execute. Supposedly, DC might start by
registering the manifest parser checkpoint, execute it, then, based
on the content of the manifest, register additional checkpoints.
Agreed.
But it's expected that this wouldn't be the complete list of Checkpoints, and
the Application would then, after loading the Manifest into the DOC, insert
it's own check "always required, but not written to manifest" Checkpoints
using the insert_before/after methods.
An example of this might be:
- ManifestParser imported the Manifest, and got:
DOC
ExecutionCheckpoints
TransferIPS - User's IPS packages
Finalizer1 - User's Script 1
Finalizer2 - User's Script 2
Finalizer3 - User's Script 3
- DC then add's it's always present checkpoints:
DOC
ExecutionCheckpoints
+ TargetDiscovery - Limited to zpool discovery only
+ TargetInstantiation - Create Staging Areas (DC zpools)
+ TransferIPS - Populate Staging Area
+ TransferCPIO - Copy from Staging Area - /
+ TransferCPIO - Copy from Staging Area - /usr
TransferIPS - User's IPS packages
Finalizer1 - User's Script 1
Finalizer2 - User's Script 2
Finalizer3 - User's Script 3
+ ICT_VBox - Create VBox Image
+ ICT_ISO - Create ISO Image
If we were to only allow addition using register_checkpoints() this might not
be possible.
I guess it depends on how register_checkpoints() is implemented.
We can implement register_checkpoints() in such a way to allow
users to specify the order.
Yes, so you will require a similar insert before/after mechanism in your
Engine API too then - rather than simply registration in-order. The reason
being the that the need by the Application to be able to insert checkpoints
that are not in the manifest (as previously discussed).
There seem to be the assumption that we want the manifest parser
to register the checkpoints during parse time. Is that what want?
Yes, for checkpoints that can occur in the manifest, not all of them will be
there.
I have always been thinking that the content of the manifest is
parsed by the ManifestParser, and all the original
content is stored in the DOC. Then, the app, DC in this case, will
All the information from the manifest is put in the DOC, as you expect.
query the DOC searching for the list of checkpoints and their associated
information, and then, the DC will call the engine to register the
checkpoints.
The suggestion above isn't all that different, the main one being that
everyone is interacting with a single point in the DOC as opposed to two
locations - which just seems simpler to me.
Here, you are making the assumption that the engine will always
store information on all registered checkpoint in the DOC.
I still have reservation about that. See the "Checkpoint DOC node proposal"
thread for my discussion.
I think you are concerned that doing it with the approach above
will mean multiple copy of checkpoint information exists in the
DOC. While that is true, perhaps we can design a way to just
"move" the node over instead of duplicating the information.
Multiple copies isn't that big a deal here - the objects are light enough - I
just didn't see why the ManifestParser should put things in the DOC differently
than the Application - it just seems more correct for everyone to do the same
thing.
Even though having the ManifestParser register the checkpoints
through the engine would work, I believe the overall Install architectural
design calls for each checkpoint to function in such a way that it
should not know about the engine, and it should only interact with
the DOC. If ManifestParser have to call the engine to register the
checkpoints, it will violate the architecture.
That's true, if we are to avoid the need for checkpoints to know about the
Engine, what you're proposing makes sense.
So to recap, you are proposing that MP would import the checkpoints from the
manifest as a list stored in a "well-known" location - thus making it an
output of the MP checkpoint. The Application then takes this list, and then
makes it's own list of checkpoints, including the one's loaded by MP, and the
checkpoints that it needs to always execute, do a merge and then finally call
register_checkpoints() on the Engine.
Yes, that's exactly what I meant. Now, the only other we need to agree
on is about storing all checkpoint information in the DOC. :-)
Thanks,
--Karen
I think that can work... ;-)
_______________________________________________
caiman-discuss mailing list
[email protected]
http://mail.opensolaris.org/mailman/listinfo/caiman-discuss
