Where's this plugin mentioned/documented? I can only find the task: https://access.redhat.com/documentation/en-us/red_hat_directory_server/10/html/administration_guide/dynamically-reloading-schema

So the plugin itself is pretty simple, I think it's just enable/disable, but the 'task' creation should probably be with dsconf <inst> schema, that makes the most sense I think. That might be why you can't find much about the plugin is we jjust default it to "enabled" and be done.

Hmm, I don't know where to put the enable/disable though. We can have it separately as all plugins. But I think it seems weird to me:

positional arguments:
  instance              The instance name OR the LDAP url to connect to, IE
                        localhost, ldap://mai.example.com:389
  {backend,schema,healthcheck,plugin,memberof,usn,whoami,schema_reload}
                        resources to act upon
    backend             Manage database suffixes and backends
    schema              Query and manipulate schema
    healthcheck         Run a healthcheck report on your Directory Server
                        instance. This is a safe, read only operation.
    plugin              Manage plugins available on the server
    memberof            Manage and configure MemberOf plugin
    usn                 Manage and configure USN plugin
    whoami              Manage and configure whoami plugin
    schema_reload       Manage and configure Schema Reload plugin

It neither seems very intuitive to me.

In this case user would have to do in order to enable the plugin:

dsconf instance schema_reload enable/disable/status

But if he actually wanted to perform a schema reload he would have to:

dsconf instance schema reload

Maybe both should go under "dsconf instance schema"?

But if so, how? Any suggestions?

Part of me wonders if we should allow disable/enable of this plugin anyway? It's pretty important for our server, so perhaps we should just link the reload task from the plugin into the schema command?

Sure. I'll just do it like this then.

Do we need functional tests for this on lib389 as well? Like test when we change the schema and reload it if the changes do actually take effect? Or it is tested elsewhere and all I need to do is just write the code for running the task?

IIRC it's tested elsewhere - we can just make sure the CLI works at a basic level in the test :)

Hmm, I'm not sure what you mean by "make sure the CLI works at a basic level". More specifically? Thanks.

Check that the call to "schema reload" doesn't cause the server to throw an exception I think would be enough.

I have created a new-style Schema class from DSLdapObject. I named it SchemaNew because I didn't want to break anything by renaming old one to legacy.

Why SchemaNew? Why not rename the old Schema object to SchemaLegacy? This part of the code is not widely used, so should be pretty easy to conduct this rename. I'd rather not have names like "SchemaNew" hanging around in the code base :(

Would you mind fixing this up? Thanks!

I was afraid of messing things up. Finally it seems that it was easier than I thought; I think this class is used in a single place only in lib389 and I didn't encountered it at all in 389-ds-base.

So, I made the rename and I hope it doesn't brake anything.

I confirmed it by running the lib389 tests, but not the whole 389-ds-base test suite.

I think it's okay, :) it's pretty simple.

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