On 06/ 2/10 01:02 PM, Sarah Jelinek wrote:
On 06/ 1/10 03:59 PM, Alok Aggarwal wrote:
Hi Sarah,
On Tue, 1 Jun 2010, Sarah Jelinek wrote:
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?
Karen responded pretty well as to why this won't work.
In brief, we don't quite have the information
needed to instantiate the boot_archive UFS until much
later in the DC process when the pkg_image area as well
as the boot_archive have been populated.
So, really it seems that with the new architecture,
the boot_archive_archive finalizer needs to be broken
into a number of different checkpoints.
Yes, I agree. but, I think that these are instances of additional
Transfer checkpoints, and TI checkpoints. I think that the post
installation processing of the boot archive can be done as one post
install checkpoint. The computing of various boot archive properties
should be done in the client, imo, not as a checkpoint. The client can
gather the data from the DOC and compute the values, then call TI to
instantiate the boot archive.
I'm not sure that's a particularly good idea. We've tried to keep that
specific knowledge out of the general DC application so that the
particulars of each image type are encapsulated in the checkpoints that
are used to construct it. Evidence so far indicates that this works
well, since we've used the application readily to several different
image types and multiple architectures without really modifying the core
application at all - all those changes have been in either manifests or
(mostly) image-specific checkpoints. What benefits would we achieve by
moving such logic into the client application?
Dave
_______________________________________________
caiman-discuss mailing list
[email protected]
http://mail.opensolaris.org/mailman/listinfo/caiman-discuss
