Karen Tung wrote: > Jean McCormack wrote: >> Karen Tung wrote: >>> Jean McCormack wrote: >>>> Karen Tung wrote: >>>> >>>>> Jean McCormack wrote: >>>>> >>>>>> Dave Miner wrote: >>>>>> >>>>>>> Jean McCormack wrote: >>>>>>> >>>>>>>> Great. Here's what I'm working doing. >>>>>>>> >>>>>>>> The user specifies the "boot_area" in the manifest. Let's say >>>>>>>> it's rpool/dc-builds. >>>>>>>> >>>>>>>> We create pkg_image and bootroot as zfs dataset/mountpoints >>>>>>>> underneath it. >>>>>>>> Also we create logs, media, and tmp as just plain old >>>>>>>> directories under it. They >>>>>>>> don't need to be datasets and it could cause loss of info they >>>>>>>> want like an old logfile >>>>>>>> if they rollback. So I'm not doing that. >>>>>>>> >>>>>>>> >>>>>>> That would seemingly only be a concern if snapshots were taken >>>>>>> of those datasets, and would still be a concern with this design >>>>>>> if you actually snapshot the top-level dataset (which I'm not >>>>>>> clear on), so I guess I don't see how this is a reason not to >>>>>>> make them datasets. By making them datasets, you would provide >>>>>>> for independent rollback of each of them if desired, as well as >>>>>>> all the other goodness that separate datasets allow, which is >>>>>>> not possible in the scheme you're suggesting. >>>>>>> >>>>>>> Dave >>>>>>> >>>>>> True. It's not a major change and easily made. And I'm not >>>>>> snapshotting the top level. >>>>>> >>>>>> Jean >>>>>> >>>>>> >>>>> Following the discussion so far, it sounds like Dave suggests that >>>>> we make each of the directory datasets, and snapshot each of >>>>> them individually. Jean suggests that we only make pkg_img and >>>>> bootroot datasets. >>>>> >>>>> I think both approach have problems in the sense that things might >>>>> get out of sync, and it might also be wasteful of space. >>>>> >>>>> From the DC point of view, there's no way to determine which of >>>>> the scripts registered in the finalizer are for constructing the >>>>> bootroot. So, if we want to snapshot the pkg_image and bootroot >>>>> datasets separately, how do we know when to >>>>> start snapshot the bootroot dataset? >>>> My original message mentioned that I believe we need to add this to >>>> the manifest. This way users can also have flexibility in >>>> what they want snapshotted if they add their own script. And that >>>> area could conceivable not be pkg_image or bootroot. >>>> >>> I re-read your original message, and I found the place where you >>> mention that. >>> I guess I didn't quiet understand what you meant the first time. >>> Sorry about that. >>> >>> You said in your original email >>> >>> -------------------------------------------------------------- >>> >>> # ls /rpool/dc-builds >>> bootroot logs media pkg_image tmp >>> >>> Then in the manifest under the finalizer scripts I'm adding the >>> ability for the >>> user to specify 1) if they want to checkpoint_before the script is >>> run (default is true) >>> and 2) the data set to checkpoint. (default is pkg_image). They can >>> specify >>> specify pkg_image, bootroot, or a full dataset. >>> >>> -------------------------------------------------------------- >>> >>> Now, I think I understand what you proposed. You meant, people can >>> specify something like this >>> in the manifest that will control how checkpointing is done. Here's >>> a section of the manifest with what my understanding of your >>> proposal specified, >>> is this what you mean? >>> >>> <finalizer> >>> <script >>> name="/usr/share/distro_const/slim_cd/pre_bootroot_pkg_image_mod"> >>> <stdout_logfile> >>> >>> /tmp/pre_bootroot_pkg_image.out >>> </stdout_logfile> >>> <stderr_logfile> >>> >>> /tmp/pre_bootroot_pkg_image.err >>> </stderr_logfile> >>> <checkpoint_before> yes >>> </checkpoint_before> >>> <dataset_to_checkpoint> >>> rpool/dc-builds/pkg_image </dataset_to_checkpoint> >>> </script> >>> >>> <script >>> name="/usr/share/distro_const/bootroot_initialize.py"> >>> <stdout_logfile> >>> /tmp/br_initialize.out >>> </stdout_logfile> >>> <stderr_logfile> >>> /tmp/br_initialize.err >>> </stderr_logfile> >>> <checkpoint_before> yes >>> </checkpoint_before> >>> <dataset_to_checkpoint> >>> rpool/special_random_dataset </dataset_to_checkpoint> >>> </script> >>> <script >>> name="/usr/share/distro_const/bootroot_configure"> >>> <stdout_logfile> >>> /tmp/br_configure.out >>> </stdout_logfile> >>> <stderr_logfile> >>> /tmp/br_configure.err >>> </stderr_logfile> >>> <checkpoint_before> yes >>> </checkpoint_before> >>> <dataset_to_checkpoint> >>> rpool/dc-builds/pkg_image </dataset_to_checkpoint> >>> <dataset_to_checkpoint> >>> rpool/dc-builds/bootroot </dataset_to_checkpoint> >>> </script> >>> </finalizer> >> That's it!!!! >>> >>> With this manifest, and the assumption that the first finalizer >>> script is "step 1", after the above >>> is done, I will have the following on my system: >>> >>> rpool/dc-builds/pkg_image at .step_0 >>> rpool/dc-builds/pkg_image at .step_1 >>> rpool/special_random_dataset at .step_2 >>> rpool/dc-builds/pkg_image at .step_3 >>> rpool/dc-builds/bootroot at .step_3 >> Yup. >>> >>> Since I didn't specify for the pkg_image dataset to be snapshot in >>> step 2, it will not get snapshot, right? >> Correct >>> So, now, I specify that I want to resume at step 2, what will happen? >> The pkg_image area will be just what it was when you started the DC >> up. No rollback of it will happen. >>> >>> - rollback rpool/special_random_dataset at .step_2 >>> - since there's no rpool/dc-builds/pkg_image at .step_2, will we just >>> rollback to the last known snapshot >>> for pkg_image, which is rpool/dc-builds/pkg_image at .step_1? What if >>> people deleted rpool/dc-builds/pkg_image at .step_1? >>> Do you rollback to step_0? Or do you detect that step_1 should >>> exist, and now it doesn't, >>> so, you force them to start from scratch? >> No rollback happens of pkg_image. Only the special image area will be >> rolled back because that's what you have >> stated you want. >> >> Like other areas of the manifest, it is assumed the user knows what >> they are doing. Think of the fact that they could >> leave out any of the bootroot files if they wish. >> >> Jean > Thanks for the explanation Jean. I completely understand your > proposal now. I still do have comments about it. > I think we are making it too complicated with the above scheme, and it > will confuse the user more than help them > I think. With the above, they will have to explicitly specify > anything that they want to snapshot. > >>> >>>> >>>> >>>>> The achieve the above, I suggest to put pkg_img, bootroot and the >>>>> tmp directory into one dataset, and snapshot it as we checkpoint. >>>>> >>>> How do you envision this looking? In order to do this you'd need >>>> pkg_image, bootroot and tmp to be under yet another subdirectory. >>>> Seems >>>> like it could be confusing to the user which is what we're trying >>>> to get away from. >>>> >>>> Jean >>>> > I still like my suggestion about keeping the pkg_image, bootroot and > temp dir into one dataset, and snapshot it in each step. > > I envision this structure. > > rpool/dc-build (this is specified in the manifest) > > Under it, we will have: > > media > logs > build-data (a dataset that we snapshot at each step) > pkg_img > tmp > manifest_step_files > The above will be created as the DC app starts. We will > document about the fact that the build-data directory > is snapshot at each step, so, for all the finalizer scripts, including > the bootroot scripts, if they want their > data to be snapshot, they should put it as a directory underneath the > build-data directory. When the bootroot > scripts are run, they can just create the bootroot directory under > build-data then. There could be other > directories under build-data too if the finalizer scripts find it > helpful to put them there. I like this idea minus the manifest_step_files directory which I comment on below. > > As for the media and logs and snapshotting them, I understand your > point about accidentally deleting stuff, and > it would be good to have a copy. Do we snapshot them at each step too? No. I think that should be up to the user. Say you have a log file log09092008.err and you snapshot it after step 1,2, 3 etc. When you start a new build resuming at step 2 you lose all the data added to log09092008 in step 3 etc. when you rollback. You really don't want that since your new log file might be log09102008 and maybe you want to be able to later see what was in the earlier one. I see it more as having these as datasets to allow the user to help themself. Kind of like I snapshot my workspace multiple times a day. > > Why I added a directory for "manifest_step_files"? I found the > current way doesn't work if I want to run 2 DC > at the same time on the same system. On my system, I want to run 2 DC > at the same time, and one > of the DC run as the pkg_image area specified as > space/protos/dc-run-1, the other one has the pkg_image area > as space/protos/dc-run-2. With the code today, all the .step files > are placed in space/protos, and they overwrite > each other as they run. So, we need to move the step files into their > own area. The step files are being put in the build_area now. We actually don't want them snapshotted. The problem you're seeing will go away since each build will have a separate build area that is specified. In your example they would reside in space/protos/dc-run-1 and space/protos/dc-run2. Since previously we were specifying the pkg_image area and they can't reside there, they went up 1 level which meant there was conflict with multiple runs.
Jean > > Thanks, > > --Karen > >
