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?
The reason I ask is that previously we spoke about whether
the Checkpoints need to be stored in the cache and we decided
that they don't - only a small amount of data associated with
each Checkpoint needs to be in the cache.
If, however, the checkpoints need to be listed in output manifest
produced after an install, then that needs to change.
- Dermot
On 05/12/10 00:16, Sarah Jelinek wrote:
On 05/11/10 03:30 PM, Alok Aggarwal wrote:
Talking with Jean, another thing that came up
with respect to Checkpoints was - do we expect
the Checkpoints to be specified in a manifest?
I'm thinking more in terms of the DC manifest here.
And, will an end user be allowed to insert/remove
arbitrary checkpoints from an installer (DC or some
other)? If yes, will the checkpoints have to be
implemented much like some of the other standard
checkpoints such as TI and Transfer or can they
be more free form shell scripts?
Darren/Sarah, do you know?
Yes, the manifests will have to have the checkpoints defined and they
are registered from that for the AI and DC applications. Checkpoints
must implement the checkpoint interface.
ace, but the internal workings are up to the checkpoint developer.
Although, I wouldn't think we need scripts to do any checkpoint work.
The only application that exports the checkpoint interface in the
manifest is DC. Other applications do not allow for insert/remove
arbitrary checkpoints as part of the supported product.
thanks,
sarah
Thanks,
Alok
_______________________________________________
caiman-discuss mailing list
[email protected]
http://mail.opensolaris.org/mailman/listinfo/caiman-discuss
_______________________________________________
caiman-discuss mailing list
[email protected]
http://mail.opensolaris.org/mailman/listinfo/caiman-discuss
_______________________________________________
caiman-discuss mailing list
[email protected]
http://mail.opensolaris.org/mailman/listinfo/caiman-discuss
_______________________________________________
caiman-discuss mailing list
[email protected]
http://mail.opensolaris.org/mailman/listinfo/caiman-discuss
_______________________________________________
caiman-discuss mailing list
[email protected]
http://mail.opensolaris.org/mailman/listinfo/caiman-discuss
