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<[email protected]>
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
_______________________________________________
Freeipa-devel mailing list
[email protected]
https://www.redhat.com/mailman/listinfo/freeipa-devel
