Note: This bug is displayed in read-only format because
the product is no longer active in Red Hat Bugzilla.
Red Hat Satellite engineering is moving the tracking of its product development work on Satellite to Red Hat Jira (issues.redhat.com). If you're a Red Hat customer, please continue to file support cases via the Red Hat customer portal. If you're not, please head to the "Satellite project" in Red Hat Jira and file new tickets here. Individual Bugzilla bugs will be migrated starting at the end of May. If you cannot log in to RH Jira, please consult article #7032570. That failing, please send an e-mail to the RH Jira admins at rh-issues@redhat.com to troubleshoot your issue as a user management inquiry. The email creates a ServiceNow ticket with Red Hat. Individual Bugzilla bugs that are migrated will be moved to status "CLOSED", resolution "MIGRATED", and set with "MigratedToJIRA" in "Keywords". The link to the successor Jira issue will be found under "Links", have a little "two-footprint" icon next to it, and direct you to the "Satellite project" in Red Hat Jira (issue links are of type "https://issues.redhat.com/browse/SAT-XXXX", where "X" is a digit). This same link will be available in a blue banner at the top of the page informing you that that bug has been migrated.
Take three hosts, add them into foreman via API. Then try and remove them. The first deletes fine, but the subsequent deletions fail. The problem is in file , line 196. When the subnet gets searched, the 1st host is not found, and then the entire subnet array is returned to the delete function, which then throws an error.
Pull request coming.
Moving to POST since upstream bug http://projects.theforeman.org/issues/6412 has been closed
-------------
Dominic Cleal
https://github.com/theforeman/smart-proxy/pull/175
-------------
David Swift
Copying the description I just wrote into github, as it explains this behavior better:
A small correction - if it fails to find the DHCP record of a deleted host in the subnet under evaluation, it will not attempt to delete it from the subnet under evaluation. This allows it to carry on, and actually delete the record that is intended.
The problem arises due to the evaluation of DHCP records with a status of 'deleted'. These records are evaluated against the subnet that contains the actual host we want to delete, and if they are found, they are removed prior to executing the target deletion.
In the case that triggered this bug, the record with the DHCP deleted status was originally in a different subnet before it was removed. On a subsequent delete run for a second host, the previously deleted host could not be found in the subnet under evaluation, and line 198 never returned a value. This left the return value of find_record_by_hostname as the result of subnet.records.each (an array), which then caused the subnet.delete call to throw an error.
A better fix might be to track the subnets of hosts with a DHCP status of deleted, but this gets the job done without added complexity.
HTH.
-------------
Anonymous
Applied in changeset smart-proxy:commit:57ea7e82f68395c61ab0515ea331423c9f4ac5ea.