This looks much better, thanks Cathy and Seb.
+1 on the revised specification.
-- Garrett
Sebastien Roy wrote:
> On Tue, 2009-12-01 at 10:49 -0800, Cathy Zhou wrote:
>
>> Okay then. I will update the case material and let you know.
>>
>>
>
> Cathy has provided an updated spec that addresses the issue raised that
> a cleaner architecture would not require the administrator to directly
> manipulate the state of the VRRP SMF service. I've placed a "spec.txt"
> file in the case directory, and pasted it in-line here. The timer is
> reset to expire on December 22nd.
>
> Disable VRRP service by default:
>
> This case proposes that the VRRP SMF service (PSARC/2008/693 and
> PSARC/2009/388)
> be disabled by default when the system boots up. The
> svc:/network/vrrp:default service will be automatically enabled when
> the first VRRP router is created by the "vrrpadm create-router"
> subcommand, and the service will be automatically disabled when the
> last VRRP router is deleted by the "vrrpadm delete-router" subcommand.
>
> A solaris.smf.manage.vrrp authorization will be introduced which is
> required to enable/disable the VRRP service. This authorization will be
> assigned to the "Network VRRP" and "Network Management" profile.
>
> This would address the problem that - currently - with VRRP service being
> enabled by default, in a shared-stack zone (where VRRP service is not
> supported), the VRRP service goes directly to the maintenance state and
> prompts annoying warning messages.
>
> This is also in-line with how other non-essential services work in
> Solaris.
>
> Interface Table
> ===============
>
> Interface Classification Comments
> ================== ============== ========
> solaris.smf.manage.vrrp Committed Authorization required to
> authorization enable/disable VRRP service
>
>
>
