both would do. this is a policy decision though.
Regards,
Avishai
On 10/06/12 23:24, Jay Feldblum wrote:
"
type="cite">Avishai,
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?
Cheers,
Jay
On Sun, Jun 10, 2012 at 7:58 AM,
Avishai Ish-Shalom <
"
target="_blank">
> wrote:
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:
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
|