Hi Alok,
Some comments on this latest spec:
Section 2.3, dependencies:
-Do you have a dependency on any of the error svc stuff? Or is this
handled via the engine.
Section 3.1, DC overview, page 9:
Once the manifest is validated, the manifest data is stored in the Data
Object Cache and the engine returns control back to DC. At this time DC
Page 8 of 25
Last Modified: 07/16/10
instantiates the top-level build dataset (as well as the datasets
underneath
that for pkg image area, boot_archive creation, etc
So, isn't TI a checkpoint that actually does the instantiation here? I
just want to be sure I understand what is doing this work.
Page 9:
If the engine encounters an Exception while running the checkpoints, it
stores that exception in the error service and returns a failure to DC. DC
retrieves the error from the error service and either ignores it or
aborts the
process after logging it appropriately in the logs.
So, the execution schema has a stop on error attribute. Why is the DC
app responsible for ignoring or aborting? Wouldn't the engine be the
place this should happen? Or the checkpoint itself that is running and
encounters an error?
General:
For the args you have listed in the checkpoints we need to ensure that
we specify the key,value interfaces that are expected for these
arguments. For example: compression=gzip, level=1. Or whatever you
determine is the best. I think we should include this in your spec.
Section 3.5.10: page 19
PostPkgImgMod will define a do_execute() that encapsulates the
functionality in it's execute().
PostPkgImgModCustom will execute functionality specific to it and then
execute PostPkgImgMod.do_execute().
Why can't the PostPkgImgModCustom just call PostPkgImgMod.execute()
instead of creating a wrapper around it with do_execute()?
General:
I don't see a reference to configuration of the SMF properties in this
design. You should probably indicate this somewhere so folks know how
this will be managed.
Section 3.10 logging, page 23:
Initially logging will be enabled such that both the simple and
detailed logs
will log to a temporary place, /var/tmp/<logfile>.pid. Once the
'target_create'
checkpoint has run and the build area has been created, the temporary
logs will
be moved to being under the 'log' dataset under the main build
dataset. From
that point on, all future log messages will go to the new locations
under the
'log' dataset.
So.. will you update the log handler for the file to reflect the new
location? I assume so, just checking.
Section 3.11 Error Handling:
As the Install Engine encounters errors, it will store them in the
error service.
DC will retrieve the errors from the error service and take the
appropriate
action.
Again, I am not sure why DC has to retrieve these and take action. Maybe
I misunderstand how the error handling will happen in the engine. I
would assume the engine would handle errors and then just pass the error
stack to DC. Is the engine not logging the errors?
thanks,
sarah
On 07/16/10 06:47 PM, [email protected] wrote:
Author: Alok Aggarwal<[email protected]>
Repository: /hg/caiman/caiman-docs
Latest revision: 145fdbfd718a5158e98f9d0f3f8aefc4401fd3da
Total changesets: 1
Log message:
Update DC design document to reflect review feedback
Files:
update: distro_constructor/dc_cud_design.odt
update: distro_constructor/dc_cud_design.pdf
_______________________________________________
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
