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

[Jay Feldblum < >]

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