On 04/30/10 16:20, Alok Aggarwal wrote:
Hi Ethan,
Here are my comments/questions -
Section 5.2.6 Does the 'aimanifest load' need to be the
very first thing that the script does or can some derivation
logic preceed the 'aimanifest load'?
It doesn't have to be the very first thing script does.
What I'm thinking here is - if the user wanted to create
a Bootable AI media that has a number of different AI
manifests and which one gets picked for installation is
determined at run-time (based on some machine characteristics, say),
can that be accomplished by this proposal?
Yes, this would be possible.
Section 5.2.6.2 I'm assuming they wouldn't have to build
a custom image in order to test their scripts but instead
can specify the script location as part of the aimanifest=
GRUB menu option. Is that correct?
This would require support in manifest-locator to process
the aimanifest= boot property in that way (which there's an
open bug for), but yes, it should be possible to explicitly
specify the location of a script via the prompt otherwise.
If the admin does infact specify an invalid/erroneous
script, the derivation will fail. At this point, if the admin
chooses to modify the script such that it is now valid, can
he/she just 'svcadm clear auto-installer' to re-initialize
the installation?
There's no reason why this shouldn't be possible. Just like
with a regular XML manifest instance file that fails to validate
today, the user would have to know the file location that the
auto-installer service is consuming, refresh that, and then
clear/restart the auto-installer service.
Section 5.3.2 Is the intent with the default manifest that
if a host does not match any criteria sets (if any are
specified) then it gets the default manifest?
That is the intention. From a selection point of view, its not
that different from it is today really, its just that the default
can be any published manifest, not just the one without any
criteria and named default.
thanks,
-ethan
Thanks,
Alok
On Fri, 23 Apr 2010, 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
_______________________________________________
caiman-discuss mailing list
[email protected]
http://mail.opensolaris.org/mailman/listinfo/caiman-discuss
