If we remove slapd- frominstance_name here then it will not find slapd-localhost section in ~/.dsrc on the next line (it will be looking for localhost)

I think we should make it more flexable and allow user to have both formats in ~/.dsrc. With and without slapd- prefix.

If we remove slapd- frominstance_name here then it will not find slapd-localhost section in ~/.dsrc on the next line (it will be looking for localhost)
I think we should make it more flexable and allow user to have both formats in ~/.dsrc. With and without slapd- prefix.

Here's the issue, .dsrc is basically undocumented. On the wiki it shows you ONLY use instance name (without slapd-). Since there was a single source of truth i just left that as it, but I will see what I can do to make it more robust...

It just looks inconsistent to me... If we allow both slapd-localhost and localhost in CLI but dsrc accepts only localhost.
I think we should change the part of the wiki...

JFTR: This naming prefix, already discussed.... how do you distinguish the slapd-x and slapd-slapd-x, when the tooling is flexible, when user specifies slapd-x? Sure we shouldn't allow creating such an instance but that does not fix the fact that someone already has such an instance (or even created it by other means than our tooling). The looser we go the bigger trouble await us. We should be clear about what is an instance-name and what is a serverid (as in the prefixed one) and not mix those two, preferably ceasing from requiring user to have to think about it (aka, present only the instance-name) unless they have to debug something.

I feel most of this should really be addressed in the docs - not in the code. I will make .dsrc processing more flexible, but I think we just need to release note that you should not use "slapd-" in your instance name, and prevent new instances from using it (have to check if that was done already)

Okay changes made to make dsrc instance name handling more robust, please review...

The change looks to remove 'slapd-' prefix from serverId and instanceName (unless dsrc contains such prefix for instanceName). Looking at src/lib389/lib389/lint.py many messages display examples with 'dsconf slapd-xxx...'. Is it expected ?

The change looks to remove 'slapd-' prefix from serverId and instanceName (unless dsrc contains such prefix for instanceName). Looking at src/lib389/lib389/lint.py many messages display examples with 'dsconf slapd-xxx...'. Is it expected ?

The code now handles all cases where the supplied ID has slapd- or it doesn't, and we now can handle the server IDs in .dsrc which uses slapd- or not.

There is nothing wrong with using slapd-instance from the CLI, but the code needs to properly handle both cases (including how we interact with the .dsrc file).

I agree code should handle both case. My concern is that it looks we are trying to promote instance_name without 'slapd-' prefix but at the same time lint.py (healthcheck ?) will display message with this prefix.

I'm assuming this is to handle dsrc with a section of [slapd-localhost] not just [localhost] ?

I'm assuming this is to handle dsrc with a section of [slapd-localhost] not just [localhost] ?

Correct, this code allows dsrc to use "localhost" or "slapd-localhost"

LGTM. Ack

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/3964

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.