claytono
commented
10 years ago I'm not sure, but the Travis failure looks unrelated to my change.
Closed claytono closed 9 years ago
claytono
commented
10 years ago I'm not sure, but the Travis failure looks unrelated to my change.
alvagante
commented
10 years ago Looks good. I've not tested it, so I count on your word before merging. Would you be interested in co-maintaining this module?
claytono
commented
10 years ago Well, to be honest, we don't actually use the module a whole lot, but I'd be willing to help out where I can. I think it makes sense to hold off on the pull request until Tuesday or Wednesday. We'll have the change in a deployment by then.
On Sun, Oct 5, 2014 at 5:04 AM, Alessandro Franceschi < notifications@github.com> wrote:
Looks good. I've not tested it, so I count on your word before merging. Would you be interested in co-maintaining this module?
— Reply to this email directly or view it on GitHub https://github.com/example42/puppet-splunk/pull/26#issuecomment-57930480 .
hajee
commented
9 years ago Is there any progress on this PR? I'm interested in the future parser fix dc6b3b3.
alvagante
commented
9 years ago Merged, I had to manually merge this PR, can you please verify if everything works as expected (with future parser enabled)
This changes the handling of the install_source to be more robust and idempotent. It retrieves the package via wget and keeps the package in a known location. It then uses the Puppet package type with an rpm or dpkg provider to install the local package. This means that Puppet will handle upgrades and checking for installation automatically.
Without this patch, we frequently ran into problems where the puppet_manage_package script would be run, but fail for some reason. Since it was a refreshonly exec, it would never be run again, and then it would fall through and attempt to install the package via apt. This would lead to very confusing debugging sessions, since most people didn't know it shouldn't be installed via apt anyway.