Cathy Zhou wrote:
> I think it can be implemented either way. But my understanding of the
> precedent examples, is that, the administrators has to enable the
> services explicitly in order for the service to work, for example, the
> ILB service.
>
> If we agreed we do not need to follow such precedence, I can change
> how VRRP works.
I think there is precedent the other way, though. ypinit -c for
example, implicitly enables the related NIS services. I think setting
sharenfs=yes on a ZFS filesystem implicitly enables the NFS server services.
If the only hook into a service is the SMF facility, then you should use
that. If you already have another administrative interface to enable or
disable a facility (or configure it), then you should not also require a
separate action to enable it in SMF.
- Garrett
>
> Thanks
> - Cathy
>> On Tue, 2009-12-01 at 06:29 -0500, James Carlson wrote:
>>
>>> Sebastien Roy wrote:
>>>
>>>> This case proposes that VRRP service (PSARC/2008/693 and
>>>> PSARC/2009/388)
>>>> to be disabled by default when the system boots up.
>>>> Administrators must
>>>> explicitly enable the svc:/network/vrrp:default service before they
>>>> try to use the VRRP functionality, and configure any VRRP routers.
>>>>
>>> Disabled by default seems like a perfectly reasonable answer, but why
>>> does the administrator have to enable it manually when the service is
>>> needed? The service seems to be an implementation detail. Shouldn't
>>> configuration using the supplied tool be sufficient?
>>>
>>
>> That's a valid question, and I've upgraded this to a fast-track with a
>> timer of December 07, 2009, to address it.
>>
>> -Seb
>>
>>
>>
>
