Probably, it makes sense to have the same filtering for _create operation. We also print the attributes there.

Probably, it makes sense to have the same filtering for _create operation. We also print the attributes there.

Done, please review...

There is a use case to display this though, which is containers need to display the randomly generated directory manager password as part of the instance setup. But that's the only exception.

There is a couple of more lines in _create that logs the attributes.
https://pagure.io/389-ds-base/blob/master/f/src/lib389/lib389/_mapped_object.py#_834
https://pagure.io/389-ds-base/blob/master/f/src/lib389/lib389/_mapped_object.py#_830

https://pagure.io/389-ds-base/blob/master/f/src/lib389/lib389/_mapped_object.py#_864 (which leads to Entry.update() method that has log.debug in it)
https://pagure.io/389-ds-base/blob/master/f/src/lib389/lib389/_entry.py#_261

I think it makes sense to clear them too as long as we clean the thing up.

There is a use case to display this though, which is containers need to display the randomly generated directory manager password as part of the instance setup. But that's the only exception.

Maybe we can check if it's containerized installation and only then print the password

Or will it be enough to just add an additional output in dscontainter itself?
If it is the intended way to use DS with the containers, it will be enough, right? @firstyear

Please, also have a look at what I've commented on having a common display method in the issue.

For the dscontainer, same as Simon, I think we should just print the DM password explicitly when necessary (i.e. not expect the insides of lib389 to do that for us), too.

There is a use case to display this though, which is containers need to display the randomly generated directory manager password as part of the instance setup. But that's the only exception.

Containers need to read the debug logging? Maybe there should be a CLI option to display it properly? Which debug logging statement in the source does a container need? I would like to understand this requirement a bit more. You can always set the DEBUGGING flag to display it as well.

All changes made, please review...

@mreynolds The log is set to a high level in container builds out of the box, and sent to stdout for docker logs. Saying this there could be better ways to handle this situation - mainly that I need to implement environment configuration of the directory manager password, which would remove the need for this at all.

I think we don't need it anymore

The rest looks good! Ack

The rest looks good! Ack

@spcihug, I added a change to setup.py where if we are in a container we still print the root DN password. In containers we generate a random password, and it needs to be recorded in the logs or else it is useless.

Please review one last time...

Made some more changes suggested by @mhonek. Please review...

Probably, it should be display_log_data

The rest LGTM!
I'd give @firstyear chance to review the containerized part too though (if it's what he wanted or not).

:thumbsup:

Ack from me here too :)

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

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.