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 > caiman-discuss at opensolaris.org > 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. - 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. 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. 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. 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. - 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? 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? 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. - 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. Thanks, --Karen
