On 06/01/2011 19:40, Keith Mitchell wrote: > On 01/ 6/11 12:30 PM, Ginnie Wray wrote: >> Hi - >> >> I have some observations that I would like to get some feedback on >> regarding this bug. >> >> First observation: Transfer makes an assumption about the state that >> the build area will be in. It makes choices based on whether the >> source directory exists in the data set. If the source directory >> exists, Transfer assumes that it is ok to begin a transfer. In the >> case of this CR, the source directory did exist but there was nothing >> within the directory to permit a transfer to continue. Since the data >> set was in an indeterminate state, the transfer failed. > > The key is that it made assumptions about the state of the directory, > even though there's no guarantee that it is the *next* checkpoint being > run - which means there's no guarantee that the state of the directory > will be changed by a checkpoint that runs prior to it. I don't think > that the __init__ of a checkpoint, and any functions it calls, should > make assumptions about any pre-conditions of the DOC, build area, etc.
Totally agree with this - because of the way that __init__ is done early, but the actual execution doesn't happen until later in the cycle - nothing really can be guaranteed until the call to execute() - it is only at this point that you can safely assume that things should be inplace for the checkpoint to run. > >> >> Second observation: from my reading of the engine code, the engine >> gets a progress estimate right after a checkpoint module is loaded. I >> was talking about this bug with Dave M. and the question came up as to >> whether an application could make changes that would affect that >> calculation between the time the checkpoint is loaded and the time >> execution of the checkpoint begins. > > Absolutely. For example, a full run of DC. We want a progress estimate > of the full process, but we can't estimate the ba-init step because the > files aren't there yet - transfer-ips-install hasn't run yet. > > So, should the engine be enhanced to dynamically update the overall > progress estimate? Possibly. Perhaps the progress estimate for a > checkpoint should be updated just before the checkpoint executes. Hmm, I certainly think that this makes sense, and would be common practice in installers. The right timing for this would be to re-estimate the progress before the running of the next checkpoint. > > Alternatively, the checkpoints need to handle best guess estimates > (which is what ba-init currently does). But as mentioned above, it needs > to be "safe" while it makes those estimates - no assumptions about the > state of the DOC, the file system, etc. While I'm all for best-guesses where it truly isn't possible to estimate the timing, I feel there is more kudos if you can give a proper value when it is eventually possible to determine. > >> >> Third observation: applies to the distro constructor. It makes the >> assumption that the build area is ok when it kicks off the distro >> build. In the case of this bug, the build area was in an indeterminate >> state. > > Pretty much the same as above - this applies to more than just DC, it > applies to extensibility of the checkpoints. To truly cover whatever > future situations (arbitrary sets of checkpoints) we may come up with, a > checkpoint *cannot* make assumptions during __init__ about the DOC (or > anything else). The only time it can really enforce pre-conditions (data > needed from DOC, filesystem layout, datasets, and so forth) and abort > execution is during its execute() call. I agree here too. Darren. _______________________________________________ caiman-discuss mailing list [email protected] http://mail.opensolaris.org/mailman/listinfo/caiman-discuss
