Duelling resources


#1

How do people handle duelling resources, like the following trivial example:

package "foo" do
    action :remove
end

package "foo" do
    action :install
end

I would expect that to error out, or at least pick the last version
and run with it, but no, on every run I get:

[Thu, 01 Sep 2011 10:37:46 +1000] INFO: Removing package[foo]
[Thu, 01 Sep 2011 10:37:48 +1000] INFO: Installing package[foo]

version x.y.z

Swapping the resources swaps the log messages and the end state.

Now, I’m well aware that having two conflicting packages defined
side-by-side like this isn’t likely in the real world, and even a
direct disagreement of “this package should/shouldn’t be installed” is
similarly unlikely in a system. I’ll note that a similar result is
observed with template resources, which are far more likely to
suffer from this sort of disagreement. It’s certainly possible in
the real world (with manifests consisting of thousands of resources,
from cookbooks written by separate groups of people), that there will
be some amount of disagreement, and it’d be nice if Chef provided a
bit more protection. What methods and practices are there to
minimise, or preferably detect and warn the user of this sort of
warfare?

  • Matt

#2

There are none.

Resources (and their actions) promise to ensure that each resource is in the correct state at that moment in the run. If, for some reason, you actually wanted to install a package, run a command from it, then uninstall the package, Chef won’t pretend to know better than you. This is the same thing that makes more complicated use cases, like installing mysql on ec2 (where the workflow is “install package, stop service, format EBS, mount EBS, configure mysql, start service”) easy to do.

If you wanted some reporting here, you could get it from a custom report handler that walks the resource collection looking for duplicate names, and prints them out.

Best,
Adam


Opscode, Inc.
Adam Jacob, Chief Product Officer
T: (206) 619-7151 E: adam@opscode.com

On Wednesday, August 31, 2011 at 5:59 PM, Matt Palmer wrote:

How do people handle duelling resources, like the following trivial example:

package “foo” do
action :remove
end

package “foo” do
action :install
end

I would expect that to error out, or at least pick the last version
and run with it, but no, on every run I get:

[Thu, 01 Sep 2011 10:37:46 +1000] INFO: Removing package[foo]
[Thu, 01 Sep 2011 10:37:48 +1000] INFO: Installing package[foo]
version x.y.z

Swapping the resources swaps the log messages and the end state.

Now, I’m well aware that having two conflicting packages defined
side-by-side like this isn’t likely in the real world, and even a
direct disagreement of “this package should/shouldn’t be installed” is
similarly unlikely in a system. I’ll note that a similar result is
observed with template resources, which are far more likely to
suffer from this sort of disagreement. It’s certainly possible in
the real world (with manifests consisting of thousands of resources,
from cookbooks written by separate groups of people), that there will
be some amount of disagreement, and it’d be nice if Chef provided a
bit more protection. What methods and practices are there to
minimise, or preferably detect and warn the user of this sort of
warfare?

  • Matt