[chef] Re: Re: RE: Re: Re: RE: Re: RE: Re: Why is my windows_package source attribute getting mucked up?


Chronological Thread 
  • From: Bryan McLellan < >
  • To:
  • Subject: [chef] Re: Re: RE: Re: Re: RE: Re: RE: Re: Why is my windows_package source attribute getting mucked up?
  • Date: Thu, 12 Feb 2015 13:33:56 -0500

On Thu, Feb 12, 2015 at 12:39 PM, Jay Mundrawala 
< >
 wrote:
> The windows cookbook supports downloading from a url, the resource in core
> does not...yet

Right. I migrated the windows package provider from the windows
cookbook into core Chef. The version is core does not support URLs in
the source, the cookbook still does.

As Matthew and Dan noted, it's not common behavior for the other
resources to take URLs because it means embedding (or worse,
duplicating) another resource. There's one super hairy place that we
do this, and it's the deploy resource -> git/svn resource. Based on
the principle of resources primitives each performing a single task
(i.e. the Unix philosophy) I don't think we really designed resources
to be used this way and it leads to a silly hack of adding all the
attributes from the embedded resource (remote_file) into the one
you're using (windows_package). We're in a better place now than a few
years ago because we can more easily build provider specific resources
(e.g. the windows_package provider uses the windows_package resource,
not the package resource). But still, I wondered if we need to work
through on RFC for a standard way of embeddeding resources and passing
their attributes.

Bryan



Archive powered by MHonArc 2.6.16.

§