Keith, Thanks for looking at this ...
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? > >> 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. > > 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. > > 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. 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
