Alan Maguire writes: > hi Rishi > > > Open question: Considering the above future work to include this support > > in the master SMF restarter and new properties introduced to customize > > the service advertisement is it better to create the 'advertised' > > property under a new property group 'mdns' that is not specific to a > > restarter? > > i wonder if a more "delegated restarter-agonstic" approach would be easier, > i.e. have a dedicated mdns property group as you suggest. the advantage of th > is > would be that adding advertisement to a service could simply create this prop > erty > group for the delegated restarter to pick up (if not already there), i.e. > > # boujouradm -a telnet:default > > would add the mdns property group to the telnet:default instance (with a defa > ult > name matching the service name) and restart it. the hooks in the inetd > restarter would then pick this up and communicate with the > mDNS daemon. > > i think in most cases the service name matches the /etc/inet/services > entry for port lookup, but exceptions could be handled by explicitly adding > the mdns property group. the advantage of this approach would be > that only the SMF manifests of services which have names that do not match > their entry in /etc/inet/services would have to be updated with an mdns prope > rty > group. > > each delegated restarter would still need hooks to communicate with the > mdns daemon to announce that the service is online/offline/in maintenance > state, but these hooks would not be so restarter-specific (i.e. they'd all qu > ery > the same mdns/advertised property, they'd all do nothing if there was > no mdns property group etc).
Or the mDNS daemon could use libscf to simply wait on service transitions. No restarter-specific hooks necessary. (The interfaces to do this are currently project private in libscf, but we could work with the project team to open them up at least under contract.) I'll have to look through the materials more to understand whether an mDNS daemon is required in general. > > this approach might make life easier when adding non-inetd services, > maybe i'm missing something though? thanks! Something like this sounds fairly sensible to me. liane -- Liane Praza, Solaris Kernel Development liane.praza at sun.com - http://blogs.sun.com/lianep
