[[chef-dev]] Re: [[chef-dev]] Re: [[chef-dev]] Re: [[chef-dev]] Resources, Providers and Runners, oh my - A tale of concerns


Chronological Thread 
  • From: Mathias Meyer < >
  • To: Daniel DeLeo < >
  • Cc:
  • Subject: [[chef-dev]] Re: [[chef-dev]] Re: [[chef-dev]] Re: [[chef-dev]] Resources, Providers and Runners, oh my - A tale of concerns
  • Date: Thu, 15 Oct 2009 22:26:52 +0200

On Tue, Oct 13, 2009 at 3:18 AM, Daniel DeLeo 
< >
 wrote:
> Ohai Chefs!
> Mathias,
> To follow up on our conversation on IRC today, what you're seeing in the
> LWRP spec failures results from the resources being initialized differently
> in the specs than they would be if created via the DSL. In the DSL, you see
> resources initialized this way:
> args << @collection
> args << @node
> resource = Chef::Resource.const_get(resource_camel_case_name).new(*args)
> But in the failing specs, you see this:
> Chef::Resource::LwrpFoo.new("morpheus")
>
> When you moved Runner#build_provider to Resource#build_provider, it became
> necessary for the specs to pass the resource collection to the resources
> when initializing. So the issue can be fixed by changing the specs to more
> closely match the behavior that would occur in a real chef run, for example:
> rc = Chef::ResourceCollection.new
> injector = Chef::Resource::LwrpFoo.new("morpheus", rc)
> By the way, should you encounter errors due to @definitions being undefined
> somewhere, there are fixes for that in the works, so I'd recommend waiting
> for those fixes to hit master so we're not stepping on each others' toes.
> As far as cleanly separating responsibilities, I'm all for it, and I'd say
> the amount of effort required to understand the code as it is now is good
> evidence that the effort is worthwhile.

All that sounds great, Daniel, and it looks like we're halfway there
with these fixes and the potentially broken specs. We talked about it
a bit more two days ago, and the last remaining problem apart from the
things you mentioned above was basically the cookbook_loader. In the
DSL core that's handed over to a Chef::Recipe instance where it's used
for include_recipe.

The definitions issue was apparently fixed with [1], and Daniel
improved quite a lot of the code that's depending on @definitions in
his methodnotmissing branch [2].

As far as what I learned during our chat was that the cookbook_loader
could easily be created lazily, maybe not even only in this case, but
whenever it's required. I just noticed that Daniel already changed it
to work this way in his branch [3].

So to sum up, it seems that most of the underlying issues were already
fixed, awesome!

The question is, how do they get in. Daniel mentioned they're too big
for a 0.7.12 release, personally I'd love to see them in the release
after that if possible. I'll play around with Daniel's changes on our
fork to see how they work with the changes we made for CHEF-606 and
CHEF_605.

If I forgot anything, please feel free to add it.

Thanks, guys!

Cheers, Mathias

[1] 
http://github.com/opscode/chef/commit/03214fa3eae3f5ccfdceb405fd66660566b005fb
[2] http://github.com/danielsdeleo/chef/commits/methodnotmissing
[3] 
http://github.com/danielsdeleo/chef/commit/f0d6bf123632723ac7fb36c0f66b42f0fb8c75d1
-- 
http://paperplanes.de ;| http://holgarific.net
http://twitter.com/roidrage



Archive powered by MHonArc 2.6.16.

§