RHEL 6 Somehow Affected

[mancusogmu]

Hey,

I have a couple RHEL 6 systems running Puppet 3.8.7 with Ruby 1.8.7 that have no profile references to the homebrew module other than it being in the main Puppetfile. However, Once I added it to the Puppetfile, I started getting the following errors on these systems:

puppet agent -t Info: Retrieving pluginfacts Info: Retrieving plugin Info: Loading facts Error: Could not autoload puppet/provider/package/brew: /var/lib/puppet/lib/puppet/provider/package/brew.rb:83: syntax error, unexpected ':', expecting ')' ...o, resource_name], failonfail: true) ^ /var/lib/puppet/lib/puppet/provider/package/brew.rb:84: syntax error, unexpected tASSOC rescue Puppet::ExecutionFailure => detail ^ /var/lib/puppet/lib/puppet/provider/package/brew.rb:90: syntax error, unexpected ':', expecting ')' ...*install_options], failonfail: true) ^ /var/lib/puppet/lib/puppet/provider/package/brew.rb:107: syntax error, unexpected ':', expecting ')' ...l, resource_name], failonfail: true) ^ /var/lib/puppet/lib/puppet/provider/package/brew.rb:108: syntax error, unexpected tASSOC rescue Puppet::ExecutionFailure => detail ^ /var/lib/puppet/lib/puppet/provider/package/brew.rb:118: syntax error, unexpected ':', expecting ')' ...e, resource_name], failonfail: true) ^ /var/lib/puppet/lib/puppet/provider/package/brew.rb:119: syntax error, unexpected tASSOC rescue Puppet::ExecutionFailure => detail ^ Error: Could not autoload puppet/type/package: Could not autoload puppet/provider/package/brew: /var/lib/puppet/lib/puppet/provider/package/brew.rb:83: syntax error, unexpected ':', expecting ')' ...o, resource_name], failonfail: true) ^ /var/lib/puppet/lib/puppet/provider/package/brew.rb:84: syntax error, unexpected tASSOC rescue Puppet::ExecutionFailure => detail ^ /var/lib/puppet/lib/puppet/provider/package/brew.rb:90: syntax error, unexpected ':', expecting ')' ...*install_options], failonfail: true) ^ /var/lib/puppet/lib/puppet/provider/package/brew.rb:107: syntax error, unexpected ':', expecting ')' ...l, resource_name], failonfail: true) ^ /var/lib/puppet/lib/puppet/provider/package/brew.rb:108: syntax error, unexpected tASSOC rescue Puppet::ExecutionFailure => detail ^ /var/lib/puppet/lib/puppet/provider/package/brew.rb:118: syntax error, unexpected ':', expecting ')' ...e, resource_name], failonfail: true) ^ /var/lib/puppet/lib/puppet/provider/package/brew.rb:119: syntax error, unexpected tASSOC rescue Puppet::ExecutionFailure => detail ^ Error: Could not retrieve catalog from remote server: Could not intern from text/pson: Could not autoload puppet/type/package: Could not autoload puppet/provider/package/brew: /var/lib/puppet/lib/puppet/provider/package/brew.rb:83: syntax error, unexpected ':', expecting ')' ...o, resource_name], failonfail: true) ^ /var/lib/puppet/lib/puppet/provider/package/brew.rb:84: syntax error, unexpected tASSOC rescue Puppet::ExecutionFailure => detail ^ /var/lib/puppet/lib/puppet/provider/package/brew.rb:90: syntax error, unexpected ':', expecting ')' ...*install_options], failonfail: true) ^ /var/lib/puppet/lib/puppet/provider/package/brew.rb:107: syntax error, unexpected ':', expecting ')' ...l, resource_name], failonfail: true) ^ /var/lib/puppet/lib/puppet/provider/package/brew.rb:108: syntax error, unexpected tASSOC rescue Puppet::ExecutionFailure => detail ^ /var/lib/puppet/lib/puppet/provider/package/brew.rb:118: syntax error, unexpected ':', expecting ')' ...e, resource_name], failonfail: true) ^ /var/lib/puppet/lib/puppet/provider/package/brew.rb:119: syntax error, unexpected tASSOC rescue Puppet::ExecutionFailure => detail ^ Warning: Not using cache on failed catalog Error: Could not retrieve catalog; skipping run

I have checked and double checked and I can't figure out why these systems get this error. If I remove the homebrew module from the Puppetfile, the error goes away and Puppet runs successfully.

I have the module tagged to 1.6.0 in the Puppetfile.

My RHEL 7 systems don't seem to have any issues, but they're running Ruby 2.0.x. RHN doesn't have Ruby above v1.8.7 for RHEL 6 so I was thinking maybe that's a possible issue? I still don't understand why it would happen since the provider files all have the darwin system constraints.

Any assistance would be great!

[TheKevJames]

It looks like this is an issue related to Ruby hash syntax -- specifically, this module uses syntax only supported on Ruby 1.9 and above.

As for why you're getting this error, I believe Puppet parses each included module even if it is not going to be executed and regardless of system constraints. Since this is a Ruby parse error, that step is exploding.

May I ask why you're including this module on a non-Darwin system?

[mancusogmu]

@TheKevJames Thanks for the quick response. Maybe the docs could use that piece of information on Ruby since Puppet < 4.0 supports Ruby 1.8.7?

And your question hits the nail on the head. We're not including the module on a non-Darwin system anywhere. It's every RHEL 6 system with Ruby prior to 1.9 having an issue though. I checked and double checked the provider files and see that they're all constrained to Darwin systems, so I can't for the life of me figure out why a system with a role that literally does nothing still will cause this error to occur.

[TheKevJames]

Done, good suggestion.

I have absolutely no idea about the later issue, though. It sounds like this might be a Puppet issue; I imagine it shouldn't parse modules that are constrained to other systems, but a quick Google search didn't turn up anything either way. It might be worth writing a minimal example of this and submitting a bug report to Puppet itself?

Otherwise, this might be an issue of puppet-homebrew not using the Puppet constraint system properly? AFAIK the Darwin constraint in metadata.json is only a search filter in the Puppet Forge, but the providers should be confined to Darwin as well. As far as I see in the Puppet docs, there's nothing more I can do, but if you see/figure something out in this regard I'd be more than happy to accept a PR or implement your suggestion.

[mancusogmu]

Thanks for adding that so fast. I think technically that resolves the issue with it not compiling. The issue of a system that shouldn't be compiling the module regardless is more than likely not this module's fault. I'd looked and seen all your constraints in the ruby, so I have no idea why it's trying to compile the module on those systems.

If I do figure out a resolution, I'll pass it along. But I'd consider this issue as it pertains to the module resolved.

Thanks again.

[mancusogmu]

Hey Kevin, I got a follow-up from Puppet. Unfortunately it wasn't too helpful, but I thought I'd share:

https://tickets.puppetlabs.com/browse/PUP-7901

[TheKevJames]

Thanks for posting the follow-up!

I think the general points here are:

• ruby 1.8.x is end-of-life'd, so its reasonable for libraries to no longer support it and use new ruby syntax
• some setups (eg. RHEL6) require ruby 1.8.x, so maybe it should be supported for legacy reasons anyway

I'm genuinely torn on this one; in the grander scheme I am totally in favor of deprecating old stuff and enforcing upgrades, but then again that leads to issues like this. Maybe puppet-homebrew should support 1.8.x, despite it being several years EOL'd, but that feels like the wrong solution. I don't know... any thoughts on this?

[mancusogmu]

I agree with you that the ideal solution would be to just upgrade Ruby since it's such an old version. I don't believe it's up to your module to support the older version of Ruby.

The problem is that RedHat has yet to incorporate the "newer" versions into its channels for RHEL 6 despite it being available in RHEL 7. Instead they created a RedHat Ruby module which can't be installed as a substitute when installing Puppet and doesn't get installed in the same way as Ruby, so I don't think that is a reasonable solution either.

Given that the Ruby code is interpreted and has a clear flow, I'd think that aborting the compile once a constraint is hit that cannot be met would be reasonable. But that's also a no go on Puppet's part.

I'm not a Ruby dev, so I don't know off hand if there's an easy way to get around this issue. I may fork the repo and create a pull for you if I can come up with something.