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

[Noah Kantrowitz < >]

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

Attachment: signature.asc
Description: Message signed with OpenPGP using GPGMail