Hi Jean and Karen.
I agree that putting all work and output directories under one root
directory is a good idea. It is a good balance between cleanliness and
flexibility. The way we do it now, allowing the end user to put
directories wherever they want, we give them so much freedom that it
could lead to confusion.
My $.02,
Jack
Jean McCormack wrote:
>
>>>
>>> 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
>>>>
>>>
>>
>>
>
