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.
Not to mention that we already implicitly started down such a path with
the current "embedded SC" implementation, since it's embedded within
general AI criteria :-)
Dave
_______________________________________________
caiman-discuss mailing list
[email protected]
http://mail.opensolaris.org/mailman/listinfo/caiman-discuss
