[chef] Re: Passing responses back to Chef?


Chronological Thread 
  • From: Daniel DeLeo < >
  • To: Brad Knowles < >
  • Cc:
  • Subject: [chef] Re: Passing responses back to Chef?
  • Date: Thu, 8 Aug 2013 08:09:24 -0700


On Wednesday, August 7, 2013 at 6:33 PM, Brad Knowles wrote:

On Aug 7, 2013, at 7:14 PM, Daniel DeLeo < "> > wrote:

Not really. What I'm getting at is, when is the earliest time in the chef run that you could have enough information to figure out what package you've been asked to install?

The information is loaded into a data bag by the front-end UI code before Chef is called, so in the recipe as soon as we load the data bag, we know what major.minor.patch that is desired -- 5.1.70, or whatever.

Problem is that the apt provider doesn't work if you try to install this specific version. You can either choose to install 5.1 and you'll get the latest version of 5.1 that is available in the repo, or you can request version 5.1.70-0ubuntu0.10.04.1, but nothing between "5.1" and "5.1.70-0ubuntu0.10.04.1" is accepted. That's why I filed CHEF-4442. Meanwhile, I'm trying to find ways to work around this problem.

The code you have now is pretty close, then. Just put the mixlib-shellout call at the top level of the recipe with no ruby block. Now it will run during the compile phase, before the package resource is evaluated.
 
Otherwise, the easiest path would be to create a wrapper LWRP, since LWP actions are evaluated during convergence.

If the problem is that the information is not yet available at the time of convergence when the code is being compiled that will install the package when it is called, I don't see how creating a wrapper LWRP around the apt provider is going to help. Can you enlighten me?
The exact way it works depends on whether you're using `use_inline_resources` or not, but the provider action of a LWRP is somewhat like a self contained chef run with its own compile phase.
 


-- 
Daniel DeLeo




Archive powered by MHonArc 2.6.16.

§