William, Some additional comments on version 1.4 of the doc below, and responses to your previous responses in-line.
5.1 - nit - still says "single" profile.
5.3.2 - this is just a wording nit but maybe you should call this
something else. The use of "deferred" or "first boot" to describe this
third type of XInclusion treatment seems presumptuous. From the
installer's pov, we're just placing the profile onto the installed system
with unprocessed XInclusions. Whether or not its actually processed
on first boot is out of our hands.
5.3.3 - Is it me or does the content of this section say something
totally different than the title of the section?
5.4.3.1 - There doesn't seem to be any benefit of having the option
to run the script at installadm time since there's no criteria from a
live client available then. Users can run their script with those limited
criteria you listed, outside of the installadm execution just as well,
since those limited criteria are all known as data that the user
would have to pass as options to the installadm call anyway.
Is there a particular reason why you see this as needed?
5.4.4 - I didn't comment on this last time because I wanted to hear
more about the use case for user-defined scripting first. We can
discuss this offline, but you need a little more here on what aspects
of derived AI manifests this will be leveraging. For example, derived
manifests doesn't do replacements as you're mentioning here.
5.6 - Isn't <options> for create-service and create-client the same
as {SC profiles}for set-sc? If so, why the different names?
5.6 - These options as defined imply we're associating SC profiles
to clients outside of the client/service relationship. Is this what you're
intending?
5.6 - For -p, -q, and -r, could we just allow multiples of them instead
per command instead of the argument being a comma-separated list?
5.6 - second table is not readable.
5.6.2. - Doesn't this need an argument for the name of the profile
you want to export?
5.6.4 - Not understanding why you'd name this subcommand
delete-criteria? Why wouldn't it be delete-profile to be consistent?
Also, the previous subcommands use -sc, why not name these
with -profile as well?
5.6.5 - Why not provide a way to validate just one profile as well?
5.7.2 - Since $QUERY_STRING is an interface exported by wanboot-cgi
that <script> is consuming, the format of $QUERY_STRING needs to
be defined.
5.7.* - Its still not quite clear to me if you're proposing to include the
SC profile with the initial wanbootfs that's requested (for Sparc), or
if Sparc will request an additional wanbootfs just to get its SC profile(s).
5.10 - Could use a little more. I'm still not quite clear how what you're
describing here works.
[two more comments below]
On 08/27/10 10:17, William Schumann wrote:
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.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 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 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.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..
This needs to be clarified then. The phrase "passed by reference" does not spell symlink file to me. But I would agree, it doesn't seem like we would need to support this case.
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.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 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.
I'm only seeing 5 use cases in the doc, but I think you mean 6.5 In your final note for this use case, you say "the script could be generalized so that the template variables come from the table as well." If the script could be generalized, is this something the installadm tool can support inherently, and hence the user wouldn't have to write any scripts at all to use this functionality? i.e. the user would be exposed to the syntax so that they can write these clauses in their profiles, but not have to write the scripts to process them? Hmm, in thinking about this, it would seem users would still have to provide the table and the variable names at least, and there'd be no way for installadm to know which criteria they want to use to use as a table lookup key ... just a thought, but is there way you can see this working in this way? thanks, -ethan
page 7 - "Basing SC profiles on various client criteria" - the program or script mentioned in this section is internal to theAI server correct?Correct.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.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.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.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?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 criteriaAlso, will add to the list of supported criteria: - OpenSolaris version number associated with the serviceso 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, Williamthanks, -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.odtThis 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
