Hi Darren,
Please see my response below. I removed all the items
that I have no further comments on.
On 05/24/10 08:50 AM, Darren Kenny wrote:
Hi Karen,
Thanks for the feedback, comments/responses below...
On 05/21/10 11:35 PM, Karen Tung wrote:
On 05/19/10 07:34 AM, Darren Kenny wrote:
Hi Darren and Dermot,
Very well written and thorough document. I have a few comments.
General comment:
--------------------------------
There's no discussion throughout the document on how any error from
interacting with the DOC will be reporting, ie: what kind of exception
will be raised..etc..
Also, there is no discussion in the document about what, if anything,
messages
will be logged to help with debugging..etc..
True, that is an omission, I'll see what I can come up with....
It's not really expected that there will actually be all that many errors.
Most of the get methods will return None if nothing matches the parameters.
Adding children isn't expected to be troublesome, but if we do enforce a
uniqueness in the name of a child of any given parent (as mentioned in the
e-mail from Dave Miner) then we may throw an exception if the name isn't
unique.
Similarly in asked to insert before/after another child then we may
also throw an exception if that child doesn't exist...
One case where a failure might be appropriate is if you attempt to add a child
to an object where that child has already been added to another object (i.e.
child.parent != None and child.parent != new_parent).
The from_xml() methods aren't expected to fail, failure should be discovered
in the can_handle() method first in the majority of cases, but we should
probably require an exception to terminate the from_xml importing if invalid
data if found.
to_xml() should never fail, other than returning None if no XML is to be
generated.
Looks like you already come up with quiet a few things to discussion. :-)
Even if there's really no errors, I think it would be good to state that
somewhere so people will know what to expect.
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.
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?
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.
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.
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.
There seem to be the assumption that we want the manifest parser
to register the checkpoints during parse time. Is that what want?
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
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.
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.
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.
Thanks,
--Karen
The application will register the checkpoints they want to execute into
the DOC directly, instead of going through the engine.
The above is my understanding of reading use case #2. Is this what you
meant?
Certainly this is what I described as a possible use-case of the DOC - but as
I say it's *not* intended to be the final result, consumers of the API can
certainly do what they want, but this only attempts to provide a solution that
would work with the DOC as designed.
The actual Engine design would need to be discussed in it's own right...
Thanks,
Darren.
_______________________________________________
caiman-discuss mailing list
[email protected]
http://mail.opensolaris.org/mailman/listinfo/caiman-discuss
