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?
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?
Dave
_______________________________________________
caiman-discuss mailing list
[email protected]
http://mail.opensolaris.org/mailman/listinfo/caiman-discuss
