Hi Ethan, Ethan Quach wrote: > Keith, > > Thanks for looking at this ... You're welcome! > > > Keith Mitchell wrote: >> Hi Ethan, >>> base manifest - an AI manifest file with the parameters that the user >>> wants to be derived replaced with special tags >>> >> Minor: I would reword this to be: "An incomplete manifest, with one >> or more parameters that will be determined at time of install" > > That sounds fine to me. I don't mind changing this > wording. > >> >>> 3.1 Creating a derived manifest configuration >>> >>> In order to create a derived manifest configuration, a user must >>> provide a >>> base manifest, which is an AI manifest file with the parameters that >>> the user >>> wants to be derived replaced with special tags, and a derivation >>> module, >>> which is a script that contains the functions that will be used to >>> derive >>> the portions of the manifest tagged in the base manifest. >>> >> This is a touch vague; I'm assuming the script contains the actual >> code used to derive the manifest? Or, does the script only contain >> function calls - if so, where are those functions stored? > > The former. The script contains the functions and will be > called into. If I change, "that will be used to derive ..." to > "that will be called into to derive ..." would that be more > clear? Still sounds odd to me. Maybe I'm nitpicking though. What about "..a script that contains functions to derive..." > >> >>> 3.2 Adding a derived manifest configuration to an install service >>> >>> To add a derived manifest configuration to an install service, the >>> 'installadm add' command with a new -b option is used. The -b option >>> specifies the derivation module script and also denotes that the >>> manifest >>> being added is a base manifest. >>> >>> installadm add -m <manifest> -b <derivation module script> -n >>> <svcname> >>> >> It seems odd to me that the "-b" flag affects both the script and the >> way the manifest is handled - that a functional side effect of the >> flag is that the manifest is treated differently by the server. >> Should the command be "installadm add -b <manifest> <script> -n >> <svcname>" or even "installadm add -b <manifest> -n <svcname>" (in >> the latter case, the script would be referenced inside the manifest). > > This was just something I mocked up, and I don't have a > strong opinion on it either way. I would expect Frank > to have input on this. Fair enough. > >> >> Use Case: Alternate Scenarios: >> After the failure, then what? > > Which use case are you referring to? Some Alternate > scenarios are meant to just be failure cases. Ok. I was expecting something to follow the failures. > >> >> Question: Are there any requirements of the transport mechanism of >> this project, especially in reference to communicating with the new >> SMF service? > > No there are not. The service discovery module will > do what it does today in communicating with the install > service. > > Obviously any new enhancements to the transport > mechanism in general (like understanding bittorrent > as a transport) would require corresponding enhancements > to the service discovery module on the client; but that > wouldn't be in the scope of this project. > >> Any required changes to handle delivery of the scripts or base >> manifests? > > The webserver will certainly have to be serving up an > additional file, but it's static content and fairly constant > in size, so I didn't feel this would make any impact. Good to know.
Thanks, Keith > > > thanks, > -ethan > >> >> -Keith >> >> Ethan Quach wrote: >>> >>> The functional spec for AI derived manifests is posted at: >>> >>> http://www.opensolaris.org/os/project/caiman/auto_install/DerivedManifests/AI_derived_manifests_func_spec.txt >>> >>> >>> >>> >>> I would appreciate and feedback comments. >>> >>> >>> thanks, >>> -ethan >>> >>> _______________________________________________ >>> caiman-discuss mailing list >>> caiman-discuss at opensolaris.org >>> http://mail.opensolaris.org/mailman/listinfo/caiman-discuss
