[chef] Re: Re: The future of the deploy resource?

[Thom May < >]

I definitely agree that the deploy resource ought to get hauled out of chef core as soon as is feasible (which'll be slow, I suspect). 

But I also think that of the git and svn resources. I'd dearly love to see the shipped set of resources be as light as possible, and a robust ecosystem of archetypes built up to extend chef with more primitive resources. 

On Fri, Jan 9, 2015 at 11:34 AM, Noah Kantrowitz < " target="_blank"> > wrote:

On Jan 9, 2015, at 3:20 AM, Roland Moriz < "> > wrote:

> Hi,
>
> the deploy resource and its provider [1] are very opinionated and tied to deployments of Ruby on Rails applications and modeled after the original Capistrano workflow defaults. But if you’re not deploying a Rails app, you’re pretty much out of luck.
> Because of its name and relevance („core resource“), many new chef users fall into this trap.
>
> Any plans to remove this from core chef w.g. with chef 13? A legacy_deploy cookbook could provide the current logic as HWRP.
>
> Another option would be to just remove the default provider and nest the current provider options below something, e.g.,
>
> ```
> Chef::Provider::Deploy::Rails
> Chef::Provider::Deploy::Rails::Branch
> Chef::Provider::Deploy::Rails::Revision
> Chef::Provider::Deploy::Rails::TimestampedDeploy
> ```
>
> What do you think?

There is general dissatisfaction with the current state of things, but I don't think there is anything like a formal plan or probably even general agreement on how to fix things. My personal solution is going to be to build out the application resource as a replacement with hopefully fewer of the issues. I would definitely not be against yanking the deploy resource to a cookbook, and I know I've heard others express a desire to remove the pseudo-capistrano bits as most of it makes little sense in a config managed world. I think I'm over my quota on RFCs for the moment, but I would be glad to read one suggesting a path forward :-)

--Noah