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).
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.
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.
>
> 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.).
>
> 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
> 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.
>
> [5.7 - 5.9 pending ..]
>
Thanks,
William
--
This message posted from opensolaris.org
_______________________________________________
caiman-discuss mailing list
[email protected]
http://mail.opensolaris.org/mailman/listinfo/caiman-discuss
