Re: Deleting overlays from cn=config

[Ralf Haferkamp <rhafer@suse.de>]

On Donnerstag, 5. Juni 2008, Howard Chu wrote:
> Ralf Haferkamp wrote:
> > Hi,
> >
> > as back-config does currently not have support for the delete
> > operation (config_back_delete() just returns 
> > LDAP_UNWILLING_TO_PERFORM currently) I am trying to figure out what
> > is needed to get at least delete support for simple overlays (e.g.
> > ppolicy or memberof) running.
>
> Very brave of you. ;)
>
> > What I am currently doing is:
> > - renumber the indexes of the siblings of the overlay that's going
> > to be deleted
> > - remove the CfEntryInfo of the overlay from the internal config
> > tree - remove the Entry from the underlying LDIF database
> >
> > Additionally I need to remove the overlay's slap_overinst structure
> > from the overlay list of the backend and in case it was the last
> > overlay, restore the original BackendInfo structure and delete the
> > SLAP_DBFLAG_GLOBAL_OVERLAY flag from the BackendDB structure of the
> > underlying database (for global overlays). Currently I use the
> > overlay_destroy_one() function for this task. This also calls the
> > db_destroy() hook of the overlay which should take are of free
> > resources held by the overlay.
> >
> > I am a bit unsure about the db_destroy() part. Is that enough or is
> > it needed to call the db_close() hooks (when provided by the
> > overlay) before calling db_destroy()? Did I miss something else? Is
> > anybody else currently working on this?
>
> You should call the db_close() hook first.
Ok. I implemented that in a separate function (overlay_remove()) now. 
Basically that calls the db_close and db_destroy hooks, removes the 
overlay from the oi_list and cleans up the BackendDB structure when the 
last overlay is being removed.

I have some preliminary code for back-config delete support ready I 
think. It currently only supports overlays which do not instantiate 
child objects (pcache, translucent) and does not touch any data the 
overlay might have created in the underlying database.

I hope to be able commit that code during the next days. Should it be 
hidden behind #ifdefs for now? (Probably be enabled with "LDAP_DEVEL")

> > Up to now I am testing this only with some simpler overlays
> > (memberof, pcache), I assume that deleting overlays that
> > instantiate their own databases (like pcache, translucent(?)) might
> > get a little more hairy.
>
> Right. We need to distinguish between tearing down due to a normal
> shutdown, which should leave underlying data intact, and tearing down
> due to removal...
Thinking about this again, if we agree that removing config entries 
should not touch any data, as previously suggested in this thread, we 
probably don't need to make this distinction. Though we would need to 
decide whether back-config should make in implicit subtree delete for 
overlays that instantiate their own database or if the admin should 
take care of cleaning up the config tree in the correct order.

An additional hook that could be used to do some config-related cleanup 
in overlays/databases and that allows to check whether the overlay can 
be deleted at all, as suggested by Hallvard, might still be useful 
though. 

-- 
Ralf