Using nios_next_ip in a host record is not idempotent

[evilhamsterman]

If I create a host record using the nios_next_ip option for the address subsequent runs throw and error that the record already exists. This was reported prior to the great split https://github.com/ansible/ansible/issues/51843 but still exists in the current code

- name: Create ansible-test DNS record
   infoblox.nios_modules.nios_host_record:
      name: ansible-tests.corp.qumulo.com
      ipv4addrs:
         - address:
               nios_next_ip: 10.100.0.0/16
      state: present
      provider: "{{ nios_provider }}"

dmills in dmills-remote in ansible on  gitlab-pages [$!] via 🐍 v3.9.5 (.venv)via ⍱ 
❯ ansible-playbook -i inventories/stage.ini -t dns playbooks/gitlab/gitlab.yml

PLAY [Setup Gitlab] ****************************************************************************************************************************************

TASK [Gathering Facts] *************************************************************************************************************************************
ok: [gitlab-stage.corp.qumulo.com]

TASK [Create gitlab DNS record] ****************************************************************************************************************************
[WARNING]: The value {'nios_next_ip': '10.100.0.0/16'} (type dict) in a string field was converted to "{'nios_next_ip': '10.100.0.0/16'}" (type string). If
this does not look like what you expect, quote the entire value to ensure it does not change.
changed: [gitlab-stage.example.com]

PLAY RECAP *************************************************************************************************************************************************
gitlab-stage.example.com : ok=2    changed=1    unreachable=0    failed=0    skipped=0    rescued=0    ignored=0   

Playbook run took 0 days, 0 hours, 0 minutes, 2 seconds
dmills in dmills-remote in ansible on  gitlab-pages [$!] via 🐍 v3.9.5 (.venv)via ⍱ 
❯ ansible-playbook -i inventories/stage.ini -t dns playbooks/gitlab/gitlab.yml

PLAY [Setup Gitlab] ****************************************************************************************************************************************

TASK [Gathering Facts] *************************************************************************************************************************************
ok: [gitlab-stage.corp.qumulo.com]

TASK [Create gitlab DNS record] ****************************************************************************************************************************
[WARNING]: The value {'nios_next_ip': '10.100.0.0/16'} (type dict) in a string field was converted to "{'nios_next_ip': '10.100.0.0/16'}" (type string). If
this does not look like what you expect, quote the entire value to ensure it does not change.
fatal: [gitlab-stage.corp.qumulo.com]: FAILED! => changed=false 
  code: Client.Ibap.Data.Conflict
  msg: The record 'gitlab-stage.example.com' already exists.
  operation: create_object
  type: AdmConDataError

PLAY RECAP *************************************************************************************************************************************************
gitlab-stage.example.com : ok=1    changed=0    unreachable=0    failed=1    skipped=0    rescued=0    ignored=0   

Playbook run took 0 days, 0 hours, 0 minutes, 1 seconds

[evilhamsterman]

I'd really appreciate this getting some attention. We'd really like to use Ansible with Infoblox but this defeats the whole point of using Ansible and Infoblox. If we use next_available_ip in the host record task then we have to go back and update the Ansible code after deployment. Or we have to create a record in Infoblox first and then use that in Ansible. Either way we have to do something manually after we deploy with Ansible. It's annoying for a few static systems and running Ansible manually. it's completely unmaintainable with automation and large numbers of systems.

[aroramanish2009]

Running into same problem. If they have not looked at your issue since 2021, I should not accept much help from them.

[evilhamsterman]

It's even older than that, I just recreated a bug from Ansible pre great separation that was from 2019. They really seem to miss the point of Ansible and have some very gaping holes in their features. I bet the only reason they haven't got more complaints is people probably hit this issue, give up and just ignore it.

I don't think they are paying much attention because their code that handles it is a hug mess of spaghetti. I tried to look at and see if I could write a PR but it looks like it would require almost a complete rewrite of their main IP handling code.

[evilhamsterman]

Another year another bump to remind the developers that they are completely missing the point of Ansible. We shouldn't have to manually specify and IP, jump through hoops using lookups to check if an IP is already allocated and creating a potential race condition to get a new IP. I should be able to just specify nios_next_ip: 192.168.1.0/24 in the address field and the module should handle checking if one has been allocated already. If it has been then move on if not get one