Chef-1065


#1

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


#2


josephholsten.com

在 星期六, 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


#3

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.


josephholsten.com

在 星期六, 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


#4

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 joseph@josephholsten.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.


josephholsten.com

在 星期六, 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


#5

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 akzhan.abdulin@gmail.comwrote:

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 joseph@josephholsten.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.


josephholsten.com

在 星期六, 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


#6

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
<akzhan.abdulin@gmail.com mailto:akzhan.abdulin@gmail.com> 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 <joseph@josephholsten.com
<mailto:joseph@josephholsten.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.

    --
    josephholsten.com <http://josephholsten.com>

    在 星期六, 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

#7

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 avishai@fewbytes.comwrote:

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 akzhan.abdulin@gmail.comwrote:

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 joseph@josephholsten.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.


josephholsten.com

在 星期六, 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


#8

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
<avishai@fewbytes.com mailto:avishai@fewbytes.com> 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
<akzhan.abdulin@gmail.com <mailto:akzhan.abdulin@gmail.com>> 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 <joseph@josephholsten.com
    <mailto:joseph@josephholsten.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.

        --
        josephholsten.com <http://josephholsten.com>

        在 星期六, 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

#9

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 avishai@fewbytes.comwrote:

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 <avishai@fewbytes.com

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 <akzhan.abdulin@gmail.com

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 joseph@josephholsten.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.


josephholsten.com

在 星期六, 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


#10

both would do. this is a policy decision though.

Regards,
Avishai

On 10/06/12 23:24, Jay Feldblum wrote:

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
<avishai@fewbytes.com mailto:avishai@fewbytes.com> 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
<avishai@fewbytes.com <mailto:avishai@fewbytes.com>> 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
    <akzhan.abdulin@gmail.com <mailto:akzhan.abdulin@gmail.com>>
    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 <joseph@josephholsten.com
        <mailto:joseph@josephholsten.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.

            --
            josephholsten.com <http://josephholsten.com>

            在 星期六, 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

#11

The original proposal was to remove the original implementation of definitions.

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.


josephholsten.com

在 星期日, 6月 10, 2012,20:24,Jay Feldblum 写道:

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 <avishai@fewbytes.com (mailto:avishai@fewbytes.com)> 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 <avishai@fewbytes.com (mailto:avishai@fewbytes.com)> 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 <akzhan.abdulin@gmail.com (mailto:akzhan.abdulin@gmail.com)> 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 <joseph@josephholsten.com (mailto:joseph@josephholsten.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.


josephholsten.com (http://josephholsten.com)

在 星期六, 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


#12

Joseph,

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
build it.

Cheers,
Jay

On Sun, Jun 10, 2012 at 5:55 PM, Joseph Holsten joseph@josephholsten.comwrote:

The original proposal was to remove the original implementation of
definitions.

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.


josephholsten.com

在 星期日, 6月 10, 2012,20:24,Jay Feldblum 写道:

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 avishai@fewbytes.comwrote:

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 <avishai@fewbytes.com

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 akzhan.abdulin@gmail.comwrote:

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 joseph@josephholsten.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.


josephholsten.com

在 星期六, 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