[chef-dev] Re: Re: file deploy resource

[Juanje Ojeda Croissier < >]

IMHO, if the attribute "scm_provider" were named just "provider" and
the attribute "repo", "source" (with an alias named "repo"), it will
feel just right to be used with SCM, artifacts, archives or whatever.

On Mon, Feb 25, 2013 at 10:37 PM, Jesse Campbell 
<
 >
 wrote:
> Is the objection here because of the provider attribute named
> "scm_provider", and the source named "repo"?
>
> Other than the naming, all the deploy provider does is maintain multiple
> versions, with a "current" pointed to the active one. This is just like
> capistrano, which doesn't have the silly requirement that you store all your
> stuff in a git or svn repository.
>
>
> What would make this not "feel wrong"?
>
>
> On Mon, Feb 25, 2013 at 5:20 PM, Juanje Ojeda Croissier
> <
 >
>  wrote:
>>
>> Actually, I've been thinking the same from some time ago. Deploy
>> resource should deploy apps, doesn't matter if they come from a SCM,
>> from artifact, file...
>> I agree that to have a SCM provider that is not SCM at all, feels just
>> wrong, but maybe the problem is that it shouldn't accept just SCM
>> providers. Maybe others like artifacts and archives.
>>
>> On Mon, Feb 25, 2013 at 9:52 PM, Joseph Holsten
>> <
 >
>>  wrote:
>> > the deploy resource is deeply tied to the scm providers. It is designed
>> > to deploy and app from an scm. It is not designed to deploy from 
>> > artifacts
>> > (cf artifact cookbook) or archives (cf ark cookbook) or native packages.
>> >
>> > It would be nice to have all the application cookbook's callbacks
>> > wrapped around those ways of dropping files in place tho. This makes me
>> > wonder if perhaps the deploy resource should go away, and that tooling
>> > should be pulled up into application. Or similar.
>> >
>> >
>> > On 2013-02-25, at 13:02, Jesse Campbell 
>> > <
 >
>> >  wrote:
>> >
>> >> It does look a little similar to the artifact cookbook...
>> >> I was just hoping I'd only have to teach the guys in my group one way
>> >> of deploying (we went with application / application_php / 
>> >> application_java
>> >> / application_python)...
>> >> so we'd have to learn yet another new and different way to accomplish
>> >> the same task. boo.
>> >>
>> >> What is the original intention of the deploy resource? I thought it was
>> >> for deploying an app :D
>> >>
>> >>
>> >> On Mon, Feb 25, 2013 at 3:30 PM, AJ Christensen 
>> >> <
 >
>> >> wrote:
>> >> It doesn't feel right to overload the deploy resource with
>> >> functionality that doesn't really reflect it's original intention (or
>> >> any of the existing providers), but I see where you are coming from. I
>> >> could have sworn I saw someone trying to hack this into remote_file a
>> >> few weeks ago on this list.
>> >>
>> >> I believe this is similar to RiotGames' Artifact style deployments
>> >> (?), which can deploy from Nexus as well? [0]
>> >>
>> >> --AJ
>> >>
>> >> [0] https://github.com/RiotGames/artifact-cookbook
>> >>
>> >> On 26 February 2013 09:24, Cassiano Leal 
>> >> <
 >
>> >> wrote:
>> >> > It makes perfect sense to me. Capistrano has that, and it's super
>> >> > useful for
>> >> > compiled binaries.
>> >> >
>> >> > Thanks for bringing this capability to Chef's deploy resource.
>> >> >
>> >> > - cassiano
>> >> >
>> >> > On Monday, February 25, 2013 at 17:20, Jesse Campbell wrote:
>> >> >
>> >> > Not quite enough words there to convey your meaning clearly, but I'll
>> >> > guess
>> >> > that what you are saying is that a remote file is not an SCM
>> >> > resource, so I
>> >> > shouldn't do this?
>> >> >
>> >> > Explain further. What are you getting at?
>> >> >
>> >> > I want to be able to use "deploy" (and by extension "application" and
>> >> > "application_*") without having a git target because the application
>> >> > is a
>> >> > war stored on an FTP server, the application is in a zip file
>> >> > downloaded
>> >> > from a web server, the application is in a zip stored on a network
>> >> > drive.
>> >> >
>> >> >
>> >> > On Mon, Feb 25, 2013 at 2:46 PM, AJ Christensen 
>> >> > <
 >
>> >> > wrote:
>> >> >
>> >> > This isn't an SCM (at all). Wat?
>> >> >
>> >> > --AJ
>> >> >
>> >> > On 26 February 2013 06:38, Jesse Campbell 
>> >> > <
 >
>> >> >  wrote:
>> >> >> and here, solving CHEF-2506 and COOK-2444, I moved the etag and
>> >> >> last-modified header checks to the base remote_file provider
>> >> >>
>> >> >>
>> >> >>
>> >> >> https://github.com/jcam/chef/compare/rest_client_11...jcam:remote_file_deploy
>> >> >>
>> >> >> I'll put together a bug and pull request once i write some unit
>> >> >> tests
>> >> >>
>> >> >>
>> >> >> On Mon, Feb 25, 2013 at 9:14 AM, Jesse Campbell 
>> >> >> <
 >
>> >> >> wrote:
>> >> >>>
>> >> >>> ... and here, updated with support for etag and last-modified
>> >> >>> headers
>> >> >>>
>> >> >>>
>> >> >>>
>> >> >>>
>> >> >>> https://github.com/jcam/chef/blob/remote_file_deploy/lib/chef/provider/remote_file/deploy.rb
>> >> >>>
>> >> >>>
>> >> >>> On Mon, Feb 25, 2013 at 7:26 AM, Jesse Campbell 
>> >> >>> <
 >
>> >> >>> wrote:
>> >> >>>>
>> >> >>>> In this commit
>> >> >>>>
>> >> >>>>
>> >> >>>> https://github.com/jcam/chef/commit/a7f5599c669c840c98945a97d3d00644da00d30a
>> >> >>>> I added a remote file deploy, which allows using the deploy
>> >> >>>> resource
>> >> >>>> like
>> >> >>>> this:
>> >> >>>>
>> >> >>>> deploy_revision "/tmp/hdocs" do
>> >> >>>>   repo "https://www.google.com/images/srpr/logo3w.png";
>> >> >>>>   revision "a123b456c789"
>> >> >>>>   scm_provider Chef::Provider::RemoteFile::Deploy
>> >> >>>>   symlink_before_migrate Hash.new
>> >> >>>>   migrate false
>> >> >>>> end
>> >> >>>>
>> >> >>>> Does this belong as remote_file/deploy.rb, or as
>> >> >>>> deploy/remote_file.rb,
>> >> >>>> or should this be inside a recipe? This would replace the current
>> >> >>>> java_remote_file in the application_java cookbook.
>> >> >>>
>> >> >>>
>> >> >>
>> >> >
>> >> >
>> >> >
>> >>
>> >
>>
>>
>>
>> --
>> Juanje
>>
>> http://about.me/juanje
>
>



--
Juanje

http://about.me/juanje