|
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
Regards,
Avishai
On 10/06/12 10:48, Jay Feldblum wrote:
"
type="cite">Avishai,
What are the issues confusing users originating from the
block scope?
What do you mean by a wrapper for LWRP?
Cheers,
Jay
On Sun, Jun 10, 2012 at 3:44 AM, Avishai Ish-Shalom <
" target="_blank">
>
wrote:
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.
Regards,
Avishai
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.
Cheers,
Jay
On Sun, Jun 10, 2012 at
2:59 AM, Akzhan Abdulin <
"
target="_blank">
>
wrote:
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 <
"
target="_blank">
>
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
写道：
http://tickets.opscode.com/browse/CHEF-1065
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?
--
Regards,
Avishai
|