I've got a question. Are all plugins supposed to be updatable on the fly without stopping / starting the server? If so, this plugin only validates its config on startup, but not when we alter its values on the fly. Should we fix it on the server or it is meant to be like this?

I've got a question. Are all plugins supposed to be updatable on the fly without stopping / starting the server?

Yes and no. We started implementing a dynamic plugin feature, but most plugins were written at a time when "dynamic" updates were not allowed.

If so, this plugin only validates its config on startup, but not when we alter its values on the fly. Should we fix it on the server or it is meant to be like this?

It's not a bug in DS, but more of a lack of functionality in that plugin. A 389-ds-base ticket should be opened to address it.

Ok, so I'll work on this first, then do the dsconf integration. Otherwise the server will not do syntax validation for us and we'll have to implement it on the lib389 side (which we don't want).

https://pagure.io/389-ds-base/issue/49338

@mreynolds I have dynamic plugins sorted for v4 (I have a patch for certmap that makes them threadsafe and all) so this will be possible very soon.

As for the config, I think you are right it needs validation added. Could we add this as proper objectClass / syntaxes, or do we need more specific types?

As for the config, I think you are right it needs validation added. Could we add this as proper objectClass / syntaxes, or do we need more specific types?

The thing is that config validation does exist but is only run at startup right now. So, I was thinking of modifying the plugin in a way that it will also validate config on-the-fly as well.

The one issue here is that we need to register a new preop modify function to check if the config being modified is for the plugin. I'm a bit worried about the extra overhead that will be created for every modify operation - so we need the "plugin detection" to be very efficient, or not do it at all.

I think there is an easier solution. I can't comment quickly here, but for now, don't worry about online changes. I'll write up a longer response to this soon but it is possible.

So I think we should leave this alone for a bit. Right now in the certmap ticket, I decided that I'm going to write this as a new poc of the plugin v4. In the process. I learnt about the plugin v3 api.

We have had a long standing dream of "dynamic plugins". Where you can enable/disable the plugins live, and no affect running operations.

reading the existing plugin v3 code, I have come to the conclusion the current design is not possible to be made thread safe nor scalable. As a result, in another ticket I have started to work ona plugin v4 management system which from day 1 will support dynamic plugins. Today, this already works and I have a simple demo plugin that can be enabled/disabled live with a completely thread safe behavioural model.

To achieve this, the plugin's config can be loaded at enabled/disable, and each plugin instance has a private data region (which is protected the same way as the plugin struct itself). So this mean that if you change the plugins config region it acts as a disable/enable process. Older threads still continue to use the existing config as the time of the operation start defined, but new calls will use the new instance.

This means you can write your plugin to have zero locks because the framework has a 100% guarantee to the thread safety around these functions.

So, summary: Don't both doing this. Let's wait for plugin v4 to land, then when we re-link this plugin to the new v4 framework, we will gain this behaviour for free, with no extra work needed.

For reference reading see:

http://www.port389.org/docs/389ds/design/plugin-v4.html
http://www.port389.org/docs/389ds/design/transactional-operations.html
http://www.port389.org/docs/389ds/design/certmap-ipa.html

Depends on #92 for the tests to pass: https://pagure.io/lib389/issue/92

commit 709d572
To ssh://git@pagure.io/lib389.git
2a50b9d..709d572 master -> master