Hi Sarah,
Thanks for the review.
On Mon, 19 Jul 2010, Sarah Jelinek wrote:
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.
We do, DC depends on the interface(s) to retrieve
errors. I'll add this to the document.
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.
Yes, this work will be done by a TI checkpoint. DC will
not instantiate any of this on it's own.
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?
That is a very good point. DC doesn't need to get
into the business of deciding which error is fatal
and which is not.
Instead, DC will set engine.stop_on_error to the value
specified in the execution schema. Then when the individual
checkpoints execute and one of them throws an exception, the
engine will honor the stop_on_error variable and either
abort the processing or continue on.
If the engine aborts the processing in the face of an error,
DC will simply retrieve the error, print it out and abort.
I will add this to the spec.
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.
I'll add it.
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()?
Initially I had it so that execute() was being called.
However, the concern with that is that the checkpoint
then is trying to call the interfaces that only the
engine is supposed to call.
Thus, the 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.
The boot-config checkpoint applies the SMF profiles. I'll
make a mention of that.
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.
Yes.
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?
I'll update the spec with what's described above.
Alok
_______________________________________________
caiman-discuss mailing list
[email protected]
http://mail.opensolaris.org/mailman/listinfo/caiman-discuss
