I created a custom fact on a registered host: <pre> $ cat /etc/rhsm/facts/override.facts { "custom.fact": "2222" } $ subscription-manager facts --update Successfully updated the system facts. </pre> This fact, while it shows up in the UI on the facts page, does not persist itself into candlepin. I would guess that non-custom fact updates are similarly ignored. Facts sent to either /rhsm/facts or /api/hosts/facts need to be persisted to candlepin, where applicable.
Created from redmine issue http://projects.theforeman.org/issues/17002
Upstream bug assigned to jsherril
Moving this bug to POST for triage into Satellite 6 since the upstream issue http://projects.theforeman.org/issues/17002 has been resolved.
Verified on Satellite 6.3 SNAP 10: satellite-6.3.0-16.0.beta.el7sat.noarch, tfm-rubygem-katello-3.4.4-1.el7sat.noarch - registered client -created /etc/rhsm/facts/override.facts containing: { "custom.fact": "2222", "custom.fact2": "3333" } # subscription-manager facts --update Successfully updated the system facts. #subscription-manager facts ... cpu.topology_source: kernel /sys cpu sibling lists custom.fact: 2222 custom.fact2: 3333 ... - also confirmed that the dynflow task included Actions::Candlepin::Consumer::Update to update the facts
Since the problem described in this bug report should be resolved in a recent advisory, it has been closed with a resolution of ERRATA. For information on the advisory, and where to find the updated files, follow the link below. If the solution does not work for you, open a new bug report. https://access.redhat.com/errata/RHSA-2018:0336
Since the problem described in this bug report should be resolved in a recent advisory, it has been closed with a resolution of ERRATA. > > For information on the advisory, and where to find the updated files, follow the link below. > > If the solution does not work for you, open a new bug report. > > https://access.redhat.com/errata/RHSA-2018:0336