Use ldap_attrs

[lvps]

$ ansible-lint
[DEPRECATION WARNING]: community.general.ldap_attr has been deprecated. Use 
community.general.ldap_attrs instead. This feature will be removed from community.general in version 
3.0.0. Deprecation warnings can be disabled by setting deprecation_warnings=False in ansible.cfg.

[lvps]

Things have finally broken in Ansible 3.0.0, an update is needed very soon

[b00ga]

Just fyi, CentOS 8 with ansible from EPEL is broken now because EPEL only has Ansible 2.9.23 and optional install for ansible-collection-community-general @ version 3.1.0. According to the docs (https://docs.ansible.com/ansible/latest/collections/community/general/ldap_attrs_module.html), _ldapattrs wasn't introduced until community-general 3.3.0.

I'm messing around a lot with Vagrant and it's option to locally install ansible on the created VirtualBox VM, and that only knows (out-of-box) to do "dnf install ansible". There are options for me to tweak things, and I'll have to do that, but this is just another instance of the pain users are experiencing with the new ansible versioning and package split. (I think a lot of package managers are falling behind and freezing on 2.9.x).

[lvps]

Yeah, and I also find very annoying that ldap_attr and ldap_attrs coexisted for a very short time. I couldn't even figure out when one was introduced and when the other was removed, initially.

If you're still on Ansible 2.9 or old versions of the collection, you can use the 3.1.x version of this role, I plan to maintain that series for a while with bug fixes. I had to update the role because things were breaking for me on Arch Linux, which now has Ansible 2.11 and collections 4.2.0 it seems...

[b00ga]

Totally makes sense. I've been tearing up and down CentOS8 vagrant VMs, and it suddenly broke yesterday (because of this change). I initially tried to get in the latest Ansible, but that was too painful with the install tooling that vagrant currently supplies, and I ended up doing exactly what you suggested (pinning version in my requirement.yml).

And yes, the new split has got a lot of people confused. I think I finally nailed it all down last night when digging into this. Here's what I've gathered for my own sanity in case it is helpful. Ansible versions 2.9, 2.10 and 2.11 are currently supported (and for EL7/EL8 it appears Red Hat and EPEL are somewhat pinned on 2.9). See the table at the end of this docs section: https://docs.ansible.com/ansible/devel/reference_appendices/release_and_maintenance.html#ansible-core-release-cycle

For 2.9 and earlier, releases were controlled by Ansible (the project) but include content maintained by Ansible (the proiect) and Ansible (the community). If there were fixes to community-maintained code (which most commonly was in modules), then all those fixes needed to wait for Ansible (project) to decide on a new release before most people would see them (typically months turnaround time).

Starting with 2.10, ansible was split from a monolith into two major components, representing Ansible (project) and Ansible (community) maintained bits. The ansible (project) part was named ansible-base (and more confusingly changed to ansible-core for 2.11 forward) and maintains the current 2.x versioning. Ansible (community) started their own release of the modules maintained by the community and can be updated separately from ansible-core and has it's own versioning.

Ansible (community) is actually a curated set of point-in-time versioned releases of a bunch of individually maintained ansible collections that can all be maintained and released on their "owners"/maintainers timelines. When you install "ansible" now, you get a specific version of ansible-core and the set of versions of Ansible community modules associated with that ansible versioned release. This is a little clearer if you look at the release notes for an Ansible release, like here https://github.com/ansible-community/ansible-build-data/blob/main/4/CHANGELOG-v4.rst#changed-collections