Further whyrun testing


#1

Hi,

I’ve tested whyrun in the last weeks intensively (found a few issues (some
of them are fixed already)).

But at the moment I can’t really proceed with testing because of the issue
I’ve filed.

http://tickets.opscode.com/browse/CHEF-3401

(I think http://tickets.opscode.com/browse/CHEF-3308 is related).

We have many custom ohai plugins/attributes in our cookbooks (i think we
are not the only ones).

Are there any plans or roadmap to fix this so that we can proceed with
whyrun testing ?

Thanks for whyrun, it’s great to have it !



#2

On Wednesday, September 12, 2012 at 11:17 PM, bjunity@gmail.com wrote:

Hi,

I’ve tested whyrun in the last weeks intensively (found a few issues (some of them are fixed already)).

But at the moment I can’t really proceed with testing because of the issue I’ve filed.

http://tickets.opscode.com/browse/CHEF-3401

(I think http://tickets.opscode.com/browse/CHEF-3308 is related).

We have many custom ohai plugins/attributes in our cookbooks (i think we are not the only ones).

Are there any plans or roadmap to fix this so that we can proceed with whyrun testing ?

Thanks for whyrun, it’s great to have it !


Can you describe the situation in more detail? Are you describing a case where you have a new ohai plugin to be added along with a recipe that depends on it?

Does everything work as expected if you install the ohai plugins before running why-run?


Daniel DeLeo


#3

Hi,

please look at

http://tickets.opscode.com/browse/CHEF-3401

, there’s a test-case to reproduce the issue.

| Does everything work as expected if you install the ohai plugins before
running why-run?

How can i distribute the ohai plugins before running chef/why-run ? I
distribute the ohai plugins with the official ohai cookbook to the servers
(as recommended in
http://wiki.opscode.com/display/chef/Distributing+Ohai+Plugins).

2012/9/13 Daniel DeLeo dan@kallistec.com

On Wednesday, September 12, 2012 at 11:17 PM, bjunity@gmail.com wrote:

Hi,

I’ve tested whyrun in the last weeks intensively (found a few issues (some
of them are fixed already)).

But at the moment I can’t really proceed with testing because of the issue
I’ve filed.

http://tickets.opscode.com/browse/CHEF-3401

(I think http://tickets.opscode.com/browse/CHEF-3308 is related).

We have many custom ohai plugins/attributes in our cookbooks (i think we
are not the only ones).

Are there any plans or roadmap to fix this so that we can proceed with
whyrun testing ?

Thanks for whyrun, it’s great to have it !


Can you describe the situation in more detail? Are you describing a
case where you have a new ohai plugin to be added along with a recipe that
depends on it?

Does everything work as expected if you install the ohai plugins before
running why-run?


Daniel DeLeo


#4

Hi,

By its nature, whyrun takes every reasonable precaution to avoid making
changes to system state. This means that no cookbook can actually
execute - including those that would install ohai plugins.

In this case chef would report that the plugins would be installed, but
anything further that depends on the presence of these plugins can’t be
executed until they are actually installed.

If you need data gathered by the plugins, you will need to install the
plugins via a normal chef client run before the data they gather is
available to a whyrun execution.

Thanks,

  • Marc

On 9/13/12 1:20 PM, bjunity@gmail.com wrote:

Hi,

please look at

http://tickets.opscode.com/browse/CHEF-3401

, there’s a test-case to reproduce the issue.

| Does everything work as expected if you install the ohai plugins
before running why-run?

How can i distribute the ohai plugins before running chef/why-run ? I
distribute the ohai plugins with the official ohai cookbook to the
servers (as recommended in
http://wiki.opscode.com/display/chef/Distributing+Ohai+Plugins).

2012/9/13 Daniel DeLeo <dan@kallistec.com mailto:dan@kallistec.com>

On Wednesday, September 12, 2012 at 11:17 PM, bjunity@gmail.com
<mailto:bjunity@gmail.com> wrote:
Hi,

I've tested whyrun in the last weeks intensively (found a few
issues (some of them are fixed already)).


But at the moment I can't really proceed with testing because of
the issue I've filed.


http://tickets.opscode.com/browse/CHEF-3401


(I think http://tickets.opscode.com/browse/CHEF-3308 is related).


We have many custom ohai plugins/attributes in our cookbooks (i
think we are not the only ones).


Are there any plans or roadmap to fix this so that we can proceed
with whyrun testing ?



Thanks for whyrun, it's great to have it !


------
Can you describe the situation in more detail? Are you describing
a case where you have a new ohai plugin to be added along with a
recipe that depends on it?

Does everything work as expected if you install the ohai plugins
before running why-run?

-- 
Daniel DeLeo

#5

Hi Marc,

if you think this way, you are absolutely right.

But in a whyrun - run, chef already executes the built-in standard ohai
plugins (and doesn’t know if they are read-only or make changes to the
system).

I can imagine of a solution which is downloading the custom ohai plugins
from the server (or (chef-solo) from a directory) to a temp directory and
execute the custom ohai plugins side-by-side (or after) with the built-in
standard ohai plugins.

Maybe this is too complicated.

Thanks for reply Marc, at the moment I will use your solution.

2012/9/13 Marc Paradise marc@opscode.com

Hi,

By its nature, whyrun takes every reasonable precaution to avoid making
changes to system state. This means that no cookbook can actually execute -
including those that would install ohai plugins.

In this case chef would report that the plugins would be installed, but
anything further that depends on the presence of these plugins can’t be
executed until they are actually installed.

If you need data gathered by the plugins, you will need to install the
plugins via a normal chef client run before the data they gather is
available to a whyrun execution.

Thanks,

  • Marc

On 9/13/12 1:20 PM, bjunity@gmail.com wrote:

Hi,

please look at

http://tickets.opscode.com/browse/CHEF-3401

, there’s a test-case to reproduce the issue.

| Does everything work as expected if you install the ohai plugins before
running why-run?

How can i distribute the ohai plugins before running chef/why-run ? I
distribute the ohai plugins with the official ohai cookbook to the servers
(as recommended in
http://wiki.opscode.com/display/chef/Distributing+Ohai+Plugins).

2012/9/13 Daniel DeLeo dan@kallistec.com

On Wednesday, September 12, 2012 at 11:17 PM, bjunity@gmail.com wrote:

Hi,

I’ve tested whyrun in the last weeks intensively (found a few issues
(some of them are fixed already)).

But at the moment I can’t really proceed with testing because of the
issue I’ve filed.

http://tickets.opscode.com/browse/CHEF-3401

(I think http://tickets.opscode.com/browse/CHEF-3308 is related).

We have many custom ohai plugins/attributes in our cookbooks (i think we
are not the only ones).

Are there any plans or roadmap to fix this so that we can proceed with
whyrun testing ?

Thanks for whyrun, it’s great to have it !


Can you describe the situation in more detail? Are you describing a
case where you have a new ohai plugin to be added along with a recipe that
depends on it?

Does everything work as expected if you install the ohai plugins before
running why-run?


Daniel DeLeo


#6

On Thursday, September 13, 2012 at 11:07 AM, bjunity@gmail.com wrote:

Hi Marc,

if you think this way, you are absolutely right.

But in a whyrun - run, chef already executes the built-in standard ohai plugins (and doesn’t know if they are read-only or make changes to the system).

I can imagine of a solution which is downloading the custom ohai plugins from the server (or (chef-solo) from a directory) to a temp directory and execute the custom ohai plugins side-by-side (or after) with the built-in standard ohai plugins.

Maybe this is too complicated.

Thanks for reply Marc, at the moment I will use your solution.

If you need to just install the plugins without running other recipes, you might look into the --override-runlist option to run just the ohai recipe.

In a larger sense, you’re hitting a specific case of a larger issue, which is that the accuracy of any no-op mode decreases as the difference between the desired state and current state increases. Chef’s implementation accounts for this on a per-resource basis by detecting when a resource could not be converged (e.g, you’re trying to put a file in a directory that doesn’t exist, restart a service for which you haven’t installed the code, etc.), issuing a message, and continuing as if the resource’s prerequisites had been met. It’s still up to you to apply your knowledge of the system to verify what why-run is telling you. This is unavoidable since many resources (execute, scripts, package installs via post-install scripts, service start/restart via init scripts, etc.) involve running code with side effects that cannot be determined by chef in advance. Modifying chef-client’s internal state by running ohai plugins is similar in this regard.

That isn’t to say that why-run is useless or “considered harmful”, just that you need to keep in mind that chef-client cannot anticipate and account for the side-effects that normal recipe execution implicitly relies on.


Daniel DeLeo