nodegroupdefine allows a nodegroup name identical to an existing node name, but this will lead to errors

[rshawocf]

Summary

Confluent allows creating a nodegroup whose name exactly matches an existing
node's name. This produces ambiguous/colliding entries for other tools that read node and nodegroup names (e.g. Ansible dynamic inventory), since a single name then resolves to both a host and a group.

This problem might arise if an engineer mis-types a group name, or if documentation provided to engineers/users is incorrect, or if the engineer/user doesn't realise it will be a problem.

We are working on scripts to create nodes/nodegroups in an automated fashion but I think there should be safeguards against this issue as there is always a likelihood that some manual work will be done on the CLI.

Steps to reproduce

# node "wlm01" already exists and is registered
nodeattrib wlm01 all

# create a nodegroup with the SAME name — succeeds, but should probably be rejected?
nodegroupdefine wlm01

nodegroupattrib wlm01 all
# confirms the group now exists alongside the node of the same name

Names duplicated across nodes/nodegroups can also be discovered with Ansible:

ansible <host> -i inventory/confluent_plugin.yaml -m ansible.builtin.setup -a "filter=ansible_hostname"

Observed

• No error/warning from Confluent on nodegroupdefine.
• Any tool building inventory from /nodes/ + /nodegroups/ (e.g. Ansible's
  dynamic inventory) cannot distinguish wlm01 the host from
  wlm01 the group — e.g. Ansible logs:

[WARNING]: Found both group and host with same name: wlm01
and hostvar lookups keyed by that name become unreliable.

Expected

nodegroupdefine (and node creation/rename) should reject a name that
already exists as the other type (node vs. nodegroup), returning a
validation error instead of silently succeeding.

Workaround

nodegroupremove to remove the colliding group.

Environment

$ rpm -q confluent_server confluent_client

Output:

confluent_server-3.15.4-1.noarch
confluent_client-3.15.4-1.noarch

[jjohnson42]

Will go to close after package release, believed to be addressed in:
8a57216

[rshawocf]

This looks great, we could potentially look to test this fix on a development cluster next week.