The design document for profiles in AI has been updated to reflect design
changes and clarifications. Feedback is sought.
Version 1.12
http://hub.opensolaris.org/bin/download/Project+caiman/System+Configuration+Project/SCProfileProposal.odt
Newly proposed: profiles and profile-generating commands can be given a name on the command line. The name is provided with the -p
<name> option in the create-profile command. If the name is not provided, the name will default to the basename of the profile file
or first command argument. The name must be unique within an AI service. Subsequent profile commands use this name. See section
5.6.1.1
Change in handling of dynamic profiles: propose that the top-level profile file specified on the command line for dynamic profiles
will be copied into the database, instead of just being a reference to a file maintained by the user.
Advantages of storing only a reference (formerly proposed):
- user can freely modify the file at any time
- a profile listing would expose the external reference simply by displaying it
Disadvantages of storing only a reference:
- user can break the profile file at any time in a number of ways
- architecturally, adds another case with its own set of details to code for
Advantages of copying the top-level profile file into the database (as now
proposed):
- less complicated architecture - dynamic profiles are stored the same as static: only the templating and inclusions are performed
at different times
- profile is validated each time with create-profile
Disadvantages of copying the top-level profile file into the database:
- external references require XInclude syntax or custom scripting unnecessarily
- to view external references (XInclude) in a profile, the user must export the
profile
- presently no edit or update profile command exists
- it conflicts conceptually with the simple (former) distinction between static and dynamic profiles: static profiles being
completely internal, and dynamic profiles being completely external
It was decided that edit-manifest, edit-profile, update-manifest, update-profile subcommands, which can be simultaneously released
for consistency, can mitigate the disadvantages.
There is still one design detail that has not received feedback - the mechanism to specify static vs. dynamic vs. first boot
includes; i.e., when template variables are substituted and XIncludes are resolved (see section 5.2). The present proposal is that
the indicator is embedded in a comment:
<!-- AI[inclusion=installadm|dynamic|inhibit] -->
There are some fairly obvious problems with this kind of specification.
What I think would be preferable is to have service_bundle(4) DTD extended to permit a tag reserved for use by the installers, with
an attribute to specify this inclusion. It could look like this:
<install inclusion='installadm|dynamic|inhibit' />
It is much more desirable to have a solution that can be validated against the service_bundle DTD to aid in development and
debugging of profiles.
Some small design changes were made in subcommands, section 5.6:
- delete-profile must name profiles explicitly with the service, and no prompting occurs. Batch deletion can be added later in
concert with manifests
- validate-profile always dumps the output to stdout, with all inclusions and templating. If errors occur during DTD validation
after inclusions, the output displays the inclusions so that line numbers in the validation error messages match those of the
profile output.
- export-profile is used only to dump the exact contents of a profile with no
validations or substitutions
- installadm list -p output is now completely consistent with installadm list -m
Section 5.9.1 specifies more details in the AI client/server interaction, the
AI client processing, and the CGI profile locator.
A new section 5.9.1.3 describes the AI client script that can be controlled
through options.
Unfinished: update to reflect design changes in client authentication:
set-client-auth
In particular, feedback on a new install-only tag in the service_profile DTD,
which can be used to indicate when to perform inclusions.
Thank you for your attention,
William
_______________________________________________
caiman-discuss mailing list
[email protected]
http://mail.opensolaris.org/mailman/listinfo/caiman-discuss
