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.

> 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
-- 
Michael Schuster        http://blogs.sun.com/recursion
Recursion, n.: see 'Recursion'

Reply via email to