hi Michael
Michael Schuster wrote:
> On 05/28/09 08:21, Alan Maguire wrote:
>> Sangeeta Misra wrote:
>>> On 05/28/09 05:29, Alan Maguire wrote:
>>>> Sangeeta Misra wrote:
>>>>>
>>>>>
>>>>> In ILB project, the persistent configuration is kept in the SCF
>>>>> framework and a user would use svcadm to enable/disable the ILB
>>>>> service. My question is, in the event that the ILB service,
>>>>> experiences a fatal error, is there a programmatic way to put ILB
>>>>> service in maintainance mode ( to prevent the service from going
>>>>> into a cycle or restart followed by fatal error)?
>>>> If the ILB service daemon can detect such fatal errors
>>>> once it has daemonized, you can use the libscf function
>>>>
>>>> smf_maintain_instance(ILB_FMRI, SMF_IMMEDIATE)
>>>>
>>>> (where ILB_FMRI points at the ILB service instance)
>>>>
>>>> ...to kill the associated running processes and put the
>>>> instance into maintenance. If there are fatal conditions
>>>> detectable before daemonizing, simply exit with
>>>> errorcode 95 (SMF_EXIT_ERR_FATAL).
>>>>
>>>> Hope this helps,
>>>>
>>>> Alan
>>> Thanks. Also after the service automatically goes into maintainance
>>> mode, we would like to have the user save the ILB config ( and
>>> provide that to us, so we can recreate the problem) and then wipe
>>> out the ILB service configuration in scf to start fresh.
>>> Assuming this is possible with SCF, how can the user do this ? Do
>>> they need to save a image of a shipped ILB config ( which is really
>>> enpty config) before they configure ILB , so at a later time they
>>> can revert back to that config?
>>>
>> hmm, one approach that might be worth investigating
>> - assuming all the config is in properties contained
>> in the ILB service instance - would be the use of SMF
>> snapshots (read-only views of the properties
>> associated with an instance). If I recall, the snapshot
>> interfaces (to create named snapshots and attach
>> to them) are private libscf functions, so I think
>> you'd need an ARC contract to use them, but they
>> might provide a useful method for archiving
>> and retrieving previous configuration views.
>
> 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)
2) user runs "ilbadm revert-config" or whatever,
and the above wiping of properties gets done.
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
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.
Alan
