[chef] Re: Passing responses back to Chef?

[Brad Knowles < >]

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.

> Or put a different way, what are the prerequisites for figuring this out, 
> and are any of them dependent on steps in the chef run? Looking at your 
> gist, you're using `aptitude show` to figure this out, but does that rely 
> on a 3rd party repo getting enabled earlier in the chef run?

I used "aptitude show" because that was a relatively easy way to get the list 
of versions available returned to me, and then I could do a simple grep 
anchored to the beginning of the line to find the version(s) that most 
closely matched the major.minor.patch version that I wanted.

I could have done "apt-cache showpkg" (or whatever), but that would have been 
a little more difficult for me to parse, even though it would have been a 
little faster than using aptitude.

> In an ideal case, you should be able to feed all the information required 
> to configure your system into chef during the compile phase and let chef 
> sort everything out in the converge phase. If that's true for you here, you 
> can just pull the shell out call out of the ruby_block resource and you'll 
> be good to go.

The apt provider is broken with regard to understanding major.minor.patch 
versions, which is how we got to where we are now.

Maybe the solution is as simple as updating the version of the apt cookbook 
that we have?  I know what we have now doesn't include the new provider for 
version pinning, which would be another potential solution to the problem.

> 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?

--
Brad Knowles 
<
 >
LinkedIn Profile: <http://tinyurl.com/y8kpxu>