I don’t think we should remove definitions. I think we should keep them,
and I don’t think we should change them at all. They are very useful
exactly as they are.
If we changed them or got rid of them, then we’d just do the same thing
that definitions used to do, but we’d have to do them long-hand in library
methods for lack of a more-convenient DSL, or we’d come up with a new
concept and associated DSL called macros, which would do exactly the same
thing that definitions used to do but merely under a new name.
Users are confused about definitions, about what they are and how they
work. That’s a problem. But the cause isn’t what definitions are and the
cause isn’t how they work. The cause is the fact that what they are and how
they work isn’t explained clearly in the documentation.
I think the best solution is: the documentation should simply explain what
they are and how they work. That the documentation is currently unclear,
confusing, or wrong is the actual problem that needs fixing, so that’s
where the attention should be focused.
The very first line of http://wiki.opscode.com/display/chef/Definitions is
already misleading: “Definitions allow you to create new Resources by
stringing together existing resources.” They do no such thing. Definitions
are macros which expand into multiple resources, and these resources are
inserted directly into the current run-context’s
resources-collection. Definitions do not have actions, notifications,
subscriptions, or guards (only_if/not_if); only resources have these
things, and definitions are not resources. The expansion (running the
definition code) occurs during the compile phase, not during the
convergence phase: only provider actions run during the convergence phase,
and definitions are not providers. Explain that in the documentation - and
the problem is solved.
I also think it’s important to keep resources and providers separate -
i.e., single abstract interface separate from possibly-many backing
implementations. Since resources are there to provide an abstraction, we
should practice good software development practices regarding abstraction:
clearly define the interface, and separate the implementation from the
interface. In the long run, the ecosystem will be much better for it.
Turning Chef into a glorified script runner is the wrong way to go. The
right way to go is to turn system administration into rigorous software
engineering with good conventions, defaults, patterns, and practices
encouraged that are encouraged and explained by the tooling, the
documentation, and the community.
If you’re writing a quick one-off LWRP, that’s probably the wrong approach.
In terms of what currently exists, you’d often be better served with either
definitions or ruby_block resources. The pattern of resources and providers
- proper abstractions, rigorous implementations to back them - isn’t
suitable for quick one-offs. It takes a lot more care. The providers that
ship with Chef are a good example of that.
Is there room for improvement? Absolutely. Is there room for a new type of
element in cookbooks? One, for example, that can help with quick one-off
things to be run during convergence? Absolutely. But that’s a new type of
element in cookbooks. It’s an addition to the family. We don’t need to
sacrifice definitions, or muddy the waters of resources & providers, to
On Sun, Jun 10, 2012 at 5:55 PM, Joseph Holsten email@example.com:
The original proposal was to remove the original implementation of
It also contained a helper to write resource/providers even more concisely
than the LWRP syntax today.
Since the ticket originally at issue suggested definitions be rewritten to
build on LWRPs, the conversation started with that frame. Clearly, we all
agree that is a bad idea.
Removing definitions without a “replacement” probably will just annoy
people. It also creates work for community cookbook maintainers, because
it’s bad form to have those firing deprecation warnings.
Also, an even simpler syntax for R/Ps would be useful, it is a little
frustrating to have to create two files for a one-off LWRP.
So if we can figure out a good way to describe the migration path, this
can be a net win for the community. But done wrong, it’ll just piss people
off who aren’t involved with contributing to chef (much like the ruby
community grumbled about recent changes to rubygems). The deprecation
warning should point to good docs explaining how to convert and why the
change was made.
在 星期日, 6月 10, 2012，20:24，Jay Feldblum 写道：
I can see how the existing documentation on definitions can engender these
types of confusions.
Why not simply improve the documentation better to reflect that
definitions are macros, not resources or providers, and to clarify the
differences between them?
Or why not get rid of definitions entirely, which at one stroke removes
all of the complexity and all of the confusion?
On Sun, Jun 10, 2012 at 7:58 AM, Avishai Ish-Shalom firstname.lastname@example.org:
See CHEF-422, CHEF-292, CHEF-778 for example. It seems users don’t
understand that definitions act as macros and how variables pass from
recipe to definition.
resolving CHEF-1065 will make definitions act as thin wrapper around LWRP
On 10/06/12 10:48, Jay Feldblum wrote:
What are the issues confusing users originating from the block scope?
What do you mean by a wrapper for LWRP?
On Sun, Jun 10, 2012 at 3:44 AM, Avishai Ish-Shalom <email@example.com
I tend to agree. However, if definitions are to remain we need to make
them more coherent. Currently there are many issues confusing users
originating from the block scoping in ruby.
We can make definitions work within a private scope by evaluating them in
a “sub-recipe” object.
Also, if we leave definitions as they are (conceptually at least), then do
we want a wrapper for LWRP? i for one think LWRPs are easy enough now.
On 10/06/12 10:19, Jay Feldblum wrote:
I think definitions need to remain, and need to remain as they are.
A definitions is essentially a macro, expanding to a list of resources
which are added to the calling run-context’s resources-collection. There is
a place for this in Chef.
Resources something quite different: an abstract interface against an
aspect of the system being configured, with one or more pure-Ruby opaque
provider implementations which do not touch the calling run-context’s
resources-collection, and which are often implemented in lower-level Ruby
code and not as simply expanding to a list of resources. There is a place
for this in Chef as well.
On Sun, Jun 10, 2012 at 2:59 AM, Akzhan Abdulin firstname.lastname@example.org:
Agree with Joseph. We need new term in addition to definition. definition
should be deprecated.
Let it be generic_resource, for example.
2012/6/9 Joseph Holsten email@example.com
Doesn’t sound worth it to implement this and keep calling it a
definition. I’d rather see definitions be deprecated in favor of this new
feature than introduce such a breaking change.
在 星期六, 6月 9, 2012，16:56，Avishai Ish-Shalom 写道：
Fixing this ticket will resolve many issues and inconsistencies, will add
the ability to notify/subscribe to a definition, use normal meta parameters
(ignore_failure, not_if/only_if) and resolve scoping problems.
However: the fix for this ticket is a major and breaking change!!!
Resource providers are evaluated at the converge stage while definition
block (old implementation) are evaluated at recipe compile time (and recipe
scope). Many cookbooks use this as a feature and use recipe DSL statements,
e.g. include_recipe in runit_service definition.
The above patch will break some cookbooks so there is a decision to be
made here. Do we resolve this ticket and fix cookbooks, implement a
fallback to old behaviour or skip this feature altogether?