Alan Maguire wrote:
>
>>
>> Alan,
>>
>> (taking smf-discuss off the list, this is getting very ilb-specific):
>>
>> for my tests, I do the following:
>>
>> 1) to view what's in SCF:
>>
>> svccfg -s network/loadbalancer/ilb:default listprop
>>
>> and to wipe out all of that:
>>
>> ==== begin
>> FMRI=svc:/network/loadbalancer/ilb:default
>>
>> for x in `svccfg -s network/loadbalancer/ilb:default listpg | \
>> nawk '($2 ~ "application"){print $1}'`; do
>> svccfg -s $FMRI delpg $x
>> done
>> ==== end
>>
>> in your opinion, is that sufficient, or do we have to do other things
>> to assure ourselves that we're not meddling with the wrong instance of
>> the SCF DB?
>>
> I think it'd be useful for me to understand the circumstances
> that you envision needing to wipe the config out like this.
> Is this for cases where the configuration is unusable and the
> user wants to revert to the initial (blank) configuration?
> If so, I think the SMF answer would be a two-step thing:
>
> 1) ILB daemon notices config is unusable - mark service
> for maintenance (which denotes the service requires
> user intervention to fix)
not quite.
The scenario we envision this for is the analog to the kernel's panic() -
ilb daemon doesn't know how to continue (we obviously hope it won't occur,
but you never know ;-). (since ilbd only handles config issues, this would
happen upon admin action, ie when someone is "watching" ilbadm)
In that case, we don't just want to terminate ilbd, to be restarted by SMF
immediately and potentially return to the "panic" situation; rathermore, we
want to go to maintainance mode, print something alarming via ilbadm and
die. The "alarming" thing should indicate
a) that this is a rare circumstance
b) keep calm
c) save the current SCF contents (eg via the listprop command I showed)
d) wipe it
e) re-enable ilb service
(probably all via a pointer to doc ... whatever)
> 2) user runs "ilbadm revert-config" or whatever,
> and the above wiping of properties gets done.
we want to do this with non-ilb methods: if we got into a state we're
uncertain of via ilbadm, then "wiping" the configuration using the same
means may not actually get rid of all potential config remainders.
(unless we can invoke something in libscf that does that for us)
> One issue you'll need to address in the above solution -
> the properties will be removed from what's known
> as the editing snapshot, and applications should
> read their config from the running snapshot. So
> you'd need to add a "svcadm refresh ilb:default".
> Snapshots aren't explained all that well in the SMF
> docs, I've tried to augment that here:
>
> http://blogs.sun.com/amaguire/entry/smf_snapshots_or_why_didn
we'll have to check that.
> Note that it might make sense (if possible) to
> keep all the configuration properties in
> the same application property group, so
> you'd just need to delete that one property
> group.
since property groups aren't hierarchical, that's not quite so simple - we
currently use more than one.
thx
Michael
--
Michael Schuster http://blogs.sun.com/recursion
Recursion, n.: see 'Recursion'
