[SERVER-2243] integer <number> too big to convert to `int' Created: 2018/07/02  Updated: 2018/07/19  Resolved: 2018/07/19

Status: Closed
Project: Puppet Server
Component/s: Puppet Server
Affects Version/s: None
Fix Version/s: None

Type: Bug Priority: Major
Reporter: Udhayamoorthy Karunamoorthy Assignee: Udhayamoorthy Karunamoorthy
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

puppet 4.5.2, puppet server 2.0.9


Template: PUP Bug Template
Method Found: Needs Assessment
QA Risk Assessment: Needs Assessment

 Description   

I had a look at this ticket https://tickets.puppetlabs.com/browse/SERVER-1408 

Let me know if this issue is related to the puppet server. 

 

Below is the stacktrace log,

Info: Using configured environment 'development'
Info: Retrieving pluginfacts
Info: Retrieving plugin
Info: Loading facts
Error: Could not retrieve catalog from remote server: Error 400 on SERVER: Evaluation Error: Error while evaluating a Function Call, Failed to parse template <template file>:
  Filepath: org/jruby/RubyKernel.java
  Line: 1320
  Detail: integer <number> too big to convert to `int'
at 
/opt/puppetlabs/puppet/lib/ruby/vendor_ruby/puppet/indirector/rest.rb:212:in `is_http_200?'
/opt/puppetlabs/puppet/lib/ruby/vendor_ruby/puppet/indirector/rest.rb:110:in `find'
/opt/puppetlabs/puppet/lib/ruby/vendor_ruby/puppet/indirector/indirection.rb:194:in `find'
/opt/puppetlabs/puppet/lib/ruby/vendor_ruby/puppet/configurer.rb:377:in `block in retrieve_new_catalog'
/opt/puppetlabs/puppet/lib/ruby/vendor_ruby/puppet/util.rb:386:in `block in thinmark'
/opt/puppetlabs/puppet/lib/ruby/2.1.0/benchmark.rb:294:in `realtime'
/opt/puppetlabs/puppet/lib/ruby/vendor_ruby/puppet/util.rb:385:in `thinmark'
/opt/puppetlabs/puppet/lib/ruby/vendor_ruby/puppet/configurer.rb:376:in `retrieve_new_catalog'
/opt/puppetlabs/puppet/lib/ruby/vendor_ruby/puppet/configurer.rb:78:in `retrieve_catalog'
/opt/puppetlabs/puppet/lib/ruby/vendor_ruby/puppet/configurer.rb:147:in `prepare_and_retrieve_catalog'
/opt/puppetlabs/puppet/lib/ruby/vendor_ruby/puppet/configurer.rb:281:in `run_internal'
/opt/puppetlabs/puppet/lib/ruby/vendor_ruby/puppet/configurer.rb:186:in `block in run'
/opt/puppetlabs/puppet/lib/ruby/vendor_ruby/puppet/context.rb:65:in `override'
/opt/puppetlabs/puppet/lib/ruby/vendor_ruby/puppet.rb:240:in `override'
/opt/puppetlabs/puppet/lib/ruby/vendor_ruby/puppet/con



 Comments   
Comment by Justin Stoller [ 2018/07/03 ]

Hi, Udhayamoorthy Karunamoorthy. That does look like the same issue. Can you try upgrading to the latest Puppet Server release in the 2.x series (2.8.1) and see if that resolves your problem?

Comment by Udhayamoorthy Karunamoorthy [ 2018/07/03 ]

Hi Justin Stoller,

Unfortunately we couldn't upgrade the puppet server for now as this happened in the prod puppet master. 

To elaborate more on the issue we had, this has happened during the catalog compilation and it fails at the below code

 
case $consul_replicate::init_style {
 'systemd':{
 file { '/lib/systemd/system/consul-replicate.service':
 mode => '0644',
 owner => 'root',
 group => 'root',
 content => template('consul_replicate/consul-replicate.systemd.erb')
 } ~>
 
 

 

It is not able to create the consul_replicate.service as it failed to parse consul-replicate.systemd.erb template.

The consul-replicate.systemd.erb file has the following,

 
[Unit]
Description=Consul-Replicate Daemon
Wants=basic.target
After=basic.target network.target
 
[Service]
ExecStart=<%= scope.lookupvar('consul_replicate::bin_dir') %>/consul-replicate \
 -config <%= scope.lookupvar('consul_replicate::config_dir') %>/config.hcl <%= scope.lookupvar('consul_replicate::extra_options') %>
ExecReload=/bin/kill -HUP $MAINPID
SuccessExitStatus=0 12
Restart=on-failure
RestartSec=10s
LimitNOFILE=4096
 
[Install]
WantedBy=multi-user.target

Comment by Udhayamoorthy Karunamoorthy [ 2018/07/04 ]

And the consul_replicate version used is v0.3.1

Comment by Justin Stoller [ 2018/07/06 ]

So in that linked ticket they have a work around that doesn't involve upgrading. They found that this issue is caused when an unknown variable is looked up and can be worked around by updating the template to include this:

val = scope.exists?(name) ? scope.lookupvar(name) : nil

do you might want to try replacing references to lookuvar like scope.lookupvar('consul_replicate::bin_dir') with something more like

scope.exists?('consul_replicate::bin_dir') ? scope.lookupvar('consul_replicate::bin_dir') : nil

Comment by Justin Stoller [ 2018/07/17 ]

Did that work around solve your issue Udhayamoorthy Karunamoorthy?

Comment by Udhayamoorthy Karunamoorthy [ 2018/07/19 ]

Thanks Justin Stoller Its fixed.

Generated at Wed Nov 13 16:55:44 PST 2019 using JIRA 7.7.1#77002-sha1:e75ca93d5574d9409c0630b81c894d9065296414.