Bug 1950431

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.