Hi Sarah,
On Wed, 2 Jun 2010, 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 don't think the DC client app should be in the
business of computing values that are then used
by some of the DC checkpoints.
A better architecture would be to have the
DC app simply setup the manifest-parser/engine/DOC/logging
as well as the checkpoints. And, let the bulk
of the actual "image construction work" happen
within the checkpoints themselves -- that's a
much more dynamic model than one where the DC app
itself does a bunch of processing.
What is the post processing exactly for SPARC?
Post processing for SPARC includes fiocompress'ing
the boot_archive contents and installing the ufs
boot blocks.
So, back to the original question, should TI/Transfer -
a) provide alternate interfaces so that they can be called
directly from within a Checkpoint? Or,
b) should a consumer (that is a Checkpoint) of TI/Transfer
instead use the Checkpoint interfaces?
The advantage of (a) seems to be that it flows much better
for DC as the app whereas the disadvantage is that it can be viewed
as a violation of the CUD architecture in some ways.
The advantage of (b) seems to be that it conforms to CUD whereas
the disadvantage is that for some DC checkpoints that need to
call into TI/Transfer, the processing just becomes a little tedious.
Alok
_______________________________________________
caiman-discuss mailing list
[email protected]
http://mail.opensolaris.org/mailman/listinfo/caiman-discuss
