On Fri, Nov 23, 2007 at 02:09:13PM +0800, Max Zhen wrote: > > > Peter Memishian wrote: > > > > Hmm...maybe we can change the name like: > > > > network/datalink:default --> network/datalink-management > > > > network/ip:default --> network/ip-management > > > > > > > > So, we split the management services from individual datalink/ip > > instances. > > > > And we use the same name that Clearview is using now for datalink > > > > management service. > > > > > > > > > > > that separation would definitely help from an implementation > > > perspective - the management services and datalink/interface instances > > > will have different dependencies and exec methods - it would certainly > > > make life easier if they could inherit these from the service level. > > > > Our foremost concern should be the resulting administrative model, rather > > than the internal complexity of the implementation. Is there an > > administrative justification for having foo and foo-management services? > > > My understanding is that each foo is representing a network interface in > this system (for layer 2 or 3). > While foo-management (or foo:default) is representing a daemon that can > generate/destroy foo. > Logically, they're of different things and there is not much to share in > service level.
I was initially uncomfortable with the split; I felt that the extra foo-management services were a little clumsy and was concerned about creating confusion with too many different services. Having the foo:default instance represent the management aspects instead felt more streamlined. But when I talked it over with Dave Powell, who is much more smf-clueful than I, he made a point very similar to Max's: the default instance isn't really meant to be used in that way. All the instances of a service should be similar, "peer" entities. Trying to graft management capabilities into the default instance really doesn't fit the general smf model. > So, maybe it is good, > if we split them, for: > a) from a administrative view, the name of the instance better shows > that foo is not foo-management. Do > not try to manage foo-management the same way as foo. Right. Enabling the datalink-management service is pretty different from enabling a specific datalink instance; the former is taking a pretty broad, system-wide action, while the latter is much more focused in its impact. Dependencies are also cleaner this way: the policy engine service instances dependson the datalink and ip management services, while the individual datalink and ip instances depend on the policy engine service. -renee > b) as pointed out by Alan, it helps from an implementation perspective. > > Max > _______________________________________________ > nwam-discuss mailing list > nwam-discuss at opensolaris.org > http://mail.opensolaris.org/mailman/listinfo/nwam-discuss
