Hi Alok,
Comments inline. I again removed all issues that I have no further
comments.
On 07/13/10 15:50, Alok Aggarwal wrote:
Hi Karen,
On Tue, 13 Jul 2010, Karen Tung wrote:
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.
The engine document in caiman-docs doesn't have
a section 8.4.1. Has the latest doc been pushed
there?
The lastest Open Office version was pushed, but I forgot to push
the latest pdf version. I just pushed it.
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.
DC needs to know about PkgImgMod (replacement for
post_boot_archive_pkg_image_mod) so it can set the
compression information for it. It also needs to
know about BootArchiveArchive so it can set the
boot_archive compression information as well as
padding amount.
I believe we had discussion on a different thread that these value will
be passed
in as arguments to those checkpoints.
Also, DC needs to set the appropriate pkg image
path for the 'transfer_ips' checkpoint to do it's
job.
Yes, it is true that DC needs to set the appropriate pkg image path.
However, it doesn't need to know about checkpoints.
IMO, DC starts, runs manifest parser checkpoint, then, it can
immediately set the pkg image path.
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.
It is not clear to me whether all of this information
can infact be moved elsewhere in the schema. Where do
you think some of the above information can be moved to
in the schema definition?
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?
Yes, it would have to. I don't quite like it but can't
find a way to get away from having to do this sort of
stuff either.
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?
We fail appropriately then. Just as we would if
people accidentally delete any of the other required
sections of the manifest.
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.
On the flip side though, not having manifest parser
as a checkpoint means a user can't stop at the manifest
parsing stage. I could see cases where they infact might
want to stop.
You do raise an important point though -- manifest parser
would have to be run prior to *every* single DC run. Which
means DC has to know to run it every time -- as opposed to
running it only when resuming prior to the manifest-parser
checkpoint.
I don't think I have a good solution here but I need one.
Alok and I had a phone conversation above all the points
above. We both agreed to the following:
- manifest parser and target instantiation will be run as
*internal* DC checkpoints. They will not be listed
in the manifest. They will not be listed when people
do a "distro_const -l".
- DC does not need to have any special knowledge about
any checkpoints listed in the manifest.
Thanks,
--Karen
_______________________________________________
caiman-discuss mailing list
[email protected]
http://mail.opensolaris.org/mailman/listinfo/caiman-discuss
