The future of the deploy resource?

Roland_Moriz1 · 2015-01-09 11:20:37 UTC

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?

best regards
Roland

[1] https://docs.chef.io/resource_deploy.html

coderanger · 2015-01-09 11:34:05 UTC

On Jan 9, 2015, at 3:20 AM, Roland Moriz rmoriz@gmail.com 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

Thom_May · 2015-01-09 13:14:36 UTC

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 noah@coderanger.net
wrote:

On Jan 9, 2015, at 3:20 AM, Roland Moriz rmoriz@gmail.com 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

Lamont_Granquist · 2015-01-09 14:55:55 UTC

On 1/9/15 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.

Is it mostly the capistrano default values that are the problem? We
could introduce a Chef::Config setting to turn those off, and then
eventually make that the default.

Roland_Moriz1 · 2015-01-09 15:52:50 UTC

Am 09.01.2015 um 15:55 schrieb Lamont Granquist lamont@chef.io:

On 1/9/15 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.

Is it mostly the capistrano default values that are the problem? We could introduce a Chef::Config setting to turn those off, and then eventually make that the default.

…also nasty bugs like e.g. https://github.com/opscode/chef/issues/2702

Afaik Capistrano itself moved on to a less-opinionated default and a capistrano-rails gem [1] that brings back the original rails defaults.
However, even a deploy resource without the defaults is barely usable outside of the Rails ecosystem, given that it’s less flexible than capistrano itself.

IMHO there is no unique base provider for every kind of application-deployment possible, also there will be „upstream“ changes e.g. regarding Rails deployment, that may break such a resource within a chef release, so it’s IMHO a bad idea to include such thing in chef-core.

best
Roland

[1] https://github.com/capistrano/rails