Ansible user module fails when group parameter matches name parameter (e.g. creating user & group name)

Question

Trying to create an Ansible playbook to create a user (user module) on RH/Cent system (e.g. useradd).

The playbook fails anytime I include the group parameter despite setting the group value to match the "name" parameter value for the new user. If I leave out the group parameter/value, the playbook works.

Should the group parameter NEVER be used when creating a user with their own primary group that matches their user name (same values)?

If so, and the group parameter is designed to be omitted in such use case, why do so many Ansible Galaxy examples build the groups before the users and add the group user there? In other words, why add the users group name ahead of the user account in those cases other than assigning a different primary group?

- name: "Adding testuser_01 user"
user: 
  append: yes
  # authorization: 
  comment: "testuser_01"
  create_home: yes
  expires: -1
  # Starting at Ansible 2.6, modify user, remove expiry time 
  # Had a bug until 2.6.4 but now fixed.  
  # Currently supported on GNU/Linux and FreeBSD.
  # CentOS /etc/default/useradd is empty string by default. 
  force: no
  generate_ssh_key: no
  group: 'testuser_01'          # Optionally sets the user's primary group (takes a group name).
  groups: nixadm
  # hidden: no
  # MacOS only - optionally hide the user from the login window and system preferences. Defaults yes
  home: /home/testuser_01
  # local: no                   # Read docs and check support
  # login_class:                # Optionally sets the user's login class, a feature of most BSD OSs.
  move_home: no
  name: testuser_01
  non_unique: no 
  password: "{{ mypw }}"
  password_lock: no 
  # profile:                    # Sets the profile of the user. Currently supported on Illumos/Solaris.
  remove: no
  # role:                       # Currently supported on Illumos/Solaris.
  # seuser:                     # Optionally sets the seuser type (user_u) on selinux enabled systems.
  shell: /bin/bash
  # skeleton: 
  # ssh_key_bits: 
  # ssh_key_comment: 
  # ssh_key_file: 
  # ssh_key_passphrase: 
  # ssh_key_type: 
  state: present
  system: no
  uid: 1001 
  update_password: on_create
register: testuser_01_added

Answer 1

You can have a look at what happens internally in ansible for you distro

After reading the source code of the module, the answer to your question is, in the context of CentOS:

• If you specify a primary group (whatever it is), this group must exist prior to running the module
• If you don't specify a primary group, the module will rely on useradd to automagically add the user to a group with the same name. If that group already exists, the module will take care of adding the -N flag to bypass any potential error.

That being said, I would not rely on any of those mechanisms and would systematically create the needed groups prior to using them explicitly in the user module because:

1. it will not make much difference in terms of running time on your overall playbook.
2. it is easier to read and understand by someone picking your code months after (including you).
3. it is more agnostic and would work on a much wider variety of OS if needed (macOS, *BSD, ...) reproducing the same result (idempotency) where defaults might be different (e.g. adding new users to the users system group...)