Description of problem: Setting facts foreman_location or foreman_organiation are not recognized anymore when provisioning a new host. The same process worked in Sat6.1 and Sat6.0: [crash] root@li-lc-1589:~# sudo facter -p foreman_organization Hilti [crash] root@li-lc-1589:~# sudo facter -p foreman_location HAG [crash] root@li-lc-1589:~# sudo puppet agent -t -v --noop Info: Creating a new SSL key for li-lc-1589.hag.hilti.com Info: Caching certificate for ca Info: csr_attributes file loading from /etc/puppet/csr_attributes.yaml Info: Creating a new SSL certificate request for li-lc-1589.hag.hilti.com Info: Certificate Request fingerprint (SHA256): 33:C...:99 Info: Caching certificate for li-lc-1589.hag.hilti.com Info: Caching certificate_revocation_list for ca Info: Caching certificate for ca Warning: Unable to fetch my node definition, but the agent run will continue: Warning: Error 400 on SERVER: Failed to find li-lc-1589.hag.hilti.com via exec: Execution of '/etc/puppet/node.rb li-lc-1589.hag.hilti.com' returned 1: Info: Retrieving plugin Info: Loading facts in /var/lib/puppet/lib/facter/service_provider.rb Info: Loading facts in /var/lib/puppet/lib/facter/hilti_oracle.rb Info: Loading facts in /var/lib/puppet/lib/facter/puppet_vardir.rb Info: Loading facts in /var/lib/puppet/lib/facter/pe_version.rb Info: Loading facts in /var/lib/puppet/lib/facter/package_provider.rb Info: Loading facts in /var/lib/puppet/lib/facter/hilti_provisioning.rb Info: Loading facts in /var/lib/puppet/lib/facter/hilti_hardware.rb Info: Loading facts in /var/lib/puppet/lib/facter/facter_dot_d.rb Info: Loading facts in /var/lib/puppet/lib/facter/hilti_aws.rb Info: Loading facts in /var/lib/puppet/lib/facter/root_home.rb Info: Loading facts in /var/lib/puppet/lib/facter/hilti_os.rb Info: Caching catalog for li-lc-1589.hag.hilti.com Info: Applying configuration version '1466436636' Notice: Finished catalog run in 0.06 seconds The host is added to Sat6, but the location and organization fields are empty: [crash] root@li-lc-1578:~# curl -K /opt/hoici/etc/sat6/curl-hoici.conf "-HContent-Type: application/json" "-d{\"per_page\":9999,\"search\":\"name=li-lc-1589.hag.hilti.com\"}" -XGET https://localhost/api/v2/hosts | jq . | egrep '(organization|location)' "location_name": null, "location_id": null, "organization_name": null, "organization_id": null, The settings with the fact name to use are set: [crash] root@li-lc-1578:~# curl -K /opt/hoici/etc/sat6/curl-hoici.conf "-HContent-Type: application/json" "-d{\"per_page\":9999}" -XGET https://localhost/api/v2/settings | jq . | grep -A1 tion_fact "name": "location_fact", "value": "foreman_location", -- "name": "organization_fact", "value": "foreman_organization", Version-Release number of selected component (if applicable): How reproducible: Steps to Reproduce: 1. Make sure the default location and orgianzation settings are kept empty (defaults after installation) 1. Create org A and B 2. Create location A and B 3. Goto a new host the and create facts foreman_location and foreman_organization, set both to B 4. Register a new host 5. Check location and organization association Actual results: location and organization not set Expected results: host associated with location B and organization B Additional info:
The reason for this is happening is we started creating host records as part of subscription-manager registration (importing rhsm facts), and when puppet facts arrive right after that, there is a check for not to import facts twice in a short period (1 minute by default). Next time the puppet agent runs (in half hour) on the host, the location should be set properly. It should be enough to wait a minute for that. The core problem is the `last_compile` column, that stores the time of last facts import, regardless of the source. There are two things we can do codewise: 1. short-term: set host.update_column(:last_compile, nil) in Katello's subscription facet so that this import doesn't influence the puppet import 2. long-term: every facts type has it's own last_compile equivalent so that they don't influence each other
It's also worth mentioning, that this means the puppet facts don't get imported at the first puppet call when subscription-manager call is part of provisioning.
Created redmine issue http://projects.theforeman.org/issues/15524 from this bug
The quickfix proposed to Katello https://github.com/Katello/katello/pull/6153
Upstream bug component is Content Management
Notes on how to reproduce: The custom facts can be provided by putting a specific file to /etc/facter/facts.d/, like this: ``` cat <<SCRIPT > /etc/facter/facts.d/foreman_facts.sh #!/bin/bash cat <<EOF foreman_organization=My Organization foreman_location=BRQ EOF SCRIPT chmod a+x /etc/facter/facts.d/foreman_facts.sh ``` Facter should pick it up and you should than be able to see it when calling `facter -j`
The facts can be a simple yaml file instead of the shell script. Below is our live example. The content is created during the kickstart %post, just before calling puppet for the first time. [crash] root@li-lc-1444:~# cat /etc/facter/facts.d/foreman.yaml # # Foreman registration facts created by hoi-config-subscription # # foreman_server: li-lc-1017.hag.hilti.com foreman_organization: Hilti foreman_location: HAG foreman_hostgroup: crash/IPS/Test-6.8-ci foreman_activationkey: hg-crash::IPS::Test-6.8-ci
Verified! @Sat 6.2 Snap 19.1 GA Steps Followed : 1. Kept default location and organzation settings empty 2. Created Org A and Org B 3. Created location Loc A and Loc B 4. Provisioned a new host from satellite onto libvirt CR. 4. In new host, created facts foreman_location and foreman_organization, set both to Org B and Loc B resp. 4. Register a new host with satellite by running puppet agent on host and signed the cert on satellite. Observed: The new host has org and loc associated in custom facts file in host(i.e here Org B and Log B resp), which is as expected. So moving this bz to verified.
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/RHBA-2016:1501