[chef-dev] Re: 回复： Re: Re: Re: Re: Re： CHEF-1065

[Jay Feldblum < >]

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 < " target="_blank"> > wrote:

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 < " 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.

--
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