Name Already Taken on API call to update host field

Support
1

Problem:
Trying to update a field on a host, fails the api call with:

2025-02-20T15:00:33 [E|app|cfd7c538] Unprocessable entity Host::Managed (id: 103078):
 cfd7c538 |   Name has already been taken
 cfd7c538 |

Expected outcome:
The field is updated successfully.

Foreman/Proxy Versions:

rubygem-hammer_cli_foreman_remote_execution-0.3.0-1.el9.noarch
rubygem-hammer_cli_foreman_ssh-0.0.3-1.el9.noarch
rubygem-foreman_vault-2.0.0-1.fm3_11.el9.noarch
rubygem-foreman_kubevirt-0.2.0-1.fm3_11.el9.noarch
rubygem-foreman_statistics-2.1.0-3.fm3_11.el9.noarch
rubygem-hammer_cli_foreman_kubevirt-0.2.0-1.fm3_11.el9.noarch
rubygem-hammer_cli_foreman_puppet-0.1.0-1.fm3_11.el9.noarch
rubygem-hammer_cli_foreman_tasks-0.0.21-1.fm3_11.el9.noarch
foreman-obsolete-packages-1.10-1.el9.noarch
foreman-release-3.13.0-1.el9.noarch
rubygem-hammer_cli_foreman-3.13.0-1.el9.noarch
foreman-selinux-3.13.0-1.el9.noarch
foreman-3.13.0-1.el9.noarch
rubygem-foreman-tasks-10.0.1-1.fm3_13.el9.noarch
rubygem-foreman_remote_execution-14.0.2-1.fm3_13.el9.noarch
rubygem-foreman_salt-17.0.0-1.fm3_13.el9.noarch
foreman-libvirt-3.13.0-1.el9.noarch
foreman-ovirt-3.13.0-1.el9.noarch
foreman-postgresql-3.13.0-1.el9.noarch
foreman-redis-3.13.0-1.el9.noarch
foreman-service-3.13.0-1.el9.noarch
foreman-vmware-3.13.0-1.el9.noarch
rubygem-foreman_puppet-8.0.0-1.fm3_13.el9.noarch
rubygem-foreman_templates-10.0.1-1.fm3_13.el9.noarch
foreman-cli-3.13.0-1.el9.noarch
foreman-installer-3.13.0-1.el9.noarch
foreman-proxy-3.13.0-1.el9.noarch
rubygem-foreman_maintain-1.8.1-2.el9.noarch

Distribution and version:
Alma 9

Other relevant data:
I dont expect this to fail, because its just updating a host that already exists.

[root@10-222-234-226 jsparrow]# grep cfd7c538 /var/log/foreman/production.log
2025-02-20T15:00:33 [I|app|cfd7c538] Started PUT "/api/hosts/10-222-77-167.redacted" for 10.222.236.151 at 2025-02-20 15:00:33 +0000
2025-02-20T15:00:33 [I|app|cfd7c538] Processing by Api::V2::HostsController#update as JSON
2025-02-20T15:00:33 [I|app|cfd7c538]   Parameters: {"host"=>{"salt_proxy_id"=>27, "managed"=>false}, "apiv"=>"v2", "id"=>"10-222-77-167.redacted"}
2025-02-20T15:00:33 [D|app|cfd7c538] Authenticated user redacted against INTERNAL authentication source
2025-02-20T15:00:33 [D|app|cfd7c538] Post-login processing for saltforeman
2025-02-20T15:00:33 [I|app|cfd7c538] Authorized user saltforeman(Salt Foreman Admin)
2025-02-20T15:00:33 [D|app|cfd7c538] Post-login processing for saltforeman
2025-02-20T15:00:33 [D|tax|cfd7c538] Current location set to none
2025-02-20T15:00:33 [D|tax|cfd7c538] Current organization set to none
2025-02-20T15:00:33 [D|tax|cfd7c538] Current location set to none
2025-02-20T15:00:33 [D|tax|cfd7c538] Current organization set to none
2025-02-20T15:00:33 [W|app|cfd7c538] Not queueing Host::Managed: ["Name has already been taken"]
2025-02-20T15:00:33 [W|app|cfd7c538] Not queueing Host::Managed: ["Name has already been taken"]
2025-02-20T15:00:33 [W|app|cfd7c538] Not queueing Host::Managed: ["Name has already been taken"]
2025-02-20T15:00:33 [E|app|cfd7c538] Unprocessable entity Host::Managed (id: 103078):
 cfd7c538 |   Name has already been taken
 cfd7c538 |
2025-02-20T15:00:33 [D|app|cfd7c538]   Rendering layout api/v2/layouts/error_layout.json.erb
2025-02-20T15:00:33 [D|app|cfd7c538]   Rendering api/v2/errors/unprocessable_entity.json.rabl within api/v2/layouts/error_layout
2025-02-20T15:00:33 [I|app|cfd7c538]   Rendered api/v2/errors/unprocessable_entity.json.rabl within api/v2/layouts/error_layout (Duration: 2.5ms | Allocations: 3142)
2025-02-20T15:00:33 [I|app|cfd7c538]   Rendered layout api/v2/layouts/error_layout.json.erb (Duration: 2.7ms | Allocations: 3278)
2025-02-20T15:00:33 [D|app|cfd7c538] Body: {
 cfd7c538 |   "error": {"id":103078,"errors":{"name":["has already been taken"]},"full_messages":["Name has already been taken"]}
 cfd7c538 | }
 cfd7c538 |
2025-02-20T15:00:33 [I|app|cfd7c538] Completed 422 Unprocessable Entity in 310ms (Views: 3.3ms | ActiveRecord: 23.0ms | Allocations: 27445)

Host information:

[root@10-222-206-152 jsparrow]# hammer host info --id 103078
Id:                 103078
Name:               10-222-77-167.redacted
Organization:       SSNC
Location:           Location Not Set
Cert name:          10-222-77-167.redacted
Managed:            no
Installed at:
Last report:
Status:
    Global Status: Error
    Build Status:  Installed
Network:
    IPv4 address: 10.222.77.167
    MAC:          00:50:56:bc:62:29
    Domain:       redacted
Network interfaces:
 1) Id:           126256
    Identifier:   vmxnet3 Ethernet Adapter
    Type:         interface (primary, provision, execution)
    MAC address:  00:50:56:bc:62:29
    IPv4 address: 10.222.77.167
    FQDN:         10-222-77-167.redacted
Operating system:
    Operating System:       Windows 2019
    Build:                  no
    Custom partition table:
Parameters:

All parameters:
    host_registration_remote_execution => true
    host_registration_insights => false
    host_packages =>
Additional info:
    Owner Id:
    Owner Type:
    Enabled:    yes
    Model:      VMware Virtual Platform
    Comment:
2

Same issue happens if I attempt to manually edit the host in the UI.

3

Why would foreman do this?

   id   |                name                 | salt_proxy_id |         created_at         |     type
--------+-------------------------------------+---------------+----------------------------+---------------
  36131 | 10-222-77-167.redacted |               | 2024-10-17 19:10:21.259469 |
 103078 | 10-222-77-167.redacted |               | 2024-12-10 12:00:10.674996 | Host::Managed
4

Usually be default all hosts are managed under default organization and default location. Wondering if this might be the cause.

5

Interesting thought. I just checked and we have over 942 hosts with more than 1 record. Some have up to 13!!!

6

We have had this happen a few times in the past, though I never figured out under which circumstances a new host object got created erroneously. We eventually turned of the “Create new host when facts are uploaded” setting in Foreman and that stopped the creation of these host records, so it is most certainly linked to that, but I could never find what specifically causes this to happen.

7

Ya, I certainly agree that is where the issue lies. However, we need that option on (for now). I guess I could rewrite our salt enc node script to use the api to create the host first if it doesn’t exist, then turn off that option.
Thanks for the reply.