>> >> Also, we had discussed possibly setting up a new tree structure for >> the builds. Possibly >> deferring it until after Phase 0 since it wasn't critical. >> >> Here's what I was thinking: >> >> pkg_image_area is specified in the manifest. Let's use something like >> rpool/dc-builds as an example. >> >> We then create rpool/dc-builds/proto, rpool/dc-builds/log (for the >> log files) >> rpool/dc-builds/media (for the output files) and maybe >> rpool/dc-builds/x86.microroot >> (for the microroot instead of /tmp/x86.microroot) if it works. > Do you mean each of the rpool/dc-builds/proto, rpool/dc-builds/log, > rpool/dc-builds/media....etc... will > be its own dataset? Or just one dataset, rpool/dc-builds, and then, > everything else under it will just > be subdirs? I'm thinking 2 datasets rpool/dc-builds/pkg_image (I forgot we're not using proto anymore) and rpool/dc-builds/bootroot (likewise, not using microroot) There's really no reason to snapshot the others and it could cause issues. > > rpool/dc-builds/proto: since we are getting away with the use of the > word "proto", perhaps call it "pkg_img"? Yup. > rpool/dc-builds/log: I think the log files in the log directory need > to be timestamped. Otherwise, when > we utilize the checkpoint/rollback > feature of DC to run multiple times, the log files will all be > overwritten. Yes. But that's for the person do the log file work to do. This is just the directory to store them in. > rpool/dc-builds/media: I am wondering whether the output files need to > be timestamped too? Or make it an option to be specified in the > manifest? I am thinking that in case we > do multiple runs, we might not want the previous output to be > overwritten. I agree. Likewise, not part of this work. > rpool/dc-builds/x86.microroot: When we implement dynamic sizing of the > microroot, this will definitely work. We will just > populate and configure the bootroot with > files in a regular directory under this "work" area. > In the archiving of the bootroot script, > we will then really create the "bootroot file", which can either > reside in /tmp or also in this work > area, we will then immediately fill it with the content of the > bootroot directory in the workaround, > and archive it up. Everything is done in the same script > instead of being in multiple scripts > like we do now. I might not have been clear. This directory is instead of /tmp. > > I think the work area also need to have: > > rpool/dc-builds/tmp: This is the temp directory. I found that having > a temp directory based on pid in /tmp > doesn't work if we do multiple runs using the checkpointing feature > and multiple finalizer scripts > depend on the same tmp file in the temp dir. This is because > everytime we start the DC app, the pid will change, > so, subsequent run of the DC app can't access temp files created by > the previous run. Using the same temp > dir will eliminate the problem. I can do that easily. Good thought.
BTW: I have this mostly working. Thanks for the input. Jean > > Thanks, > > --Karen > >> >> Then the user has everything under one area. They don't need to worry >> about modifying >> multiple places in the manifest. This is more like the install and ON >> gates work and people seem >> comfortable with that format. >> >> I have the cycles now to work on this if you wish. >> >> Jean >> >> >> >>> Thanks, >>> >>> --Karen >>> _______________________________________________ >>> caiman-discuss mailing list >>> caiman-discuss at opensolaris.org >>> http://mail.opensolaris.org/mailman/listinfo/caiman-discuss >>> >> > >
