[chef] Re: Re: Re: The future of the database and application cookbooks

[Noah Kantrowitz < >]

On Sep 1, 2011, at 12:41 PM, William McVey wrote:

> On Thu, Sep 1, 2011 at 2:35 PM, Noah Kantrowitz 
> <
 >
>  wrote:
>> How is your application delivered now? The core of the application 
>> resource and the current cookbooks is still a deploy resource, which 
>> somewhat limits what you can feed in to it.
> 
> I had a long period of frustration with the application cookbook and
> finally gave up on it in favor of a (mostly) reusable (but somewhat
> tailored to my environment) Django-app deployment cookbook that is
> still evolving.  The main thing is that we have our own PyPI server
> that we push "production" code into after our CI testing passes. So I
> don't need my deployments to suck from a repo (which would be
> mercurial and not git), but simply install python packages and do
> configurations.

So the hook for that is you can specify a :strategy attribute which lets you 
replace the deploy_revision with something else entirely, as long as it 
supports the same rough API (same inputs, creates something at $path/current, 
does symlinks et al). You could do this as an LWRP, but it is far easier to 
make a "fat" resource/provider that subclasses deploy and changes the 
behavior. Another common request has been to make current/ an actual git (or 
something else) checkout instead of a symlink, as well as being able to 
deploy from tarballs. Do you think this would cover your use case? A 
python_package_deploy definitely seems like a good thing to add to the python 
cookbook to me :-)

--Noah

Attachment: smime.p7s
Description: S/MIME cryptographic signature