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.
DescriptionFabian von Feilitzsch
2016-07-18 14:50:39 UTC
Description of problem:
This is a known interaction in Rails (< 4.1.6) between ActiveRecord::Base#becomes and ActiveRecord::Base#save!. The issue is that the save! call creates an UPDATE like this:
UPDATE "hosts" SET ... WHERE "hosts"."type" IN ('Host::Managed') AND "hosts"."id" = 18 [...]
The WHERE clause there matches nothing, because the record in the database still has a type of Host::Discovered. An UPDATE on an empty set doesn't raise an error, so execution continues, and the transaction is not rolled back. This means, if you convert a host from discovered to managed and then save! it inside a transaction, all of the SQL statements that handle deleting the discovered attributes, adding entries to hosts/puppetclasses/operating systems/hostgroups etc succeed, and at the end you are left with a broken discovered host with no attributes, that can't even be deleted because of database constraints.
This is only an issue in Rails versions <= 4.1.5, it was fixed with this commit in Rails 4.1.6: https://github.com/rails/rails/commit/257d65ed2ceb14dca6b1319355ed4f8a73540498 . Here is the associated issue: https://github.com/rails/rails/issues/14785
Version-Release number of selected component (if applicable):
6.2.0
How reproducible:
100%
Steps to Reproduce:
1. Create a discovered host
2. Inside a transaction
a. Use the HostConverter.to_managed to convert the host from discovered to managed
b. Call host.save!
Actual results:
After the transaction, the host is of type Host::Discovered, but its attributes have been nilled out. Hostgroups/puppetclasses/operating systems all have entries related to the discovered host, which prevents me from deleting it.
Expected results:
After the transaction, the host is of type Host::Managed
Additional info:
from foreman-rake console, I ran ActiveRecord::VERSION::STRING and it output "4.1.5". If we can bump up to any Rails version >= 4.1.6, this issue should go away without any additional work.
Fabian, thanks for report and deep investigation.
We encountered similar problems in the upstream, we haven't figured out and we removed explicit transactions from the codebase as a result. Current stable version Foreman 1.12 does not have it, also we ship it against Rails 4.2.5.
But Satellite 6.2 is a different story. The explicit transaction removal patch did not make it there yet and we still use Rails 4.1.5 version which is affected as you found out. Therefore Satellite 6.2 is affected and we need to handle this.
Description of problem: This is a known interaction in Rails (< 4.1.6) between ActiveRecord::Base#becomes and ActiveRecord::Base#save!. The issue is that the save! call creates an UPDATE like this: UPDATE "hosts" SET ... WHERE "hosts"."type" IN ('Host::Managed') AND "hosts"."id" = 18 [...] The WHERE clause there matches nothing, because the record in the database still has a type of Host::Discovered. An UPDATE on an empty set doesn't raise an error, so execution continues, and the transaction is not rolled back. This means, if you convert a host from discovered to managed and then save! it inside a transaction, all of the SQL statements that handle deleting the discovered attributes, adding entries to hosts/puppetclasses/operating systems/hostgroups etc succeed, and at the end you are left with a broken discovered host with no attributes, that can't even be deleted because of database constraints. This is only an issue in Rails versions <= 4.1.5, it was fixed with this commit in Rails 4.1.6: https://github.com/rails/rails/commit/257d65ed2ceb14dca6b1319355ed4f8a73540498 . Here is the associated issue: https://github.com/rails/rails/issues/14785 Version-Release number of selected component (if applicable): 6.2.0 How reproducible: 100% Steps to Reproduce: 1. Create a discovered host 2. Inside a transaction a. Use the HostConverter.to_managed to convert the host from discovered to managed b. Call host.save! Actual results: After the transaction, the host is of type Host::Discovered, but its attributes have been nilled out. Hostgroups/puppetclasses/operating systems all have entries related to the discovered host, which prevents me from deleting it. Expected results: After the transaction, the host is of type Host::Managed Additional info: from foreman-rake console, I ran ActiveRecord::VERSION::STRING and it output "4.1.5". If we can bump up to any Rails version >= 4.1.6, this issue should go away without any additional work.