Hello,

do we have a reproducer? To me this sounds like: create two subnets, create a host in subnet A, edit the host and pick subnet B. DHCP orchestration will not delete reservation from A (and does it create reservation in B)?

Was the host in build mode or normal mode when it was edited?

Do you experience this with the DHCP Capsule managing ISC DHCP or is this Infoblox or a different DHCP provider?

For the record, I just tested this on nightly and it correctly deletes the host reservation and adds a new one:

server-duid "\000\001\000\001(\020k\236RT\000\265u\311";
host fern-lowen.dummy.lan {
  dynamic;
  hardware ethernet aa:bb:cc:dd:ee:f2;
  fixed-address 192.168.111.96;
        supersede server.filename = "pxelinux.0";
        supersede host-name = "fern-lowen.dummy.lan";
}
host fern-lowen.dummy.lan {
  dynamic;
  deleted;
}
host fern-lowen.dummy.lan {
  dynamic;
  hardware ethernet aa:bb:cc:dd:ee:f2;
  fixed-address 192.168.222.38;
        supersede server.filename = "pxelinux.0";
        supersede host-name = "fern-lowen.dummy.lan";
}

Note leases are not subject of any Satellite management, I am assuming by the term "lease" you actually mean "reservation" (the host record in the leases file).

Hey Lukas,

 > Was the host in build mode or normal mode when it was edited?

I don't believe they were in build mode, but I'm not sure.  In some situations, the host was built, and on the subnet for a week or so, and then moved to a different subnet.  So I assume build mode was not enabled, unless the provisioning template was edited, and the call back to confirm the build was successful was removed.  I will double check on that. 


 > Do you experience this with the DHCP Capsule managing ISC DHCP or is this Infoblox or a different DHCP provider?

1 Capsule is managing dhcp and is provisioning the server on subnet A.  Subnet B does not have a Capsule managing DHCP. 


Yes, I do mean reservation, my apologies.  

And no, I have not had a chance to test, but will do my best to test on the same version as customer.

Hey Lucas,

I too couldn't trigger this bug.  I tried a lot of combinations to trick the Capsule into not updating the file, but most ended with red errors in the Satellite UI.

The only way I could get the host to change its subnet/ip and for the Capsule not to update the dhcpd.leases file, was to uncheck "Managed" from interface and remove the Capsule as a dhcp capsule from the original subnet.  However, this seems like we are just telling Satellite/Capsule to not worry about the subnet, and the nic, therefore it seems expected for the dhcpd.leases file not to get updated with a "deleted" entry in this situation.

Hey Lucas,

We figured out the issue is caused by a puppet plugin from Satellite, that changes the subnet and ip of a host when the facts of the host changes.  It is located under Administer => Settings, named "Update subnets from facts", which causes Satellite to update a host's subnet from the facts.

Customer is manually updating the ip address of the host, runs the "puppet agent -t" on the host, and the subnet is changed from the provisioning (Capsule dhcp managed) to the non-provisioning (not-managed by a Capsule).  This successfully updates the subnet and ip address of the interface of the host from Satellite UI.  However the leases file does not update with a host delete entry as you would expect (like when someone manually makes this change from the Satellite UI).

We tested manually changing the subnet of the interface from the Satellite UI, and things worked as expected.  When we moved the host from the capsule managed subnet to the non-managed subnet, we see a host delete entry get appended to the dhcpd.leases file for the managed subnet.

Yes, I can confirm that the "Update subnets from facts" or also "Update domain from facts" can indeed break orchestration. I will propose a fix that will not perform the change if DHCP or DNS Capsule is associated with such NIC as this would break orchestration. I am opening a discussion upstream:

https://community.theforeman.org/t/rfc-turning-off-update-subnet-domain-from-facts-for-managed-interfaces/23292

Thanks for the report and the analysis, I hope we can come to some good solution.

Upon review of our valid but aging backlog the Satellite Team has concluded that this Bugzilla does not meet the criteria for a resolution in the near term, and are planning to close in a month. This message may be a repeat of a previous update and the bug is again being considered to be closed. If you have any concerns about this, please contact your Red Hat Account team.  Thank you.

This is still an issue for us.  Provisioning fails b/c we run out of leases and we have to manually have to clean up the dhcp.leases file of old smoketest builds and automated builds that change IPs.  I reported this issue in Satellite 6.8 and the issue has remained all the way through to our current version, Satellite 6.13.  We have two /23 subnets and we are still running out of IPs because of this issue. We will be updating to Satellite 6.14 next month.

Because this is an old bug I'm first going to try to summarize the (long) private conversation.

The reproducer is:

* Have 'Update subnets from facts' setting on
* Create a subnet Provision: 192.0.2.24/29 and assign a DHCP proxy
* Create a subnet Production: 198.51.100.0/24 and do NOT assign a DHCP proxy
* Provision a new machine using kickstart & PXE with an IP assigned from the Provision subnet
* After it's provisioned, change the IP address to one within the Production subnet on the machine itself
* Use a tool to send new facts (Puppet/subscription-manager) to Foreman

The expected outcome is:

* The subnet is updated to Production
* The IP is updated to the new value
* The old IP from the Provision subnet is released

The actual outcome is:

* (unclear if the subnet changed)
* (unclear if the IP changed)
* The old IP from the Provision subnet is NOT released

Some questions I can't immediately find an answer for:
* What does the fact upload change? Host audit logs should be able to answer this
* Is orchestration triggered at all? If so, why isn't the DHCP deletion triggered? Foreman's production.log and Foreman Proxy's proxy.log may be able to answer this

This BZ has been automatically migrated to the issues.redhat.com Red Hat Issue Tracker. All future work related to this report will be managed there.

Due to differences in account names between systems, some fields were not replicated.  Be sure to add yourself to Jira issue's "Watchers" field to continue receiving updates and add others to the "Need Info From" field to continue requesting information.

To find the migrated issue, look in the "Links" section for a direct link to the new issue location. The issue key will have an icon of 2 footprints next to it, and begin with "SAT-" followed by an integer.  You can also find this issue by visiting https://issues.redhat.com/issues/?jql= and searching the "Bugzilla Bug" field for this BZ's number, e.g. a search like:

"Bugzilla Bug" = 1234567

In the event you have trouble locating or viewing this issue, you can file an issue by sending mail to rh-issues. You can also visit https://access.redhat.com/articles/7032570 for general account information.

The needinfo request[s] on this closed bug have been removed as they have been unresolved for 120 days