Hi Karen, On 05/24/10 09:49 PM, Karen Tung wrote: > 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. >
Agreed, I'll add something do the document. >>> 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'. So it is valid that the user do this, as long as they don't try to resume beyond 'b'. > > 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. 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. > > 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. I think that can work... ;-) Thanks, Darren. _______________________________________________ caiman-discuss mailing list [email protected] http://mail.opensolaris.org/mailman/listinfo/caiman-discuss
