>> Alan Maguire wrote: >> >> [...] >> >> Sounds making sense to me. I am not sure I understand the role of the >> default instance correctly. In what case a service would have a >> default instance and at the same time some other specific instances >> under it? > > One reason is that we might have an OpenSolaris-supplied > daemon alongside an alternative - e.g. svc:/network/routing/ripng:default > and svc:/network/routing/ripng:quagga.
OK. > [...] > > The VRRP design doc at > > http://www.opensolaris.org/os/project/vrrp/vrrp_design.pdf > > mentions that you will need to modify start methods of > VRRP-managed services such as apache. Couldn't you > modify the stop methods too, adding a > "svcadm refresh vrrp-management". and then the daemon > could catch the HUP signal and reassess. Actually we thought more about this and felt that the solution of modifying methods of other services is kind of a hack. The proposal of making the dependency chain of "vrrp:inst0 -> http:apache2 -> vrrp:default" was supposed to be an alternative of that hack. The doc should have been updated. I just remove that section from the doc to avoid confusion. > > > I guess the right answer here depends on how people feel > about having a lot of VRRP instances that are just there > to monitor dependency state. Thanks! This raises another question. Suppose we don't need the dependency mechanism (using other notification scheme like David suggested in another post), is it conventional to use dynamic smf instances to mannage vrrp configuration instances? When we were making the design, we thought it was natual to match each vrrp instance to an smf instance, but it seems that might be incorrect. Thanks, Yifan
