[Freeipa-devel] [PATCH] 905 add plugin framework to updater

[Rob Crittenden]

Alexander Bokovoy wrote:
> On Wed, 16 Nov 2011, Rob Crittenden wrote:
>> There are two reasons for the plugin framework:
>> 1. To provide a way of doing manual/complex LDAP changes without having
>>     to keep extending ldapupdate.py (like we did with managed entries).
>> 2. Allows for better control of restarts.
>>
>> There are two types of plugins, preop and postop. A preop plugin runs
>> before any file-based updates are loaded. A postop plugin runs after
>> all file-based updates are applied.
>>
>> A preop plugin may update LDAP directly or craft update entries to
>> be applied with the file-based updates.
>>
>> Either a preop or postop plugin may attempt to restart the dirsrv
>> instance. The instance is only restartable if ipa-ldap-updater is
>> being executed as root. A warning is printed if a restart is
>> requested for a non-root user.
>>
>> Plugins are not executed by default. This is so we can use
>> ldapupdate to apply simple updates in commands like ipa-nis-manage.
>>
>> rob
>
>> > From e8c632c0a17c5fad3792d4f741976161d245fec6 Mon Sep 17 00:00:00 2001
>> From: Rob Crittenden<rcritten at redhat.com>
>> Date: Wed, 16 Nov 2011 15:37:56 -0500
>> Subject: [PATCH] Add plugin framework to LDAP updates.
>>
>> There are two reasons for the plugin framework:
>> 1. To provide a way of doing manual/complex LDAP changes without having
>>     to keep extending ldapupdate.py (like we did with managed entries).
>> 2. Allows for better control of restarts.
>>
>> There are two types of plugins, preop and postop. A preop plugin runs
>> before any file-based updates are loaded. A postop plugin runs after
>> all file-based updates are applied.
>>
>> A preop plugin may update LDAP directly or craft update entries to be
>> applied with the file-based updates.
>>
>> Either a preop or postop plugin may attempt to restart the dirsrv instance.
>> The instance is only restartable if ipa-ldap-updater is being executed
>> as root. A warning is printed if a restart is requested for a non-root
>> user.
>>
>> Plugins are not executed by default. This is so we can use ldapupdate
>> to apply simple updates in commands like ipa-nis-manage.
> ACK though I have few considerations, perhaps asking for a
> separate patch.
>
> This patch adds Updater namespace available in all contexts albeit
> populated only in 'updates'/'installer' modes. I wonder if we could
> re-factor the API class code so that until you have called finalize(),
> you can add more namespaces. This would prevent need to modify basic
> initialization every time new namespace is added -- especially given
> that namespaces like Updater are specific to single utility.
>
> I know, technically you could simply replace api.register by a new
> instance and dispose the old one before going to finalize()...
>
> Another thought is to allow API to accept list of pairs (context,
> path) to simplify loading plugins. By default 'ipalib' plugins would
> be loaded, and for others, API.add_plugins(context, path) would be
> adding more, then API.load_plugins() would iterate over these pairs
> and if context is the same as in API.env, load them.
>
> This way plugins will be truly generic and we'll gain ability to use
> per application plugins without any additional changes in the core
> framework.
>

My original intention was to have the updater in its own completely 
separate api, and that is how I initially coded it. I had to abandon it 
though due to wanting to re-use ldap2.py in ipaserver. We do lots of 
'from ipalib import api' and this doesn't work if you have your own api.

I considered replacing register as well but gave up on that avenue as well.

Rebased, pushed to master.

rob