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.
Some corrections and clarifications are in there.
considering changes:
I would also like to remove SC profile options from installadm
create-service/create-client and have a separate command set. The
main reason is that, as the option list grows for
create-service/client, it becomes more complicated and harder to
rollback if an error is encountered at some late phase in execution of
the installadm command. It's also more difficult for the user to have
long option lists. No functionality would disappear - just separate
command lines.
This sounds reasonable to me. The augmentation of
create-service/create-client to accept these options can always be
added later if needed and doesn't seem to impact the design at all.
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. 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?
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.
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.
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?
5.6 - The -o option should perhaps be -c instead, to be consistent
with add-manifest and set-criteria. 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.
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.
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.
[5.7 - 5.9 pending ..]
thanks,
-ethan
_______________________________________________
caiman-discuss mailing list
[email protected]
http://mail.opensolaris.org/mailman/listinfo/caiman-discuss
