On 07/14/10 09:47 PM, Dave Miner wrote:
Would you explain in more detail, both generally and specifically, what criteria you would like to see?On 07/14/10 10:13 AM, William Schumann wrote:Given options for locations of SC manifests previously addressed: 0) AI manifest 1) wanboot.conf 2) sc_manifest/ directory in hierarchy0) AI manifest is unsuitable as the only means of specifying SC manifests since it forces an association and a dependency that may not apply to all users. 1) wanboot.conf is unsuitable for reasons given previously. 2) sc_manifest/ directory in hierarchy - this would require a command set for maintaining the files and the order in which they are processed on first boot. This is not prohibitive, but not elegant. After discussion with Ethan, proposing a solution that combines features of the others. Storing and sending single SC manifest file to the client would simplify matters. XInclude can be used to perform inclusions from multiple sources on the AI server side, which would improve scalability. installadm command additions: Specifying an SC manifest with installadm subcommands, where <sc_manifest_file> is either a path or URL specification: when creating an AI service: create-service ... [-s <sc_manifest_file>] for a custom client, upon creation of the client or to modify an SC manifest for an existing client: create-client ... [-s <sc_manifest_file>] to change an SC manifest associated with an existing service, a new installadm subcommand is created: modify-service -s <sc_manifest_file> To delete SC manifests, the "-S" option (rather than "-s") is specified in all of the above.I'm still wondering why we wouldn't want to use criteria for configuration manifests in the same way we do for the AI manifest. This scheme seems to leave only per-service or per-client behavior without the other dimensions that the criteria design allows for.
More narrowly focusing on the above, why wouldn't we provide a modify-client subcommand rather than overloading create-client?
Ethan pointed out to me that presently 'create-client' is used to modify.
Before going further, I would recommend some consultation with Frank on both that question and the options; I consider the -s/-S inversion of operation based on capitalization to be dangerous.
OK
Indeed, the design relies upon the sysadmin to manage an inclusion framework.To display an SC manifest for a custom-client or a service: export-sc { <CID> | <service> } To list any services, specific services, or specific clients with SC manifests: list-sc [ <CID> | <service> ] Behavior: installadm parses, verifies, and stores the SC manifest: - inclusions through XInclude are performed - XML is verified - if DTD file is specified in DOCTYPE, validate SC manifest against DTD - store in /etc/netboot hierarchy according to either service or client ID (CID) with filename "sc_manifest.xml" Custom clients without SC manifests will receive the SC manifest specified for the service, if it exists. Sample master SC manifest for a server: This is one way that a server can have custom values for properties. Here, root password, user name, user password, timezone can be found by service name in a table, using XInclude "xpointer", or taken from defaults, using XInclude "fallback": <?xml version='1.0'?> <!DOCTYPE service_bundle SYSTEM "/usr/share/lib/xml/dtd/service_bundle.dtd.1"> <service_bundle type="profile" name="name" > <service name="ai_properties" version="1" type="service"> <instance name="default" enabled="true" > <property_group name="ai" type="application" ><xi:include href="psw.xml" xpointer="element(myservice/1)"> <xi:fallback><propval name="rootpass" type="astring" value="$5$VgppCOxA$ycFmYW4ObRRHhtsGEygDdexk5bugqgSiaSR9niNCouC"/> </xi:fallback> </xi:include><xi:include href="psw.xml" xpointer="element(myservice/2)"> <xi:fallback><propval name="description" type="astring" value="default_user"/> </xi:fallback> </xi:include><xi:include href="psw.xml" xpointer="element(myservice/3)"> <xi:fallback><propval name="username" type="astring" value="jack"/> </xi:fallback> </xi:include><xi:include href="psw.xml" xpointer="element(myservice/4)"> <xi:fallback><propval name="userpass" type="astring" value="9Nd/cwBcNWFZg"/> </xi:fallback> </xi:include> <propval name="timezone" type="astring" value="US/Pacific"/> </property_group> </instance> </service> </service_bundle> The XML file containing the table with the specified values (referred to above as "psw.xml"): <itemlist> <item xml:id="someotherservice"> <propval name="rootpass" type="astring"value="ourencoded5$VgppCOxA$ycFmYW4ObRRHhtsGEygDdexk5bugqgSiaSR9niNCouC"/><propval name="description" type="astring" value="private_user"/> <propval name="username" type="astring" value="wm"/> <propval name="userpass" type="astring" value="ourencoded/cwBcNWFZg"/> </item> <item xml:id="myservice"> <propval name="rootpass" type="astring"value="ourencoded5$VgppCOxA$ycFmYW4ObRRHhtsGEygDdexk5bugqgSiaSR9niNCouC"/><propval name="description" type="astring" value="private_user"/> <propval name="username" type="astring" value="wm"/> <propval name="userpass" type="astring" value="ourencoded/cwBcNWFZg"/> </item> </itemlist> The above "psw.xml" file has properties for two different services: "myservice" and "someotherservice". The above XML source can be tested using "xmllint --xinclude --postvalid <master XML filename>" Limitations: The inclusions are resolved as the time of issuing the installadm command. This has the dual effect of validating and locking in the inclusions, and of preventing dynamic install-time processing. To be considered: a flag indicating dynamic processing of the specified SC manifest file, deferring inclusions until install time.I think this limitation is fairly serious. If I want to update an included section, how will I know what including manifests need to be republished to re-resolve the inclusions? Very concerned that this is too static to scale over the full lifecycle.
The most basic way to lessen this impact would be to store the top-level SC manifest - the one specified on the command line. This would provide names of the top-level files being included.
Another approach would be to keep names of all included files as metadata. The 'list-sc' subcommand could display the inclusion tree, as well as an information about the files: e.g., is the included file still available? does it still parse? when was it last updated? has it been updated since the 'installadm' command was launched (possibly stale)?
Still another approach would add comments to the final SC manifest specifying the source input filenames so that the 'export-sc' subcommand would display them. (This would mean that the information would appear on the client, of course, and would be useful for debugging.) The 'list-sc' subcommand could provide the same information as mentioned just above.
Is dynamic inclusion at install time preferable to static? Should we provide the option of either?
William _______________________________________________ caiman-discuss mailing list [email protected] http://mail.opensolaris.org/mailman/listinfo/caiman-discuss
