Ethan,
On 09/ 2/10 10:45 AM, Ethan Quach wrote:
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?
The title is rather a summary of the different options, including the one
mentioned in the content. Will reword.
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.
In the case of a custom client, the MAC address, which is the criterion
uniquely identifying the AI client, is know at installadm time.
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?
Needed? No. There are some advantages, as I wrote in response to Dave Miner, but I don't think it is necessary and will withdraw
the option.
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.
Derived AI manifest processing can be used as-is. Will supply a use case.
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?
Indeed, they need to be reconciled.
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?
Yes, that is what the global associations are about. See -g.
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?
Sure. Why is this preferable?
5.6 - second table is not readable.
Margins gone awry.
5.6.2. - Doesn't this need an argument for the name of the profile
you want to export?
A profile doesn't always have a name - it can be generated as stdout from a
script.
5.6.4 - Not understanding why you'd name this subcommand
delete-criteria? Why wouldn't it be delete-profile to be consistent?
delete-criteria is more to the point, but unnecessary. Will change to
delete-profile.
Also, the previous subcommands use -sc, why not name these
with -profile as well?
Yes, they should be the same, but why not stick with 'sc', since it's more
concise and to the point (System Configuration)?
5.6.5 - Why not provide a way to validate just one profile as well?
Good idea.
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.
OK.
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).
That's actually a bit of a problem, since when wanbootfs is requested under SPARC, the criteria are unavailable, since it is done in
firmware. To implement this in SPARC, the wanbootfs will have to be executed once more of the microroot is available. Will mention
this.
5.10 - Could use a little more. I'm still not quite clear how what you're
describing here works.
Will bake longer.
[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.
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.
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.
OK.
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.
I'm only seeing 5 use cases in the doc, but I think you mean 6.5
Indeed
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?
To accomplish this as in the use case, we would either have to make installadm dependent on the Cheetah package, require that the
user install Cheetah, or at least support some equivalent of the #if...#then...#else directives in the template.
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?
One simple way: taking the first line as variable names, if the name is the name of a criteria environmental variable, this
indicates that the value in the column must match the value of the environmental variable. For this example, the first line would be:
AI_CID psw
0101 pass1
0102 pass2
So if the CID were 0102, the value 'pass2' would be substituted for 'psw' in
the template.
Criteria could be used in complex logical expressions;
e.g., AI_CID=${CID} && (AI_ZODIAC=${AI_ZODIAC} || AI_SERVICE != ${AI_SERVICE}).
To represent this, say that first line is used solely for the logical expression, and that the logical expression must be a template
for a valid Python expression. For second line, the columns are named. The first three columns could be AI_CID, AI_ZODIAC,
AI_SERVICE, and the rest of the columns could be the values to be substituted for user-defined template variables: e.g., psw
represents the root password in the example.
So, line 2 would define the columns:
AI_CID AI_ZODIAC AI_SERVICE psw username userpassword
The user data would follow:
01000102030405 pisces myservice <encoded root password> jack <jack's
encoded password>
01000102030406 scorpio myservice <another encoded root password> ian <ian's
encoded password>
...
For each line in the text file, the substitutions are made in <logical expression>, then it is evaluated as a Python logical
expression. if <logical expression> is True, substitute the column values for the named template variables and generate a profile
and exit.
Perhaps this could be done more easily with database and database query instead
of text file and Python logical expression.
So, it is not outrageously complicated to implement. Does it add sufficient
value to justify it?
William
_______________________________________________
caiman-discuss mailing list
[email protected]
http://mail.opensolaris.org/mailman/listinfo/caiman-discuss
