On 11/16/10 08:23, Dave Miner wrote:
On 11/15/10 09:39 PM, Ethan Quach wrote:
On 11/12/10 15:43, Dave Miner wrote:
On 11/ 5/10 10:13 AM, William Schumann wrote:
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.
I'd hope that the "regular way" becomes just using the image provided
in the pkg repository. We might even choose to dispense with
providing the ISO's in favor of a tool that generates the ISO from the
package for the cases where it's needed, though I'm not proposing to
do so right now.
Yeah, I agree with here.
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.
I would think that aliasing and updating would provide essentially
this result.
I was thinking of a slightly different use case. If we provided more
direct access to this functionality in the form of something like:
# installadm create-service -e <existing svc> ... -s <srcimg> -n
<svcname>
it would allow a user to create a fresh service for an older release or
off cycle build, yet still copy configuration (manifests/profiles) from
an arbitrary existing service. It occurred to me that the work involved
in implementing update-service would provide for much of this already.
i.e. creating a service using an existing service's config, and
validating manifests/profiles after a new image is has been put/updated
in place. With the above command, we'd just replace the "image update"
part with a fresh lay-down from srcimg, and could support either, a pkg
spec or an iso.
-ethan
Dave
_______________________________________________
caiman-discuss mailing list
[email protected]
http://mail.opensolaris.org/mailman/listinfo/caiman-discuss
