Thanks for the reply!
I agree that the ‘ark’ resource shares some similar features. There are also some potential features in ark that would be nice to “borrow” for this proposed SCM provider.
Whereas, the main purpose for ark is to do the “fetch-unpack-configure-build-install dance” for building/installing binaries, the purpose of this ObjectSCM provider is to fetch web application code in a way that we can leverage the all the migration, callback and rollback functionality offered by the existing Deploy Resource.
I have updated the overview and implementation sections in an attempt to be more clear about that. I have also renamed the proposed provider to “Chef::Provider::ScmObject”. Please see:
 - http://docs.opscode.com/resource_deploy.html
On May 8, 2013, at 6:13 PM, Ranjib Dey wrote:
the ark resource shares some of the features. might be easier to extend that one,
On Wed, May 8, 2013 at 5:22 PM, Sol Kindle email@example.com wrote:
I’m finally had a chance to play around with deploy resource and application cookbooks. While the deploy resource is pretty complicated, it works great and has an amazing amount of flexibility.
I have a requirement to deploy application code from tarballs living in an object storage service (e.g. S3) – this so we don’t depend on github being available during an autoscaling event. I have to support all kinds of app stacks, including rails, tomcat and php.
I just wanted to get some expert eyes on this idea to see if there is any value in it and if this approach is the right direction.
Here are some more details about what I am thinking…
Does it make sense to extend the deploy and scm resources to support an ObjectStorage SCM resource and providers?
Does the way of matching archive filenames and the naming conventions make sense?
@kindsol (aka caryp)