Description of problem:

After PXE provisioning a host on a subnet for which Satellite manages DHCP, the host cannot be re-provisioned without manually clearing its DHCP lease from the Satellite.
 

How reproducible:

100%
 

Is this issue a regression from an earlier version:

No, but it was initially reported on Satellite 6.10.7 and was not fixed.
 

Steps to Reproduce:

1. Deploy a Satellite and configure it for PXE provisioning, including creating a subnet, domain, and compute resource. The Satellite should manage DHCP for any provisioned hosts.

2. Enable and sync the BaseOS/AppStream repos, Satellite client repo, and BaseOS/AppStream kickstart repos for a RHEL version.

3. Add the repos to a content view and publish the content view.

4. Create an activation key, associate the synced repos with the key, and override the Satellite client repo to 'Enabled' on the key.

5. Create a hostgroup containing all objects created in the previous steps.

6. Use the hostgroup to create a new VM on the compute resource.

7. Put the host in build mode and allow the provisioning process to complete.

8. Put the host in build mode again and reboot it.

Actual behavior:
Rebuilding the host fails with the following error:

[I|app|718f82a2] Backtrace for 'Failed to perform rollback on Remove DHCP Settings for satellite.example.com - ERF12-6899 [ProxyAPI::ProxyException]: Unable to set DHCP entry ([RestClient::Conflict]: 409 Conflict) for Capsule https:/satellite.example.com:9090/dhcp' error (ProxyAPI::ProxyException): ERF12-6899 [ProxyAPI::ProxyException]: Unable to set DHCP entry ([RestClient::Conflict]: 409 Conflict) for Capsule https://satellite.example.com:9090/dhcp

Removing the entry for the provisioned host from /var/lib/dhcpd/dhcpd.leases on the Satellite and restarting dhcpd.service allows the rebuild to proceed successfully.

Expected behavior:
A provisioned host can be rebuilt without manually modifying DHCP leases.

Business Impact / Additional info:

This issue was originally reported in https://bugzilla.redhat.com/show_bug.cgi?id=2129033 but was eventually autoclosed. I encountered it while verifying SAT-29975. It is likely that customers affected by SAT-29975 will encounter this issue as well.