On 11/12/10 15:43, Dave Miner wrote:
On 11/ 5/10 10:13 AM, William Schumann wrote:
As a result of efforts to make management of AI manifest and SC profiles
more similar, changes have been made to the user interface, section 5.6
'installadm options and subcommands'.
add-sc adds profiles
set-sc changes criteria for profiles
The basename(1) of the profiles and commands will be used as a reference
name once the profile or command is stored in the database. The basename
must be unique within a service; i.e., a service can have only one
profile with a given basename.
Is this aligned with the recent changes in handling of AI manifest
naming?
I've looked at this, and it is in alignment with the AI manifest
naming. Profiles don't have an internal name field that we can
specifically use for naming purposes like AI manifests do, so they
essentially fall back to an alternate form of naming, which is to use
the file name itself. For derived manifest (scripts), we're following
the same logic.
A difference with profiles and manifests is that when adding a manifest,
there's an option on the command line to name the manifest
specifically. We're not proposing to support that with profiles because
the subcommand to add profiles supports adding multiple profiles at a
time, and so associating a name doesn't quite fit there.
export-sc and validate-sc have been expanded and documented in more
detail.
Added section 5.8 Logging
There has been some discussion about allowing the indefinite re-use of
profiles, particularly across large releases. My original view on this
was that the user would have to take responsibility for the validity of
profiles across releases, updating them as necessary. Ethan argues that,
since SMF services can undergo fundamental changes over time, we should
not all a profile to remain indefinitely. One way of preventing this is
to force profiles to be associated with AI services, which links them to
particular releases. This could be a nuisance for the sysadmin that
installs from development releases - with each release, commands would
have to be issued to configure profiles, even if no changes occur in
profiles. The prevailing viewpoint is that a more cautious choice of
forcing profiles to be associated with a service is the best option
so far.
The changes in the ISIM project should help alleviate the issue of
re-configuring profiles, as the profiles can be associated with
aliased services (such as the default service) to provide the
operational stability that is desired here. Do we believe that will
be sufficient?
I think that depends on if we think users will be more inclined to use
update-service to create a new service when a new release becomes
available, or if they'd just download the media for each release and
create a service from that the regular way.
For the latter, I wonder if we should just supply a user interface for
copying an existing service's config when creating a new service, so
that users can access that functionality directly.
-ethan
Dave
_______________________________________________
caiman-discuss mailing list
[email protected]
http://mail.opensolaris.org/mailman/listinfo/caiman-discuss
_______________________________________________
caiman-discuss mailing list
[email protected]
http://mail.opensolaris.org/mailman/listinfo/caiman-discuss
