Sangeeta Misra writes: > On 03/12/09 12:13, James Carlson wrote: > >> that would imply that we're storing the information you're referring to > >> within the SMF framework ... which is not the case. As of now, all SMF > >> does > >> is start and stop ilbd, maybe store the location of the persistent config > >> (file). > >> > > As far as I understand, svccfg import /export, is used to import/export > a SMF manifest file. So I think in asking the above question, you are > assuming that configuration details of ILB ( VIP address, lb algorithm, > server group details including server IP addresses, health check details > ) are all part of the SMF manifest. Is that correct?
No, I'm not assuming it. I'm asking why it's not done that way. > If yes, what would be the benefit of such a model over our current > design( in our model the configuration details are not kept in SMF, but > in a persistent config file which ilbd/or ilbadm reads in when the ILB > service is invoked). The benefit would be that you get all of the SMF framework features (including locking, snapshotting, data typing, audited access controls, profiles, and more) "for free." > SMF does not provide any means to display the > statistics of a service. Statistics aren't configuration; they're a very different kind of data. No, SMF doesn't expose statistics. > For that the admin has to use ilbadm. Actually, it seems that we're going a different direction elsewhere in the system, so you might want to reconsider that path. For instance, the Crossbow guys are busy now breaking up 'dladm' into a separate configuration administration tool (dladm) and a statistics display tool (dlstat). > Given > that, it would easier for a user to use one interface to view, modify > ILB features than have two things to learn ( ilbadm and svccfg) I wasn't suggesting that the user necessarily would need to learn anything about svccfg. In fact, the SMF best practice *is* to provide a service-specific configuration utility (such as ilbadm), and then store the configuration data via SCF. There's an important distinction between the command used for access (the documented administrative interface) and the actual back-end storage of parameters. Just because something is stored in SCF doesn't mean that the "only" or even the "best" way to control it is through svccfg. > > SMF has 'profiles' for basic service configuration. They're being > > enhanced now to provide a lot more control over services through the > > profile mechanism, and this will be used (in turn) by NWAM to set up > > services on systems, and to switch between sets of services when > > changing "location." > > > > In addition, I believe the enhanced profile mechanism will be a part > > of how we intend to provide install-time configuration for enterprise > > types of deployments. > > > > For ILB phase 1 project we will not be providing any basic service > configuration. The admin will be required to build his config from > scratch. User experience and feedback from ILB Phase 1 , may result in > a basic service configuration down the road, but there are not plans to > have this in Phase 1 I'd still suggest a discussion with the enhanced profiles team. > One could argue that in Solaris one would use SMF to do import/export a > service, but IMO we need to design the ILB similar to something that > admins who use other commercial and opensource load balances are used > to. If SMF had provided a ways to display virtual service stats, then it > would have made sense to abandon abandon ilbadm and simply have admin > use SMF interface to configurr, modify and display various statistics of > each LB serveice of ILB. But that is not the case. I believe that this is not an accurate representation of how SMF is supposed to be factored into new system features. If I were working on this project, I'd certainly want to validate those sorts of assumptions with them. If you've already done that, then great, but since it seems we've reached an impass on philosophy, I'm not so sure we can go much further. -- James Carlson, Solaris Networking <james.d.carlson at sun.com> Sun Microsystems / 35 Network Drive 71.232W Vox +1 781 442 2084 MS UBUR02-212 / Burlington MA 01803-2757 42.496N Fax +1 781 442 1677
