Hi Alok,
On 05/26/10 04:13 PM, Alok Aggarwal wrote:
There are a number of existing DC finalizer scripts
that call target instantiation and transfer at
various points in time.
As these finalizers get converted over to being CUD
Checkpoints, I don't believe they can call target
instantiation/transfer directly in CUD any more. Instead,
a Checkpoint that needs to call TI/Transfer would
need to be broken up into multiple different checkpoints
where TI/Transfer is one of them.
So, for example, with boot_archive_archive.py, it
would more or less get distilled into the following
distinct checkpoints -
I don't think we need or want to break these down this way. I agree some
boundaries have to be set and adjusted, but not every finalizer should
be it's own checkpoint. The way I see it is, for boot archive processing:
-Image Modification
-Transfer
The target instantiation for the boot archive target can be done with
the initial target instantiation. We have the boot archive properties
set in the manifest, and if we need to calculate any of them this can be
done earlier on. We know we need 3 targets:
DC build area
pkg image area
boot archive area
So, I think we want to do these all in one Target Instantiation sweep.
The top level DC build area is a dataset, the other two are directories,
right?
1) Compute various boot_archive properties - size, pad,
nbpi, etc
This can be done early on and stored in the DOC for use by target
instantiation in the early stages of DC.
2) Instantiate the boot_archive target
This can be done with initial Target Instantiation. We know the DC build
area path, we can create the directories at this time, can't we?
3) Do optional post-processing on that boot_archive in
case of sparc
Is this before the transfer of contents? In looking at the finalizer
scripts it looks like we do the
boot_archive_initialize - transfer the contents-This would be the second
Transfer checkpoint in the DC processing.
boot_archive_configure
boot_archive_archive- using the nbpi, etc.. data
4) Transfer the contents into boot_archive
5) Release the resources setup in (b)
6) Compress the boot_archive
Each of these checkpoints will store data needed by any
other checkpoints in the DOC as they go along.
So, at a high level I see DC doing something like:
Target instantiation - including boot archive and pkg image directories
Transfer- pkg image population
Image modification-to do the boot archive image modifications that need
to be done
Transfer-populate boot archive area
Post Install-boot archive compression, gen cd contents, create images
Would this not work?
thanks,
sarah
*****
Does anyone disagree with this?
Thanks,
Alok
_______________________________________________
caiman-discuss mailing list
[email protected]
http://mail.opensolaris.org/mailman/listinfo/caiman-discuss
_______________________________________________
caiman-discuss mailing list
[email protected]
http://mail.opensolaris.org/mailman/listinfo/caiman-discuss
