Yifan Xu wrote: > 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 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. >>> 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 ... > > Okay. >>> [...] >>> >> 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. > > I believe the general policy is to discourage SMF instances that don't actually do anything, but I suppose from some perspective these instances do actually do something. I've got an alternate suggestion below.... >> 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? > It is - it's just that creating instances just for catching down events seems a little heavyweight to me. >> (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. > > 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. 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! Alan
