voxpupuli / puppet-staging

⛔️ Deprecated in favor of puppet-archive
https://forge.puppet.com/puppet/archive
Apache License 2.0
51 stars 109 forks source link

file define forces a default path for Exec #2

Closed geoffdavis closed 12 years ago

geoffdavis commented 12 years ago

In manifests/file.pp, there is a default path specified for Exec which overrides anything set by the user in site.pp.

Unfortunately, this breaks on Solaris, at least in my environment. Solaris 10 does not ship with curl, so I have added it with the pkgutil provider. This places it the curl binary in /opt/csw/bin/curl.

From looking at the code, the workaround is to put a symlink in /usr/local/bin/curl pointing to /opt/csw/bin/curl, but I'd rather not if I can avoid it.

Can the default Exec path either be parameterized or removed?

nanliu commented 12 years ago

Ah, would addition of the $::path fact be helpful as the parameter default?

geoffdavis commented 12 years ago

As a default value, $::path is a good start, but I think that parameterizing the staging class would break in many cases. For example, I don't actually call staging directly from my top-level manifests, but Adrien's magic puppet-enterprise upgrader brings it in with a 'require' statement, as does a module that I'm writing. How does the 'require' function work? Does it play nicely with parameterized classes? If not, parameterizing anything in the top-level staging/manifests/init.pp class may be a non-starter unless it can also modified with a top-scope variable or hiera. Parameterized classes are messy when you have more than one module trying to use them.

It's a pity that the $::path fact doesn't change during runtime when you set the default value of path for all Exec statements. I'd love to just do this in site.pp and be done:

 Exec {
   path => $::osfamily ? { 
     Solaris => '/usr/bin:/opt/csw/bin:/usr/sbin:/opt/csw/sbin:/bin:/sbin',
     default => '/usr/bin:/usr/sbin:/bin:/sbin',
   }
 }
nanliu commented 12 years ago

You have several options since this module was intended to be used with heira 1 and 2 is preferred.

  1. In hiera.yaml configuration specify %{operatingsystem} as a hierarchy. solaris.yaml will have staging_exec : '/usr/bin...'.
  2. In hiera.yaml enable puppet backend and in data module set conditional similar to above with $staging_exec = '...' the right path conditionally.
  3. declare the staging class before the require in site.pp.

    class { 'staging': exec => '...', }

geoffdavis commented 12 years ago

Hmm, like almost everything related to parameterized classes, that third approach seems like a hack that requires on the parser doing "the right thing". But hey if it works, that's probably going to be the approach I go with until I figure out the best way to structure my hiera setup.

nanliu commented 12 years ago

This is fixed with a way to allow your existing Exec defaults in site.pp to specify exec path in this module. If there's any issues, please reopen.