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

Alexander Bokovoy abokovoy at redhat.com
Mon Nov 21 08:21:39 UTC 2011


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.

-- 
/ Alexander Bokovoy




More information about the Freeipa-devel mailing list