It looks like Puppet doesn’t really work. It appears to assign the class (at least no error is returned) and Puppet runs, but then it doesn’t apply the class so /etc/motd isn’t updated.
It seems the puppet server couldn’t get the ENC from Foreman
puppetserver.log:
2021-07-19T22:16:43.649Z WARN [qtp2135865030-35] [c.p.p.ShellUtils] Executed an external process which logged to STDERR: Error retrieving node pipe-foreman-server-nightly-centos7.n62.example.com: Net::HTTPNotFound
Check Foreman's /var/log/foreman/production.log for more information.
2021-07-19T22:16:43.711Z ERROR [qtp2135865030-35] [puppetserver] Puppet Server Error: Failed to find pipe-foreman-server-nightly-centos7.n62.example.com via exec: Execution of '/etc/puppetlabs/puppet/node.rb pipe-foreman-server-nightly-centos7.n62.example.com' returned 1:
uri:classloader:/puppetserver-lib/puppet/server/execution.rb:50:in `execute'
uri:classloader:/puppetserver-lib/puppet/server/execution.rb:14:in `block in initialize_execution_stub'
/opt/puppetlabs/puppet/lib/ruby/vendor_ruby/puppet/util/execution.rb:222:in `execute'
/opt/puppetlabs/puppet/lib/ruby/vendor_ruby/puppet/indirector/node/exec.rb:35:in `execute'
/opt/puppetlabs/puppet/lib/ruby/vendor_ruby/puppet/indirector/exec.rb:19:in `find'
/opt/puppetlabs/puppet/lib/ruby/vendor_ruby/puppet/indirector/node/exec.rb:17:in `find'
/opt/puppetlabs/puppet/lib/ruby/vendor_ruby/puppet/indirector/indirection.rb:223:in `find'
/opt/puppetlabs/puppet/lib/ruby/vendor_ruby/puppet/network/http/api/indirected_routes.rb:138:in `do_find'
/opt/puppetlabs/puppet/lib/ruby/vendor_ruby/puppet/network/http/api/indirected_routes.rb:54:in `block in call'
/opt/puppetlabs/puppet/lib/ruby/vendor_ruby/puppet/context.rb:62:in `override'
/opt/puppetlabs/puppet/lib/ruby/vendor_ruby/puppet.rb:314:in `override'
/opt/puppetlabs/puppet/lib/ruby/vendor_ruby/puppet/network/http/api/indirected_routes.rb:53:in `call'
/opt/puppetlabs/puppet/lib/ruby/vendor_ruby/puppet/network/http/route.rb:82:in `block in process'
org/jruby/RubyArray.java:1809:in `each'
/opt/puppetlabs/puppet/lib/ruby/vendor_ruby/puppet/network/http/route.rb:81:in `process'
/opt/puppetlabs/puppet/lib/ruby/vendor_ruby/puppet/network/http/route.rb:88:in `process'
/opt/puppetlabs/puppet/lib/ruby/vendor_ruby/puppet/network/http/route.rb:88:in `process'
/opt/puppetlabs/puppet/lib/ruby/vendor_ruby/puppet/network/http/handler.rb:87:in `block in process'
/opt/puppetlabs/puppet/lib/ruby/vendor_ruby/puppet/network/http/handler.rb:70:in `block in with_request_profiling'
/opt/puppetlabs/puppet/lib/ruby/vendor_ruby/puppet/util/profiler/around_profiler.rb:58:in `profile'
/opt/puppetlabs/puppet/lib/ruby/vendor_ruby/puppet/util/profiler.rb:51:in `profile'
/opt/puppetlabs/puppet/lib/ruby/vendor_ruby/puppet/network/http/handler.rb:66:in `with_request_profiling'
/opt/puppetlabs/puppet/lib/ruby/vendor_ruby/puppet/network/http/handler.rb:86:in `block in process'
/opt/puppetlabs/puppet/lib/ruby/vendor_ruby/puppet/network/http/handler.rb:93:in `respond_to_errors'
/opt/puppetlabs/puppet/lib/ruby/vendor_ruby/puppet/network/http/handler.rb:85:in `process'
uri:classloader:/puppetserver-lib/puppet/server/master.rb:65:in `block in handleRequest'
/opt/puppetlabs/puppet/lib/ruby/vendor_ruby/puppet/context.rb:62:in `override'
/opt/puppetlabs/puppet/lib/ruby/vendor_ruby/puppet.rb:314:in `override'
uri:classloader:/puppetserver-lib/puppet/server/master.rb:64:in `handleRequest'
2021-07-19T22:16:54.328Z WARN [qtp2135865030-35] [puppetserver] Puppet The node parameter 'fqdn' for node 'pipe-foreman-server-nightly-centos7.n62.example.com' was already set to 'pipe-foreman-server-nightly-centos7.n62.example.com'. It could not be set to 'pipe-foreman-server-nightly-centos7.n62.example.com'
2021-07-19T22:16:54.329Z WARN [qtp2135865030-35] [puppetserver] Puppet The node parameter 'hostname' for node 'pipe-foreman-server-nightly-centos7.n62.example.com' was already set to 'pipe-foreman-server-nightly-centos7'. It could not be set to 'pipe-foreman-server-nightly-centos7'
I don’t see the foreman.log in the sosreport, are we bundling it too somewhere? Is there a way to access that if it’s not in sosreport?
The problem seems to be that while our tests execute hammer host update --puppet-class-ids $id --name $(hostname -f), the values are correct and hammer answers Host updated., the puppet class is not actually assigned.
Assigning the class in the WebUI or via the API (curl -XPUT -d'{"host":{"puppetclass_ids":[1]}}' -H 'Content-Type: application/json' -u admin:changeme -k https://localhost/api/hosts/1) seems to work fine, and a Puppet run afterwards does apply the motd module.
And indeed, if you run hammer --debug with the above parameters, the resulting update call is actually empty:
[ INFO 2021-07-22T08:41:35 HammerCLIForeman::Host::UpdateCommand] Called with options: {"option_puppetclass_ids"=>[1], "option_volume_list"=>[], "option_interface_list"=>[], "option_name"=>"pipe-foreman-server-nightly-centos7.yatsu.example.com", "option_id"=>1}
[DEBUG 2021-07-22T08:41:35 HammerCLIForeman::CommandExtensions::UpdateCommon] Called block for HammerCLIForeman::UpdateCommand request params:
#<Proc:0x00000000027d84b0 /opt/theforeman/tfm/root/usr/share/gems/gems/hammer_cli_foreman-2.6.0.pre.develop/lib/hammer_cli_foreman/command_extensions/update_common.rb:8>
[ INFO 2021-07-22T08:41:35 API] Server: https://pipe-foreman-server-nightly-centos7.yatsu.example.com
[ INFO 2021-07-22T08:41:35 API] PUT /api/hosts/1
[DEBUG 2021-07-22T08:41:35 API] Params: {
"host" => {
"name" => "pipe-foreman-server-nightly-centos7.yatsu.example.com"
}
}
I don’t know hammer well enough to understand why it stopped translating this, but maybe someone wiser than me can chime in here.
FWIW, I did find GitHub - theforeman/hammer-cli-foreman-puppet but didn’t manage to install it on a nightly box, as the commands clash with the ones from hammer_cli_foreman and I really have no clue how to make them not clash.
The winner gets 3.0 points, and ows both @Marek_Hulan and me 3.0 pints of beer each.
foreman_puppet has a nice check to only be overriding things when it’s actually needed: ForemanPuppet.extracted_from_core?:
As you can see there, the checked version is “3.0”, but our develop branch is still versioned 2.6. That means that this method returns false. And then the API override does not get applied in
Which means the apidoc is missing the puppetclasses_ids parameter when creating/updating hosts (and hostgroups). And well, if something is not in the apidoc, hammer ignores it. And so would FAM.
So we either need to revert the extraction, or bump to 3.0 with red nightlies and hope it works. (Given it’s the only failing test, I do expect it to become green then)