Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

(#10295) Work around bug #4248 whereby the puppet/util paths are not bein #22

Merged
merged 1 commit into from Oct 26, 2011

Conversation

kbarber
Copy link
Contributor

@kbarber kbarber commented Oct 26, 2011

(#10295) Work around bug #4248 whereby the puppet/util paths are not being loaded correctly on the puppetmaster

This patch suggested by Dan Carley will work-around the puppet/util error
specified in bug #4248 by loading relative paths instead.

This also fixes the load errors related to running the resource in a standalone
puppet case as well.

If the load fails for some reason, we fall back to the normal load behaviour.
This order is important as we want to load libraries before sync in case the
user has disabled pluginsync in the meantime. This will ensure we attempt to
get the latest copy, but have a fall back just in case.

I believe this fix will need to be applied for some time to support older Puppet
versions.

I've updated the documentation to provide more thorough instructions for
cases where people are using environments, and to tell people to pluginsync
on the master and potentially restart their puppetmaster first just in case.

…being loaded correctly on the puppetmaster

This patch suggested by Dan Carley will work-around the puppet/util error
specified in bug #4248 by loading relative paths instead.

This also fixes the load errors related to running the resource in a standalone
puppet case as well.

If the load fails for some reason, we fall back to the normal load behaviour.
This order is important as we want to load libraries before sync in case the
user has disabled pluginsync in the meantime. This will ensure we attempt to
get the latest copy, but have a fall back just in case.

I believe this fix will need to be applied for some time to support older Puppet
versions.

I've updated the documentation to provide more thorough instructions for
cases where people are using environments, and to tell people to pluginsync
on the master and potentially restart their puppetmaster first just in case.
saysjonathan added a commit that referenced this pull request Oct 26, 2011
(#10295) Work around bug #4248 whereby the puppet/util paths are not bein
@saysjonathan saysjonathan merged commit 062b0f0 into puppetlabs:master Oct 26, 2011
@dcarley
Copy link
Contributor

dcarley commented Oct 26, 2011

I kind of prefer your previous begin/rescue approach. Except with the order switched around, so that it tries the "normal" way first and then falls back to cater for edge cases. Seems safer than tainting the whole load path. That'd also be more consistent with the existing behaviour of pluginsync on multiple environment masters where I seem to recall $libdir always wins out.

@kbarber
Copy link
Contributor Author

kbarber commented Oct 26, 2011

So I figured using the items in the module first is a better approach on the master ... this means users don't have to wait for pluginsync to run on the master to receive the latest copy if they are midway between and upgrade. The goal here is less emails to puppet-users with users saying "what the?". I don't want to have to keep reminding users to pluginsync each time they upgrade.

As far as tainting the load path - its only tainting it with stuff thats going to be sync'd ultimately anyway right? So it actually doesn't give you any benefit picking the individual files. Also this way - the amount of special casing is only in one place. Not 3.

Do you see some unforeseen problem here?

cegeka-jenkins pushed a commit to cegeka/puppet-firewall that referenced this pull request Oct 23, 2017
(#10295) Work around bug #4248 whereby the puppet/util paths are not bein
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

4 participants