Alan Maguire wrote: > hi Yifan > > comments inline below... > > yifan wrote: >> [...] >> An smf service "network/vrrp:default" will be introduced to manage the >> vrrp daemon called vrrpd. Smf instances will be dynamically created >> through libscf upon each creation of vrrp instances, the fmri of which >> looks like "network/vrrp:inst1". The creations are achieved through a >> administrative tool called vrrpadm which interacts with vrrpd to >> manipulate vrrp instances. > Sounds okay - my personal preference would be to have > a slightly different FMRI for the daemon than for the objects > it controls, but I've no idea if that's a view others might share. > So what I'm thinking is something like > > svc:/network/vrrp-management:default > > ...for the daemon, and > > svc:/network/vrrp:inst0 > ... > > ...for the objects the daemon manages. One reason for such > a separation is that different instances implicitly share > service-level properties (including dependencies). If two > instances are fundamentally different things - like a daemon > and a configuration object - I'd argue having them live > under the same service is a bit confusing, since such sharing > of configuration doesn't make sense for two different types > of thing. Just my opinion though.
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 desired feature of vrrp is to monitor health of network services and >> trigger fail-over when failures are detected. The design is that a vrrp >> smf instance could have dependency on a network service, say >> network/http:apache2, which wants to be protected, so that when it >> somehow fails, the vrrp smf instance turns to offline state which is >> expected to trigger vrrp fail-over. So far so good. > This almost sounds like the SMF monitor project which > has been discussed a few times here in the past (try > searching the smf-discuss archives for more details). > The idea of that project - which I don't believe has been > started yet - is to provide more fine-grained monitoring > of service state. I _think_ the idea is that an additional > method - a "monitor" method - can be supplied with > a given service to check its health. Maybe I'm out of > date on these details though... Is it the thread "how to get automatic notification when service"? The mechanism sounds useful but I am afraid we won't have chance to make use of it in this project ... >> [...] > I wonder - what else do these dynamic instances you're creating > do? Are they just a mechanism to catch restarts of other services? Exactly. By current design the configuration data of vrrp instances will be stored in the configuration file instead, and the dynamic smf instances will only have the dependency properties. > If so, I wonder if it'd make more sense to catch such notifications > in the vrrp daemon instead? I couldn't figure out how to achieve that. Isn't dependency the good way to catch down events of services? > (Having said that, I don't think there's > a good way to get such notifications unless you're the delegated > restarter for the service, but maybe that's changed recently though, > I'm not sure).So I think the first thing I'd like to understand > in a bit more details is what else these dynamic instances > (such as the one handling apache you describe above) need to do, > i.e. what do their start/stop methods do if anything? > If these instances are just a mechanism to catch restarts of the > services that VRRP monitors, I'm not so sure that introducing > them is the right way to go. If there are other ways that the vrrp daemon could get notifications, I agree that we don't have to rely on the smf dependency mechanism. Thanks, Yifan
