* Dave Miner (Dave.Miner at Sun.COM) wrote: > Glenn Lagasse wrote: >> Hey Clay, >> >> Thanks for the feedback, my thoughts inline. >> >> * Clay Baenziger (clayb at sun.com) wrote: >>> Hi Glenn, >>> I'm all for the simple approach. I think the power of the DC is for >>> a user to twiddle the bits on and off and extend only if necessary >>> and skilled enough. >>> If you have a finalizer which does the checksums then someone >>> wanting to extend this functionality can always easily slurp-up and >>> modify that finalizer script. Easier is certainly better! >> >> And why can't they also slurp up and modify the existing finalizer >> scripts that contain the new checksum functionality? >> >>> Though I agree with the simplicity of Karen's desire to have the >>> create_iso and create_usb steps include the hash generation, having >>> it all in one place (a single finalizer script) makes a modification >>> by skilled users easier without really any added complexity for a >>> novice. >> >> I don't know that I see your argument here. Having a distinct finalizer >> script that just computes hashes vs computing hashes inside the >> finalizer scripts that actually create the images you want hashes for >> doesn't seem to be any different to me in terms of ease of modification. >> What exactly is easier about modifying a finalizer script that only >> computes hashes? >> >> By including the checksum generation in the existing image type >> finalizer scripts (by image type I'm referring to the create_iso and >> create_usb scripts which are the only two types of images DC can >> construct at the moment that you'd want checksums for) I'm linking image >> hash generation with the actual image construction which just seems >> natural and logical to me. Moving the hash generation out into a >> finalizer script of it's own buys us the ability to pause and resume >> around that script but I don't find that to be of any significant value >> considering how simple of an operation generating the image hashes are. >> It isn't a long-lived complex process so I don't know that there's any >> 'visibility' gains achieved by being able to stop construction around >> generating the hashes. >> > > If the hashing were configurable, the advantage would be to be able to > re-run with different hashing without regenerating the images. However, > since you don't seem to be implementing configurability of the hashes, > then I guess that's moot.
That gives me something to think about. I think I had this scenario in the back of my head, but wasn't mentalizing it when I was coming up with this. I think I can see how and why having the separate finalizer script (in conjunction with configurable hash types) would be desirable more clearly. Let me go ponder a bit. Thanks Dave. -- Glenn
