On 03/25/09 08:56, Michael Schuster wrote: > Jan, > > here's a few notes. > >> 1. ilb will have one single instance in SMF framework: >> svc:/network/loadbalancer/ilb:default >> 2. persistent configuration of ilb is saved in SCF. >> 3. rules, servergroups and healthcheck objects will be property >> groups for the >> ilb instance. When user use ilbadm to create them, a new property >> group will >> be created in SCF. When user destroy them, the property group will >> be deleted >> from SCF. >> 4. When user ilbadm uses to change the configuration, the change >> saves to SCF >> implicitly, unless user uses '-t' to state the configuration is >> temporary. > > we recently got rid of -t, so, though not strictly wrong, this doesn't > apply to us any more. > >> 5. 'ilbadm import' reads from a file and override what is in SCF, >> meaning that >> all existing property groups will be deleted, and new property >> groups will be >> created based on the content of the file. > > this is in direct contradiction to what we have now: as the spec has > it, you need to *explicitly* remove all configuration if you want to > start afresh.
Where in the spec does it say this? I think ilbadm import<filename> should replace the contents of persistent conf in SCF that of the file. > >> 6. 'ilbadm export' reads from SCF and output all property groups of >> ilb instance >> to a file in certain format. This format is readable to 'ilbadm >> import'. >> 7. user can use svcprop(1) to get ilb configuration. But should NOT use >> svccfg(1M) to change ilb configuration. >> 8. use 'svccfg import/export' is not equivalent to 'ilbadm >> import/export' and >> cannot be used exchangeable. If user wants to import/export ilb >> configuration, 'ilbadm import/export' should be used. 'ilbadm >> import' cannot >> read output from 'svccfg export', vice versa. >> 9. When daemon starts up, it reads from SCF to get configuration. >> There will be >> empty configuration when the first time daemon starts. >> >> Below is a sample layout of the ilb property groups/properties: >> >> prop-group name | property name | property type | property value >> ------------------------------------------------------------------------- >> >> rule123 status boolean disabled/enabled >> vip net-v4-addr v4 IP address >> vip6 net-v6-addr v6 IP address >> port astring port range >> ipversion int 4/6 > > a) why two seperate fields for vip6 vs vip? > b) is it really necessary to store the IP version? this information is > inherent in the VIP. > > thx for the writeup > Michael
