On 09/22/10 05:48, William Schumann wrote:
Ethan,
On 09/22/10 10:02 AM, Ethan Quach wrote:
On 09/16/10 11:04, William Schumann wrote:
Updated proposal. version 1.6
http://hub.opensolaris.org/bin/download/Project+caiman/System+Configuration+Project/SCProfileProposal.odt
Made some updates in response to Darren RE: clarification of AI
client criteria.
Added section
5.4.3.5 Prefabricated scripts delivered with AI, and
5.4.3.6 Process a table of CSV (comma-separated values) containing
property values
in response to Dave's request for a solution driven by a simple
ASCII-style character table. (At this point, it's modeled to run as
a user-defined script that we provide, so it might be presented
differently.)
It's a way around coding XML by separating the XML code into
templates and having all of the property data in a simple table.
It's also a way to import data from a different management utility.
Does this seem useful?
I think it's perhaps useful as an advanced use case. But to be honest,
I still find it rather complex. It would seem to me that the use of
XInclude
with the addition of what you propose in 5.4.2 gives a fair amount of the
flexibility and scalability that we're after.
Firstly, it should perhaps be noted that 5.4.2 only provides
substitution for known criteria: (e.g., not root password).
Right, but as you noted this can be used in conjunction with XInclude
to "lookup" the root password from an external table file based on one
of the known criteria.
Also, the table described here is just CSV text - values used by
XInclude must be XML-encoded. This table should be much simpler to
maintain.
[...]
The other idea is that a CSV table should be more easily generated by
management utilities that could contain this information.
For this case, I'd think management utilities could generate XML-encoded
tables just as easily since it'd be programmatic.
I wrote you about an alternative to this - installadm SC options
specifying that input comes from a table:
installadm set-sc --template=<template> --table=<table> [other
set-sc options]
The table-specific options would still be defined in the table.
The issue I have with the table is that it's defined format
doesn't seem to scale when you need the table to be used for
multiple replacement variables each based on differing and/or
intersecting criteria. You potentially end up with many rows
with repetitive column content. Have you thought about just
sectionalizing the table file so that multiple replacement variables
could be defined separately from one another?
Secondly, allowing the user to specify a python chunk seems
really awkward -- on the commandline or in a file.
5.3 - I really don't like the use of a comment as the marker to denote
inclusion time. Did you look into simply using a made up attribute
to the
<xi:include> element as our marker? In a quick test, I specified the
following in a real XML file:
<xi:include href='file:/etc/svc/profile/name_service.xml' foo='bar' />
ran it through 'xmllint --xinclude' and it resolved the xinclusion
seemingly ignoring the additional attribute. If this can actually work
this may be a better approach. It qualifies as well formed XML. It
does not interfere with the inherent Xinclude statement.
This seems a lot better than using comments.
And most
importantly, since its part of the XML, we can programmatically
process the XInclusions as we choose, using the python lxml library.
In looking at the lxml.etree.XInclude class, we can element-wise
resolve xincludes as we process a DOM, which means that we can
support a file with mix-n-matched Xinclude statements that the
user wants handled at the three various times. Thoughts?
The problem is that if the inclusion option is specified per xinclude
instance, there is no way to indicate that the profile itself is
static - i.e., copied locally into the installadm database for
previously stated reasons (section 5.3: protected, less 500 internal
server errors, etc.).
Isn't the main profile file itself always copied in? I hadn't realized this
proposal was offering that as an option to the user.
5.3.3 - At this point, this is just a wording nit, but my issue is with
the section is that it still sounds like we're only proposing to support
dynamic install-time (client request time) resolution of inclusions.
Made it clear.
5.4.3.2 - It may be beneficial if these env variable names match that
of used with derived AI manifests for the ones that intersect.
Indeed. Will add this to list of interdependencies.
AI_MKTG_RELEASE - not sure what you're intending here, but I don't
think a marketing release name ever makes it into the Solaris OS's
system info anywhere. Can you clarify what you're considering here?
Well, if it doesn't, then there's no need. Removing.
5.6 - The -o option should perhaps be -c instead, to be consistent
with add-manifest and set-criteria.
Indeed.
Also, instead of a comma separated
list, could we make it be multiple -c instead? This would make it
consistent with the -c option of add-manifest and set-criteria. In an
offline previous conversion with Frank a while back, he noted that we
should try to be consistent in that nature, among our commands.
OK. Does this also apply when more than one profile is specified? e.g.:
installadm add-sc -g -p p1.xml -p p2.xml
I would think so.
5.6.2 - Shouldn't the name of the SC profile that the user wishes to
export to stdout be specified in this command? Otherwise for cases
where there have been multiple SC profiles associated with the queried
entry, are we just going to output them all stdout, concatenated
together?
I see users issuing a 'list-sc' command, and then running the 'export-sc'
command on some sc that they listed to view/save its contents. I'm
not quite seeing what a group export of 3 profiles in a wad of output
for example, would be useful for.
The intent of this is to give a user the means of seeing what profiles
would be output for the given criteria, to try to give the user a look
at exactly what would go on an AI client. The fact that it's a wad is
less important than the added visibility. Please read on...
5.6.5 - I think I had this comment before, but I think it could be useful
for this command to take a specific profile to validate as well.
This relates to 5.6.2 in that both individual profiles and a
collection of profiles are of interest for both validation and
viewing. In the proposal, both aim at a collection and not at
individual profiles. Changing proposal to provide either.
OK.
-ethan
[5.7 - 5.9 pending ..]
Thanks,
William
_______________________________________________
caiman-discuss mailing list
[email protected]
http://mail.opensolaris.org/mailman/listinfo/caiman-discuss
