On 07/21/10 05:04 PM, Dave Miner wrote:
On 07/21/10 07:34 AM, Ethan Quach wrote:
On 07/19/10 12:34, Dave Miner wrote:
On 07/19/10 07:35 AM, William Schumann wrote:
On 07/14/10 09:47 PM, Dave Miner wrote:
On 07/14/10 10:13 AM, William Schumann wrote:
Given options for locations of SC manifests previously addressed:
0) AI manifest
1) wanboot.conf
2) sc_manifest/ directory in hierarchy
0) AI manifest is unsuitable as the only means of specifying SC
manifests since it forces an association and a dependency that
may not
apply to all users.
1) wanboot.conf is unsuitable for reasons given previously.
2) sc_manifest/ directory in hierarchy - this would require a
command
set for maintaining the files and the order in which they are
processed
on first boot. This is not prohibitive, but not elegant.
After discussion with Ethan, proposing a solution that combines
features
of the others. Storing and sending single SC manifest file to the
client
would simplify matters. XInclude can be used to perform inclusions
from
multiple sources on the AI server side, which would improve
scalability.
installadm command additions:
Specifying an SC manifest with installadm subcommands, where
<sc_manifest_file> is either a path or URL specification:
when creating an AI service:
create-service ... [-s<sc_manifest_file>]
for a custom client, upon creation of the client or to modify an SC
manifest for an existing client:
create-client ... [-s<sc_manifest_file>]
to change an SC manifest associated with an existing service, a new
installadm subcommand is created:
modify-service -s<sc_manifest_file>
To delete SC manifests, the "-S" option (rather than "-s") is
specified
in all of the above.
I'm still wondering why we wouldn't want to use criteria for
configuration manifests in the same way we do for the AI manifest.
This scheme seems to leave only per-service or per-client behavior
without the other dimensions that the criteria design allows for.
Would you explain in more detail, both generally and specifically,
what
criteria you would like to see?
Here I'm operating on the principle that congruity between the
capabilities for associating installation manifests and configuration
manifests would be a good thing. I don't have a specific example in
mind, but think that any differences between them should be
justifiable based on some principle.
The principle I have been going by is that install configuration (the
AI manifests) and system configuration (the SC profiles) represent
two different things and the belief is that the criteria we've defined,
which are client attributes (mostly hardware attributes), help
classify install configuration into categories that can be used by the
server as the selection mechanism to serve that configuration. In
looking at criteria, it didn't seem like they were generally applicable
to classify system configuration. For example, criteria such as cpu
type or memory size didn't seem to have any relevance to select
system configuration. The criteria that did seem relevant were
ones that'd identify specific clients, hence the proposal to specify
configuration manifests with the the client specific association (as
a simplified usage of such criteria).
I can't identify one offhand, though I recognize that sysid was less
flexible than I'm suggesting here.
Admittedly, the assumption I have been going by above is
predominantly based on the set of sysid configuration. We are
allowing for the potential for a much larger set of configuration
to be specified now (as compared to sysid) so perhaps there are
cases where the full set of criteria might be useful, but those cases
just haven't been apparent to me.
That's exactly the issue from my perspective: we previously had a very
limited set of configuration that could be expressed, and it was
primarily client-specific. By moving to a more extensive and
extensible mechanism, that seems to change the equation to allow for
broader, attribute-based application of configuration and leads me to
conclude that these things (AI manifest and configuration profile) are
more like than different.
Given that at least some of the SMF properties appearing in SC manifests
are sensitive from a security standpoint (most notably, passwords),
criteria-based selection of the SC manifest and any properties from
tables, etc., should be resolved on the server side. This is a major
difference between AI and SC manifests.
A similar syntax used for AI manifests can be applied on the server side
for SC manifests. From Derived Manifests design document:
installadm add-manifest -m <manfiest/script> -n <svcname> [ -c
<criteria=value|range>, ... | -C <critieria.xml> ]
The criteria specification can be identical for SC manifests.
The source of the criteria on the server is quite different: aside from
any networking information that can be gleaned from the HTTP connection,
the HTTP QUERY_STRING could provide additional criteria. To make the
criteria consistent, the QUERY_STRING could be standardized to contain a
known set of criteria.
Processing of a criteria.xml input file could be done with the same code
used for the AI manifests. The same goes for criteria-matching code run
at install time. Also for criteria listings.
This brings the discussion to AI manifest derivation: is SC manifest
derivation desirable? The only specific requirement related to this is
scalability. This thread has proposed many different methods of
derivation for SC manifests, including replacement tags, document
generators (like Cheetah), user-defined scripts, but there has been no
feedback on this subject of having some kind of programming available
for the sysadmin to generate SC manifests.
Are derived manifests as proposed for AI useful for generating SC manifests?
SC manifests, being processed on the server side, can more easily make
use of XInclude processing to improve scalability, also discussed in
this thread in some detail. The main limitation I see is that the
XInclude processing is static - although there is logical branching in
XInclude, there is no external (environment) variable processing, so you
still need N different top-level manifest files to have N unique manifests.
Ethan and I have not been able to agree on an approach that combines
maximum scalability with ease-of-use and other issues. Options
discussed to produce an SC manifest file include:
1) simple XInclude processing
2) XInclude processing with replacement tags representing criteria
3) client scripting, passing all available criteria as input to the
client script
4) leveraging AI derived manifests
I favor supporting client scripting, which would allow the client to
choose among many available document or text generators. Ethan's point
has been that such generators are not normally used by sysadmins and it
would be easier for them and therefore preferable to leverage AI derived
manifest code.
William
_______________________________________________
caiman-discuss mailing list
[email protected]
http://mail.opensolaris.org/mailman/listinfo/caiman-discuss
