@firstyear, while adding acceptance tests for AD DN plugin, I found that we don't have the default ldif for it in template-dse.ldif. Do you think it should stay that way or we can add it there (off by default, of course)?

LGTM

@vashirov I'm of two minds here. I really hate template-dse.ldif because it locks us into long-term configuration syntaxes because they aren't upgraded and come from old installs. Older installs also don't have new plugin configs added either so it's non obvious. template-dse.ldif is not documentation, it really should be "the minimal required server to make dscreate work".

I think maybe I'd prefer that dsconf ... plugin addn enable should be the correct way to "add" the required cn=config object, and we have an example ldif in documentation. I think that's the most sustainable approach long term.

@firstyear, I'm fine with the current approach. I was asking because I want to have a more robust and consistent behavior of creating and configuring plugins. Since some plugins are already present, I can configure them right away. And for some, like AD DN, I need to call .create() first to ensure that the DN exists before modifying attributes there. So maybe it's more for lib389 to handle this correctly, since we can't guarantee for sure that the plugin's DN will be present in cn=config by default.

Dynamic plugins test suite fails because of this PR, investigating.

@vashirov there is a stateful method in lib389, .ensure or something like this. It says "create or modify to make this thing look like this". I think that may be what you want here.

Really I think as a team we need to talk about getting our house in order and how we should be configuring and setting up the server and plugins, because it's such a fragmented and chaotic process today, lib389 has helped a lot, but we need to work out what's best here.

Is there anything outstanding here before we can merge?

Is there anything outstanding here before we can merge?

There were test failures in plugin test suite with my change. I need to revisit this and fix it.

389-ds-base is moving from Pagure to Github. This means that new issues and pull requests
will be accepted only in 389-ds-base's github repository.

This pull request has been cloned to Github as issue and is available here:
- https://github.com/389ds/389-ds-base/issues/3518

If you want to continue to work on the PR, please navigate to the github issue,
download the patch from the attachments and file a new pull request.

Thank you for understanding. We apologize for all inconvenience.