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

[Noah Kantrowitz < >]

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.

--Noah

On Sep 1, 2011, at 11:25 AM, William McVey wrote:

> I'm a fairly new user of Chef and the application cookbook, but I do
> like the proposal for the application deployment (and database
> deployment for that matter.) One thing I'd like to confirm though is
> that the 'repository' and 'revision' fields would be optional. The
> current 'application' deployment cookbook pretty much explodes in
> error if you try to use it to deploy an application that is not
> fetched from an revision control repository (a problem I wrote up in
> ticket COOK-724). If in the example below, the repository and revision
> fields were optional, and the packages to load (ideally both OS level
> packages as well as 'python::pip' installation rules) could be
> specified, then that would go a long way to making the application
> cookbook usable in environments where there the codebase to install
> isn't sucked out of a live repository.
> 
>  -- William
> 
> On Tue, Aug 30, 2011 at 10:39 PM, Noah Kantrowitz 
> <
 >
>  wrote:
>> application "radiant" do
>>  path "/srv/radiant"
>>  owner "nobody"
>>  group "nogroup"
>>  repository "git://github.com/radiant/radiant.git"
>>  revision "master"
>>  packages ["libxml2-dev", "libxslt1-dev", "libsqlite3-dev"]
>>  migrate true

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