Hi Alok,
Please see my comment to your responses inline.
I removed all the items that I have no further comments.
On 07/13/10 02:02 PM, Alok Aggarwal wrote:
Hi Karen,
Thanks for reviewing.
On Tue, 13 Jul 2010, Karen Tung wrote:
Hi Alok,
Here are my comments:
Section 1.2.3:
----------------
last sentence of the 2nd paragraph:
"The DOC will also be used to rollback to a checkpoint and
resume the build process from there.".
I believe that's how the engine will use the DOC to provide the
stop/resume
functionalities. DC will not do that. So, I don't think it should
be mentioned here.
The DOC's rollback/snapshot functionality is
an indirect dependency for DC. The engine is
indeed going to be responsible for calling the
necessary DOC interfaces to rollback/snapshot.
The DOC's rollback/snapshot functionality is a dependency
for the engine. So, IMO, DC should put the
dependency on the engine's rollback/snapshot functionality.
As an app, DC shouldn't care how engine implement's
the rollback/snapshot functionality.
I will rephrase the above so the intent is clearer.
Section 2.3, The Data Object Cache bullet
-------------------------------------------
"interfaces to rollback and snapshot": Will those be directly used by
DC?
If so, how? and for what purpose?
The interfaces won't actually be used by DC but they're
an indirect dependency. I'll re-word it.
See my comment above about this.
Section 3.1, 4th paragraph
---------------------------
After the manifest is parsed and stored in DOC, before or after DC
registers the list of checkpoints, DC also needs to set the "dataset"
property in the engine so the engine knows which dataset it should
snapshot
to provide the pause/resume capability
Wow, that's a glaring omission. Where is this specified
in the engine document?
Section 8.4.1 of the latest engine document.
Section 3.1, 6th paragraph
---------------------------
The DC app's role is to drive the image creation process. It should not
be aware of what checkpoints are being executed, and what they do.
So, I don't think this paragrah should belong here, since this
section 3.1
is about what the DC app do, not what checkpoints do.
The fact is that it has to. Initially I had the same mindset
as you do in that I believe DC to be pretty much a "dumb"
app. Once we started doing some initial implementation, it
became clear that DC has to get into the business of knowing
exactly which checkpoints will be executed.
Well, besides the couple of special checkpoints, like manifest_parser
and target instantiation, I am not sure which other checkpoint
the DC app need to know about.
Consider the case of compression mechanism to be used. It
is set in the dc_spec section of the DC manifest even though
it gets consumed by one of the boot archive checkpoints. It
seems cleaner to not have the boot archive checkpoint know about the
dc_spec objects in the DOC if it could instead be specified
as part of a different object in the DOC.
Actually, I disagree about this. Perhaps the compression mechanism being
in the dc_spec section right now is a mistake. Perhaps it should be
moved somewhere else. The dc_spec section should only contain
things that's needed for the DC application.
Let's assume we go with this example and have the DC app know about the
compression and set it in the DOC or something. The VMC image
construction process doesn't use this compression value. So, the DC
app will have to have special case to check for output type and act
accordingly?
general comments for DC checkpoint sections: (section 3.5)
------------------------------
1) Some of the checkpoints are used "internal" to the DC implementation,
such as manifest_parser and target_instantiation. Others are
user specified checkpoints via the manifest. I think we should
make a distingtion between these checkpoints, and document how the
DC app treats them. For example, will the internal checkpoints
show up when you do "distro_const -l"? Will people be able to
resume from those...etc..
Actually I intend on exposing all the checkpoints via
the manifest including manifest_parser and target_instantiation.
Just seems cleaner that way and makes the build process
more observable.
Since manifest_parser and target_instantiation is required for
DC to work, I don't know whether it is good to expose it
in the manifest. What if people accidentally delete them?
What if they move them around? I know for a fact that it
really doesn't matter whether manifest_parser is listed,
because in order for DC to even start, it must run manifest_parser first.
Also, manifest_parser and target_instantantiation
is exposed, I assume via "distro_const -l" also.
What does it mean when people want to resume at ba-init.
Does it mean manifest_parser will be skipped?
It can not be. So, IMO, it is confusing to expose those
checkpoints that's required for the DC app.
That is why you see all the checkpoints listed in this
section.
3) In many checkpoint descriptions, you mentioned that XXXX will have
a mod_name
of XXXXXX. For example, in section 3.5.3, it is mentioned that
"The checkpoint named 'transfer_ips' will have a mod_name
of the CUD transfer module and will....". What is this "mod_name"
value for?
The mod_name corresponds to the 'mod_name' for each
checkpoint in the execution of the DC manifest.
So, you mean, mod_name name of the checkpoint class object
you will use? If that's the case, then, I think you should make
it exactly the way the checkpoint class name is specified.
Also, I want to make sure that mod_name is NOT the checkpoint name
that will be used for registering with the engine, right?
Thanks,
--Karen
_______________________________________________
caiman-discuss mailing list
[email protected]
http://mail.opensolaris.org/mailman/listinfo/caiman-discuss
