Hi Sarah,
Please see my comments inline.
On 06/01/10 08:36, Sarah Jelinek wrote:
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 boot_archive_archive.py is the final step of boot archive
processing. The Image modification for the
boot archive is currently done in boot_archive_configure and the
transfer of the boot archive content
from pkg_image area to the boot_archive construction area is done in
boot_archive_initialize.py.
The "transfer" that's done in boot_archive_archive.py is to cpio the
modified content of
the boot archive construction area into the UFS based boot_archive.
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
Just to be clear, there's a boot archive construction area under the DC
build area, and then,
there's a *separate* target for the UFS boot archive itself.
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?
Currently, the DC build area is one top level dataset. A build_data
area is a separate dataset
under the DC build area dataset. The "pkg image area" and "boot archive
area" are directories
under the build area. The build area is snapshot by DC to provide the
stop and resume support.
The actuall UFS file for the UFS boot archive is created in the "pkg
image area" by boot_archive_archive.py script.
The UFS boot archive can not be created early at target instantiation
time, because size of the boot archive
is dynamically calculated based on the content of the boot archive
construction area.
All the modification done to the boot archive construction area affects
the size of
the boot archive, so, it must be created after boot archive modify.
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.
No, this all depends on the boot archive content, so, all this can not
be calculated until after
boot archive modify is done.
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?
See above for why we can not do this.
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_initialize is to copy the selected content of the
boot_archive from the pkg image area to
the boot archive, based on the boot archive content list specified in
the manifest.
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
This will not work. Some of the modifications to the package image area
need to be done before the boot archive is constructed, and must be included
in the boot archive. So, "transfer" of content to pkg image area and
boot archive
construction area can not be done at the same time, and must be 2
separate transfer.
After content is transfered to the root archive construction area, it
needs to
be further customized, before the boot archive can be constructed.
Thanks,
--Karen
_______________________________________________
caiman-discuss mailing list
[email protected]
http://mail.opensolaris.org/mailman/listinfo/caiman-discuss
