On 05/12/10 06:59 AM, Dave Miner wrote:
On 05/12/10 07:11 AM, Darren Kenny wrote:
This is how I remember it too :)
As I understood it, from previous discussions, the actual Checkpoint
to be
executed are not part of the manifest[1], as such it there was no
/need/ to
store them in the DOC - of course that doesn't exclude us from doing
so...
But, as found in the prototype we tried, we did need to store some
information
about progress of checkpoints so as to be able to correctly
suspend/resume an
install, hence we came up with the CheckpointData (or CheckpointNode
as it's now
being called).
Saying all that, if finalizers are to be seen as checkpoints in
themselves (as
opposed to there being a single checkpoint that reads and executes a
list of
finalizers), then there may be the need to store the checkpoints in
the DOC so
that they can be read/written from/to XML manifests - is this
something that we
want?
It certainly would be good to have clarification on what we desire of
the
Manifest in this area, so as we can decide on the correct solution.
For the Distribution Constructor, it's imperative that each element of
execution (currently called "finalizers") be expressible as a
checkpoint in its own right, otherwise we lose many of the benefits
that this whole mechanism is intended to provide. For the other
installers, the set of things that are currently glommed together in
the "ICT" area are also expected to be made into checkpoints. The
difference, of course, is that in the case of DC we explicitly allow
the user to specify (by way of the input manifest) the full set of
checkpoints to be undertaken, whereas in the case of the current set
of installers, we do not.
I would suggest that it's up to each application what it wants
produced in any manifest *output* that it requests from the DOC. That
could be by way of marking individual checkpoints, or by setting
something globally. The latter would suffice for the current
application set, I believe (in reality, I don't see a need offhand for
DC to ouput a manifest at all, but perhaps there's some utility that's
not occurring to me), but I wouldn't foreclose the possibility of
either one.
Dave
Thanks,
Darren.
[1] - Although, there was some mention that it may exist separately
in an
XML file of it's own...
On 05/12/10 11:03 AM, Dermot McCluskey wrote:
Sarah,
Just seeking further clarification:
Do you expect the 'regular' checkpoints like TD, TI, etc to be
in the manifest, or just the finalizer script-type ones?
Today the finalizers include Transfer(im-pop) so that more general
purpose checkpoint is exposed to the user. In the case of DC my
expectation is that all execution pieces(read: checkpoints) will be in
the manifest. The idea is that DC is fully configurable by users. They
can do TI and TD any way they way in reality.
Another point is that today the user has to give at least one piece of
target information then DC client takes it from there and sets up the
rest. So, the data for TI is exposed in part today. Why not include the
TI checkpoint? We can leave it such that the user still only specifies
the path to the location for the build, and have the TI checkpoint is
just part of the manifest, just like Transfer is today. The additional
target data is calculated based on the user input from the manifest, and
TI just manages it.
So, to answer your question, yes, I think we want these in the manifest.
sarah
******
_______________________________________________
caiman-discuss mailing list
[email protected]
http://mail.opensolaris.org/mailman/listinfo/caiman-discuss
