Ethan,
The document has been updated in response to your and Dave's suggestions.
Still some work to be done.
Responses inline.
On 08/26/10 10:14 AM, Ethan Quach wrote:
page 5 - "Overview" - The last sentence says a single profile is
delivered, but later on in the proposal seems to indicate that you
are proposing to support multiple SC profiles. I.e. the comma
separated list of profiles specified via the -p -q or -r options on
page 9.
Yes, the intent is to support multiple profiles. Will update the doc.
page 5 - Mentioned in the doc in a couple of places is that the SC
profiles would be stored in the /etc/netboot hierarchy according to
service ID and CID. But if you're also proposing to use criteria as
the selection mechanism, what is the purpose of the hierarchy?
The hierarchy is a leftover storage model from an earlier design. It has some efficiency advantages, but since criteria-based
profiles have been added, a different storage model is in order. Will remove mention of the hierarchy from the SC profile storage
model.
page 6 - "SC profiles passed by reference" - This statement
seems false. Its seems you are supporting this via the -r option
you're proposing on page 9..
The difference between the -r option and passing profiles by reference is that in the proposal, the server always passes a profile
*file* - even with the -r (first boot) option, as opposed to a filename, link or other reference. That profile may contain a
reference to another profile or fragment of a profile (via XInclude) that is on the AI client, but I'm drawing the line at passing
references to keep the design simple; i.e., the proposal is to pass files from the AI server to the client, not references such as
pathnames or soft links.
Now, one might say that a soft link is a file. It's possible that soft links to files on the AI client are allowed, with the
understanding that they could appear as broken links on the AI server side. If there is a significant advantage to supporting this
use of soft links, it can be added.
page 6 - "Preprocesssing XInclude ..." - Is there an additional
advantage or use-case for user-defined scripts over simply
having installadm support an inherent preprocessing step of
replacing known variables? If the user-defined scripting is
only to solve the issue of resolving criteria, then the latter
would seem much more simple for users to do for the same
functionality.
Use case 8 illustrates how a user-defined script can look up properties in a normal text file according to criteria. In this case,
the property value is substituted, not the criteria.
page 7 - "Basing SC profiles on various client criteria" - the
program or script mentioned in this section is internal to the
AI server correct?
Correct.
I.e. its not the same as the would be
user-defined script described previously, so mentioning it as
program or script seems a bit confusing, or maybe just
clarifying that.
OK, will clarify. Providing criteria-based definitions should reduce the number of cases in which user-defined scripting would be
necessary. Otherwise, there is no connection between the two.
page 8 - This is related to the first comment, but if we're
proposing to use criteria as the selection mechanism for SC
profiles, what is the purpose for the association of SC profiles
at the service level and the client level?
Associating SC profiles at the service level would indicate that all AI clients requesting this service would receive the defined
profiles. Associating SC profiles at the client level would restrict their use only for a specific custom client.
When specifying profiles using installadm create-service, the service name is implied and does not have to be explicitly listed
among the criteria. Same for the client ID for custom clients defined by 'installadm create-client'. If we dispense with using the
'create-service' and 'create-client' subcommands to define profiles, using only 'set-sc' and 'add-sc' with criteria to define
profiles by service or client ID, then they don't have to be associated at the service and client levels, but the service and client
IDs would have to be explicit among the criteria.
In the end, it's just a matter of convenience, allowing the user to define profiles with one installadm command instead of two,
otherwise forcing the user to supply redundant, inelegant criteria pairs on the command line: -o service=<service> or -o CID=<cid>
Per our discussion yesterday, I will add support for server-wide SC profiles
that are included:
- if no criteria are specified, the profile is included for all AI clients
- if criteria are specified, the profile is included strictly according to
criteria
Also, will add to the list of supported criteria:
- OpenSolaris version number associated with the service
so that SC profiles defined globally in this way can be restricted by OS
version.
Also, will add an option for template preprocessing of SC profiles supporting replacement of the entire range of supported
criteria. This should relatively safely:
- improve scalability
- make static XInclude dynamic
- circumvent the need for some user-defined scripting
Thank you,
William
thanks,
-ethan
On 07/28/10 09:38, William Schumann wrote:
Resulting from previous discussions on SC profiles, a second draft document proposing changes to SC profiles is now on
opensolaris.org at:
http://hub.opensolaris.org/bin/download/Project+caiman/System+Configuration+Project/SCProfileProposal.odt
This is a complete rewrite from the initial draft. Many significant features
were reconsidered and redesigned.
Those interested in offering input about how the OpenSolaris installer
configures a system, please comment.
Thank you for your attention,
William Schumann
_______________________________________________
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
_______________________________________________
caiman-discuss mailing list
[email protected]
http://mail.opensolaris.org/mailman/listinfo/caiman-discuss
