Yum package provider always succeeding


#1

What might I redefine so I can temporarily have my package provider
always succeed? The relevant packages are already installed, but the
related repository may not be reachable, so I’d like to have the chef
run still succeed.

Thanks!


Thursday next week is indeed time for a thorough insight
into the swirling red debian vortex. — leeta


#2

If you define a version on the package I don’t think it contacts the remote repo so it should just keep going.

On Saturday, October 27, 2012 at 11:12 AM, Jason Boxman wrote:

What might I redefine so I can temporarily have my package provider
always succeed? The relevant packages are already installed, but the
related repository may not be reachable, so I’d like to have the chef
run still succeed.

Thanks!


Thursday next week is indeed time for a thorough insight
into the swirling red debian vortex. — leeta


#3

Sure, but I am using the community cookbooks for several things and no
version is set for those; I certainly could modify each recipe in
turn, but I wanted to avoid that.

On Sat, Oct 27, 2012 at 2:39 PM, Daniel Condomitti
daniel@condomitti.com wrote:

If you define a version on the package I don’t think it contacts the remote
repo so it should just keep going.

On Saturday, October 27, 2012 at 11:12 AM, Jason Boxman wrote:

What might I redefine so I can temporarily have my package provider
always succeed? The relevant packages are already installed, but the
related repository may not be reachable, so I’d like to have the chef
run still succeed.

Thanks!


Thursday next week is indeed time for a thorough insight
into the swirling red debian vortex. — leeta


Thursday next week is indeed time for a thorough insight
into the swirling red debian vortex. — leeta


#4

On Saturday, October 27, 2012 at 12:42 PM, Jason Boxman wrote:

Sure, but I am using the community cookbooks for several things and no
version is set for those; I certainly could modify each recipe in
turn, but I wanted to avoid that.

I’m not sure it’s any better than modifying the recipes, but you can get a reference to a previously defined resource with code like this:

pkg = resources(:package => "tmux")

And then you can set a version on it:

pkg.version("1.2.3")

Or set ignore_failure(true) on it.

One way to structure this is to have a local cookbook that depends on the upstream one, and runs the upstream cookbook via include_recipe. After the include_recipe statement, use code like the above to modify the resources in question.

HTH,


Daniel DeLeo


#5

Interesting idea. Thanks!

I decided to check the sanity of my overall approach instead.

On Mon, Oct 29, 2012 at 11:41 AM, Daniel DeLeo dan@kallistec.com wrote:

On Saturday, October 27, 2012 at 12:42 PM, Jason Boxman wrote:

Sure, but I am using the community cookbooks for several things and no
version is set for those; I certainly could modify each recipe in
turn, but I wanted to avoid that.

I’m not sure it’s any better than modifying the recipes, but you can get a
reference to a previously defined resource with code like this:

pkg = resources(:package => "tmux")

And then you can set a version on it:

pkg.version("1.2.3")

Or set ignore_failure(true) on it.

One way to structure this is to have a local cookbook that depends on the
upstream one, and runs the upstream cookbook via include_recipe. After the
include_recipe statement, use code like the above to modify the resources
in question.

HTH,


Daniel DeLeo


Thursday next week is indeed time for a thorough insight
into the swirling red debian vortex. — leeta