Sue,

On 05/04/10 14:50, Sue Sohn wrote:
On 04/23/10 19:47, Ethan Quach wrote:
>
> I have posted a revision to the derived manifest design.
>
> (I've removed the pieces about an interactive manifest CLI on
> the server side, as that needs to be a separate design.)
>
> http://hub.opensolaris.org/bin/download/Project+caiman/DerivedManifests/DerivedManifestsDesignSpec.pdf
>
>
>
> Please review.  Comments appreciated.
>
> thanks,
> -ethan
>
>
>
> _______________________________________________
> caiman-discuss mailing list
> [email protected]
> http://mail.opensolaris.org/mailman/listinfo/caiman-discuss

Hi Ethan,

General: consider adding a glossary

5.2.3 Wherever the derived manifest is made available, is the actual script also made available (copied to installed system on success, made available on failure)?

Not stated, but it can be.  I'll update the doc to clarify that.


5.2.4
set(): Set's-> Sets
verify(): is validates->validates

OK

commit(): Writes the current data out as an instance file to the destination file
   Which destination file? Is this specified by the user?

It's specified by the caller of the manifest input module, which in
this case s the aimanifest command.


5.2.5 aimanifest command

Is it required to load a starting manifest? Or can you build one from scratch?

A call to load a starting manifest is not required.


A couple of examples for set and get would make it more obvious what those commands do.

OK.  I can add some example usages.


Does the starting manifest file need to be valid (i.e., is it verified when loaded)? Or can it be a partially completed manifest, which might not be valid?

No the load command does not validate.


For verify, what is the output? Basically pass/fail? Is there feedback provided to tell the user what failed?

Its a basic pass/fail.  But thinking about it some there should probably
be a way to enable richer output.  We could enable an env variable to
trigger richer output (so that its easily used with the dev and testing
of the scripts as described in 5.2.6.2), or just simply have additional
output come out in the aimanifest log file, see below.


If verify fails during manifest derivation during an install, then I assume the installation would fail. What information is provided to the user in that case and where? Will it be apparent from the install_log as to what happened?

If you're talking about an "aimanifest verify" call from within the script,
no, that wouldn't cause installation to fail.  At the point when the script
finishes execution (with success), the DMM is going to validate the manifest
at that time, and if it fails to validate then, installation process will stop.


Does aimanifest log its commands?

No, but this is a good suggestion.  aimanifest can keep a log
file of all the transactions it's done.  I'll add this to the spec.


5.3.1 Perhaps change to say "-m <manifest/script>" ?

Sure.


5.3.2 If, when adding a manifest, you specify the location as /path/mymanifestfile and you then decide to make mymanifestfile the default, do you again specify the path? Or simply "-p default-manifest=mymanifestfile"?

The latter.  As noted in 5.3.1, the script is listed and referenced as
the name of the file itself, so that's what the user will reference it
as once added to the service.


thanks,
-ethan


Thanks,
Sue
_______________________________________________
caiman-discuss mailing list
[email protected]
http://mail.opensolaris.org/mailman/listinfo/caiman-discuss

Reply via email to