Hi Jack,
Thanks for the review.
On Mon, 19 Jul 2010, Jack Schwartz wrote:
Hi Alok.
Here are my comments for the DC-Redesign doc, submitted today with your
approval. I reviewed the version I pulled at 11:34 AM PST today.
3.5: In general what is the difference between checkpoint name and mod_name?
I thought at first that "checkpoint name" was what gets listed by
distro_const -l. However, parse-manifest and target-setup have checkpoint
names but don't get listed by distro_const -l. Please clarify what mod_name
and checkpoint_name is in the document.
checkpoint name and mod_name refer to how the various
checkpoints are listed in the execution section of
the new AI/DC schema.
I have added verbiage to that effect in section 3.5
3.5.4: How come text-installer doesn't have its own prePkgImageMod? Is all
of its prePkgImgMod processing common to the other kinds of images?
TextPrePkgImgMod is infact needed. I've added it to section
3.5.4
Would there be a need, for debugging perhaps, for splitting out the common
processing from the image-specific processing?
The image-specific processing is fairly minimal so having
these combined seems to make sense. If it turns out that
it does infact make debugging harder (I don't expect it will),
it would be fairly easy to separate these checkpoints out.
3.5.6: Same basic question as 3.5.4.
3.7: The doc says that "CUD doesn't have a concept of finalizer scripts but
instead has a concept of checkpoints." so it is not clear whether
user-supplied checkpoints can be placed anywhere among the pre-defined
checkpoints. With finalizer scripts, one just edited the manifest to include
the user-defined script whereever it was supposed to go relative to other
scripts. Does the mechanism which implements pre-defined checkpoints list
them in the manifest the same way, allowing users to put their custom scripts
where they want (like they can now), or are there restrictions on where
custom scripts can be executed? Can multiple user-defined scripts be
specified? (E.G. If someone wanted to add something right after populating
the pkg-image area, and then do something later to the boot-archive, is this
possible?) Please clarify this in the doc.
There are no restrictions as to where the user defined
checkpoints can be placed in the execution section of the
manifest. That is, they can be run at any stage of the image
construction process and multiple of them can be specified.
I will clarify this in the design doc.
3.10: Currently DC has a simple log that displays only error messages, and a
detailed log that displays error and informational messages. The DC-Redesign
doc talks of a simple log that contains error and informational messages, and
a detail log that contains debug information.
- I see a need to have a log with just error messages. This is useful if,
for example, someone wants to batch a DC job. Do we expect users to tee the
output of DC to a logfile for this?
I digress. The current DC has a notion of a simple-log
and a detail-log. That seems to have been adequate so
far, I have not noticed any outstanding RFEs in this area
either. So I'm tempted to not make a change here.
- What does "debug information" refer to? How does it differ from
informational messages?
It is basically saying that the format of the current
DC logs as well as what gets logged to them will stay
the same.
The second paragraph is incomplete. Maybe a cut and paste error?
I've fixed that.
Here are a few grammatical corrections I found as well:
1.2.7: first sentence: The CUD Error Service is used to store and retrieve
errors.
3.1 Fourth PP: If DC is being resumed... it ensures that the build...
creating datasets are cleared.
3.5.9 First PP: ...finalizer script to be a checkpoint...
3.14: ... individual DC checkpoints as well...
Thanks,
Alok
_______________________________________________
caiman-discuss mailing list
caiman-discuss@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/caiman-discuss
