Karen, thanks for your review. Comments are in line.
On 03/26/10 12:48 PM, Karen Tung wrote:
On 03/16/10 12:35, jeanm wrote:
I've updated the transfer module design doc at:
http://hub.opensolaris.org/bin/preview/Project+caiman/CUE_docs
Since I'll be out next week, I would like to get input by COB of
Friday the 19th.
Jean
_______________________________________________
caiman-discuss mailing list
[email protected]
http://mail.opensolaris.org/mailman/listinfo/caiman-discuss
Hi Jean,
Here are my comments.
Page 4:
--------------
" Each transfer module will also need to provide the ability to kill a
transfer in progress via various exceptions (KeyBoardInterrupt) and a
kill method."
- I think the transfer module should only kill a transfer in progress
when the kill method is
explicitly called. Either the engine or the application should handle
various exceptions
or keyboard events.
Sure. I'll change the wording so that the cancel method is the only way
to kill the transfer.
- There's no discussion here or later in the document on what will
happen when a transfer-in-progress
is killed? Will the partially transfered data be cleaned up, will it
be left alone...etc..
I think more detail about what will happen would be useful.
I'll add more details here too.
section 3.4.1:
--------------------------------
".... From the data in the node, it will be determined which type of
transfer
is required and will instantiate the appropriate transfer object. ...."
- Just to be clear from our discussion, during checkpoint registration
time,
we will not be able to register the "data in the node", which I assume
you mean
a handle that points to a node in the data cache's tree. What will get
registered into the engine, and subsequently passed into the
create_transfer() function is a fixed key/constant of some sort that
will help the create_transfer() function to retrieve the node in the
data cache's tree that will contain the needed information.
Fine by me, I'll make the appropriate wording changes.
section 3.4.2:
--------------------------------
".... It will provide property decorators to enable the user to set
and get each attribute...."
- I assume you mean the attributes listed in 3.4.2.1. I am not sure
why those attributes
need to be set by "the user". I assume those are private variables
that gets set at the
object's init time, and should not be changed.
They don't need to be set by the user. I've removed that wording.
section 3.4.3.1.2:
----------------------------
- In the current transfer module implementation, the list of files to
be copied
from the live media is generated within the transfer module itself,
it also has the logic to generate the list of files for the
"do_clobber" functionality.
This function did not talk about who would "search the media" and
generate
the list of files to be copied. It also does not talk about who would
set the
list of files for the do_clobber functionality. I think all those
details need to
be discussed.
After talking with both you and Dave, the list of files and directories
and the
do_clobber (and other media specific transformations) will all be
associated with
the media. That means that the files with the directories and files to
be copied
will be in a specific place on the media and will be generated during
the DC build.
The media specific transformations that are needed will be dealt with via an
executable that will reside on the media.
- For the case where the dry run flag is set, the spec mentioned that
all the
computations leading up to the transfer are performed, but the transfer
itself is not executed. Would the result of the performed computation
be recorded anywhere?
Yes. There would be logging messages with that information.
Section 3.4.4
----------------------
- From reading this section, I understand that the IPS checkpoint is
just 1 single
checkpoint. The description of the execute() method talked about the
fact that
"IPS actions to be performed will be determined by the data in the
data cache".
What does that mean? Will calling ips_chkpoint.execute() end up doing
the "whole set" of IPS operations, such as "pkg image-create",
"set-publiser", "install packages"
"uninstall packages", "reset the publisher to different values".
Or doing each of the IPS operations will involve registering different
IPS checkpoints?
Calling the checkpoint could end up doing the whole set of IPS
operations if that is what
the data cache instructs it to do.
Other misc. comments
------------------------------------
- It would be good to discuss what kind of information will be logged,
and at which level
those information will be logged.
Are you looking for something for each subclass or something more
generic for the whole module?
Do you want specifics like "It will log the cpio directories at level X"
or something more like
"It will log errors at level X".
- It would be good to have a diagram or something showing the
relationship of the
transfer checkpoint class, and all the subclasses, and indicating
which functions will
be defined where.
The interface table doesn't do this for you? I'm just trying to see how
this will actually help.
Jean
_______________________________________________
caiman-discuss mailing list
[email protected]
http://mail.opensolaris.org/mailman/listinfo/caiman-discuss
