Facing some issue while rendering snippet variable now.
we have udpated_finish_16 provisioning template which calls collectd.configuration snippets where @conf_file variable is defined. The problem is when the @conf_file is called within the actual provisioning template the scope completion doesn’t go through.
this used to work in 1.10 but doesn’t work in 1.20
I don’t know what @conf_file is. It’s not part of the Foreman history. If it’s a local variable, you should use it without @:
<% conf_file = 'x' -%>
file = <%= conf_file %>
So basically the following is something which we have in collectd.configuration snippet
<% if @host.operatingsystem.family.downcase == 'windows' -%>
<%- @conf_file = 'C:\ProgramData\collectd.conf' -%>
<% else -%>
<%- @conf_file = '/etc/collectd.conf' -%>
<% end -%>
The following is something which we have in updated_finish_16 provisioning template
<%= snippets "collectd.configuration" -%>
# Generate puppet.conf
cat > <%= @conf_file -%> <<- EOF
<%= snippets "collectd.remidiate" %>
EOF
<% end -%>
Now the @conf_file doesn’t work for some reason and the exact same thing works in 1.10 version.
P.S - I tried to define the way you mentioned but that didn’t work too 
Tried all the possible option but no go.
Referred to preview section of the template with my changes for instant testing but no go.
Use of snippets was changed (Bug #24503: snippets macro does not render a snippet partial from filesystem - Foreman). It’s now a (deprecated) alias of snippet.
It also looks like you want to pass a variable from a snippet to the calling template. I think that’s the issue and I’d move the file location detection up or move the cat part down.
The destination logic * <%= snippets “collectd.remidiate” %>* happens before the cat.
So, I’m calling the collectd configuration file via @conf_file and writing the contents to it from * <%= snippets “collectd.remidiate” %>.
@conf_file entry is in * <%= snippets “collectd.configuration” -%>
I do suspect that @conf_file used to assign the variable to the class (which is what the @ signifies. In those many versions there have been changes to make the jail stricter. Passing variables between templates this way may no longer be allowed. @Marek_Hulan any idea?
Passing variables between templates this way may no longer be allowed
If this is really true this is gonna affect us a lot as we manage the configuration parameters like region, environment and stuff like that via template variables which is again a cool thing to manage dynamic configs.
Is there any reason the key gets added all the time ?
Debug: Executing: ‘/usr/bin/apt-key adv --keyserver keyserver.ubuntu.com --recv-keys AE0AF310E2EA96B6B6F4BD726F8600B9563278F6’
Notice: /Stage[main]/Foreman::Repo/Foreman::Repos[foreman]/Foreman::Repos::Apt[foreman]/Apt::Source[foreman]/Apt::Key[Add key: AE0AF310E2EA96B6B6F4BD726F8600B9563278F6 from Apt::Source foreman]/Apt_key[Add key: AE0AF310E2EA96B6B6F4BD726F8600B9563278F6 from Apt::Source foreman]/ensure: created
Due to this the services gets restarted as mentioned here --> https://github.com/theforeman/puppet-foreman/blob/master/manifests/init.pp#L348
I can see the keys present on the node, so not sure why it keeps on adding.
root@ubuntu1804-2:~# /usr/bin/apt-key list | /bin/grep “Foreman Automatic Signing Key”
Warning: apt-key output should not be parsed (stdout is not a terminal)
uid [ unknown] Foreman Automatic Signing Key (2016) packages@theforeman.org
this is what my apt version looks like
mod ‘puppetlabs/apt’, ‘2.2.2’
Looks like there is a problem with the apt module which we are using.
The support for ubuntu18 is from 4.4.0 once the module was upgraded things got fixed.
While creating a new host in foreman 1.20, at times the API endpoint for available network gets disrupted.
2019-04-08T08:55:57 [I|app|] Started GET "/api/v2/compute_resources/1/available_networks" for 127.0.0.1 at 2019-04-08 08:55:57 +0000
2019-04-08T08:55:57 [I|app|9c3ff] Processing by Api::V2::ComputeResourcesController#available_networks as JSON
2019-04-08T08:55:57 [I|app|9c3ff] Parameters: {"apiv"=>"v2", "id"=>"1", "compute_resource"=>{}}
2019-04-08T08:55:57 [I|app|9c3ff] Skipping user group update for user ashwin as $login is in use, group sync is unsupported
2019-04-08T08:55:57 [I|app|9c3ff] Authorized user ashwin(Ashwin Balakrishnan)
2019-04-08T08:55:57 [I|app|9c3ff] Current user set to ashwin (admin)
2019-04-08T08:55:57 [W|app|9c3ff] Action failed
NameError: uninitialized constant Fog::Compute::Vsphere::Network
Did you mean? Fog::Network
/usr/share/foreman/vendor/ruby/2.5.0/gems/activesupport-5.2.1/lib/active_support/inflector/methods.rb:285:in `const_get'
/usr/share/foreman/vendor/ruby/2.5.0/gems/activesupport-5.2.1/lib/active_support/inflector/methods.rb:285:in `block in constantize'
/usr/share/foreman/vendor/ruby/2.5.0/gems/activesupport-5.2.1/lib/active_support/inflector/methods.rb:281:in `each'
/usr/share/foreman/vendor/ruby/2.5.0/gems/activesupport-5.2.1/lib/active_support/inflector/methods.rb:281:in `inject'
/usr/share/foreman/vendor/ruby/2.5.0/gems/activesupport-5.2.1/lib/active_support/inflector/methods.rb:281:in `constantize'
/usr/share/foreman/vendor/ruby/2.5.0/gems/activesupport-5.2.1/lib/active_support/core_ext/string/inflections.rb:68:in `constantize'
/usr/share/foreman/vendor/ruby/2.5.0/gems/activesupport-5.2.1/lib/active_support/core_ext/marshal.rb:10:in `rescue in load'
/usr/share/foreman/vendor/ruby/2.5.0/gems/activesupport-5.2.1/lib/active_support/core_ext/marshal.rb:5:in `load'
/usr/share/foreman/vendor/ruby/2.5.0/gems/activesupport-5.2.1/lib/active_support/cache.rb:804:in `uncompress'
/usr/share/foreman/vendor/ruby/2.5.0/gems/activesupport-5.2.1/lib/active_support/cache.rb:726:in `value'
/usr/share/foreman/vendor/ruby/2.5.0/gems/activesupport-5.2.1/lib/active_support/cache.rb:358:in `block in read'
/usr/share/foreman/vendor/ruby/2.5.0/gems/activesupport-5.2.1/lib/active_support/cache.rb:663:in `block in instrument'
/usr/share/foreman/vendor/ruby/2.5.0/gems/activesupport-5.2.1/lib/active_support/notifications.rb:170:in `instrument'
/usr/share/foreman/vendor/ruby/2.5.0/gems/activesupport-5.2.1/lib/active_support/cache.rb:663:in `instrument'
/usr/share/foreman/vendor/ruby/2.5.0/gems/activesupport-5.2.1/lib/active_support/cache.rb:345:in `read'
/usr/share/foreman/app/services/compute_resource_cache.rb:34:in `read'
/usr/share/foreman/app/services/compute_resource_cache.rb:19:in `cache'
/usr/share/foreman/app/models/compute_resources/foreman/model/vmware.rb:145:in `networks'
/usr/share/foreman/app/models/compute_resources/foreman/model/vmware.rb:168:in `available_networks'
/usr/share/foreman/app/controllers/api/v2/compute_resources_controller.rb:121:in `available_networks'
/usr/share/foreman/vendor/ruby/2.5.0/gems/actionpack-5.2.1/lib/action_controller/metal/basic_implicit_render.rb:6:in `send_action'
The issue is intermediate, on the second or third time there is no disruption and everything goes well.
Following is a snippet for the host creation.
2019-04-08T08:58:13 [I|app|] Started GET "/api/v2/compute_resources/1/available_networks" for 127.0.0.1 at 2019-04-08 08:58:13 +0000
2019-04-08T08:58:13 [I|app|94435] Processing by Api::V2::ComputeResourcesController#available_networks as JSON
2019-04-08T08:58:13 [I|app|94435] Parameters: {"apiv"=>"v2", "id"=>"1", "compute_resource"=>{}}
2019-04-08T08:58:13 [I|app|94435] Skipping user group update for user ashwin as $login is in use, group sync is unsupported
2019-04-08T08:58:13 [I|app|94435] Authorized user ashwin(Ashwin Balakrishnan)
2019-04-08T08:58:13 [I|app|94435] Current user set to ashwin (admin)
2019-04-08T08:58:13 [I|app|94435] Rendering api/v2/compute_resources/available_networks.rabl within api/v2/layouts/index_layout
2019-04-08T08:58:13 [I|app|94435] Rendered api/v2/compute_resources/available_networks.rabl within api/v2/layouts/index_layout (0.5ms)
2019-04-08T08:58:13 [I|app|94435] Completed 200 OK in 111ms (Views: 2.0ms | ActiveRecord: 24.9ms)I have manually tried to query the endpoint almost 10times within 3 seconds and it works fine, not sure what the problem is when it is provisioned.
Any insights/suggestions @ekohl ?
You probably need to upgrade to 1.21.2:
https://github.com/theforeman/foreman/commit/373b10769b07e8c48fdd06fbe78a6ccd7c7f82dd
This wasn’t happening on our test environment so went with production.
We upgraded our system to 1.20.2-1 from 1.10 which was a bit painful but went fine apart from the intermittent issues we are seeing.
I went through the link and looks like we are just upgrading some of the plugins which were pushed only 20 days ago.
Maybe I’m missing something.
I have been reading the changelog for 1.21.2 but haven’t seen anything related to the issue I raised.
I have upgraded the foreman from 1.20 to 1.21and haven’t seen any issues yet.
@ekohl I’m stuck in a weird issue where foreman is trying to do sudo in the windows machine during provisioning template.
I turned on debug mode to find the following
2019-05-16T13:20:38 [D|app|47dd9177] about to execute sudo sh -c '(chmod 0701 ./bootstrap-5003e0da-4073-2d94-0e21-16c2d124452b && sudo ./bootstrap-5003e0da-4073-2d94-0e21-16c2d124452b ; echo $? >bootstrap-5003e0da-4073-2d94-0e21-16c2d124452b.status) 2>&1 | tee bootstrap-5003e0da-4073-2d94-0e21-16c2d124452b.log; exit $(cat bootstrap-5003e0da-4073-2d94-0e21-16c2d124452b.status)'
and then on the next line
operable program or batch file.
2019-05-16T13:20:38 [W|app|47dd9177] Failed to launch script on ash-dev-test: ERF42-0453 [Foreman::Exception]: Provision script had a non zero exit
Foreman::Exception: ERF42-0453 [Foreman::Exception]: Provision script had a non zero exit
/usr/share/foreman/app/models/concerns/orchestration/ssh_provision.rb:77:in `setSSHProvision'```I read this part Image based windows provisioning but we have been using our own templates not the ones shipped via foreman.
Also, this used to work before (almost 3 years) not sure what has changed with the upgrade.
