File deploy resource

In this commit
https://github.com/jcam/chef/commit/a7f5599c669c840c98945a97d3d00644da00d30aI
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.

… and here, updated with support for etag and last-modified headers

On Mon, Feb 25, 2013 at 7:26 AM, Jesse Campbell hikeit@gmail.com wrote:

In this commit
https://github.com/jcam/chef/commit/a7f5599c669c840c98945a97d3d00644da00d30aI 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.

and here, solving CHEF-2506 http://tickets.opscode.com/browse/CHEF-2506and
COOK-2444 http://tickets.opscode.com/browse/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 hikeit@gmail.com 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 hikeit@gmail.com wrote:

In this commit
https://github.com/jcam/chef/commit/a7f5599c669c840c98945a97d3d00644da00d30aI 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.

This isn’t an SCM (at all). Wat?

–AJ

On 26 February 2013 06:38, Jesse Campbell hikeit@gmail.com 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 hikeit@gmail.com 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 hikeit@gmail.com 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.

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 aj@junglist.gen.nz wrote:

This isn’t an SCM (at all). Wat?

–AJ

On 26 February 2013 06:38, Jesse Campbell hikeit@gmail.com 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 hikeit@gmail.com
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 hikeit@gmail.com
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.

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 <aj@junglist.gen.nz (mailto:aj@junglist.gen.nz)> wrote:

This isn’t an SCM (at all). Wat?

–AJ

On 26 February 2013 06:38, Jesse Campbell <hikeit@gmail.com (mailto:hikeit@gmail.com)> 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 <hikeit@gmail.com (mailto:hikeit@gmail.com)> 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 <hikeit@gmail.com (mailto:hikeit@gmail.com)> 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.

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 cassianoleal@gmail.com 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 aj@junglist.gen.nz wrote:

This isn’t an SCM (at all). Wat?

–AJ

On 26 February 2013 06:38, Jesse Campbell hikeit@gmail.com 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 hikeit@gmail.com 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 hikeit@gmail.com 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.

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 :smiley:

On Mon, Feb 25, 2013 at 3:30 PM, AJ Christensen aj@junglist.gen.nz 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 cassianoleal@gmail.com 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 aj@junglist.gen.nz
wrote:

This isn’t an SCM (at all). Wat?

–AJ

On 26 February 2013 06:38, Jesse Campbell hikeit@gmail.com 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 hikeit@gmail.com
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 hikeit@gmail.com
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.

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 hikeit@gmail.com 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 :smiley:

On Mon, Feb 25, 2013 at 3:30 PM, AJ Christensen aj@junglist.gen.nz 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 cassianoleal@gmail.com 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 aj@junglist.gen.nz wrote:

This isn’t an SCM (at all). Wat?

–AJ

On 26 February 2013 06:38, Jesse Campbell hikeit@gmail.com 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 hikeit@gmail.com 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 hikeit@gmail.com 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.

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
joseph@josephholsten.com 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 hikeit@gmail.com 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 :smiley:

On Mon, Feb 25, 2013 at 3:30 PM, AJ Christensen aj@junglist.gen.nz 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 cassianoleal@gmail.com 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 aj@junglist.gen.nz wrote:

This isn't an SCM (at all). Wat?

--AJ

On 26 February 2013 06:38, Jesse Campbell hikeit@gmail.com 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 hikeit@gmail.com 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 hikeit@gmail.com 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

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 <
juanje.ojeda@gmail.com> 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
joseph@josephholsten.com 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 hikeit@gmail.com 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 :smiley:

On Mon, Feb 25, 2013 at 3:30 PM, AJ Christensen aj@junglist.gen.nz
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 cassianoleal@gmail.com
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 aj@junglist.gen.nz
wrote:

This isn’t an SCM (at all). Wat?

–AJ

On 26 February 2013 06:38, Jesse Campbell hikeit@gmail.com 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 hikeit@gmail.com
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 hikeit@gmail.com
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

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 hikeit@gmail.com 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
juanje.ojeda@gmail.com 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
joseph@josephholsten.com 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 hikeit@gmail.com 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 :smiley:

On Mon, Feb 25, 2013 at 3:30 PM, AJ Christensen aj@junglist.gen.nz
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 cassianoleal@gmail.com
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 aj@junglist.gen.nz
wrote:

This isn't an SCM (at all). Wat?

--AJ

On 26 February 2013 06:38, Jesse Campbell hikeit@gmail.com 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 hikeit@gmail.com
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 hikeit@gmail.com
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

On Mon, Feb 25, 2013 at 6:38 PM, Jesse Campbell hikeit@gmail.com wrote:

and here, solving CHEF-2506 http://tickets.opscode.com/browse/CHEF-2506and
COOK-2444 http://tickets.opscode.com/browse/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

Looks good overall, however it also increases complexity and I’m not sure
that’s warranted.

In particular, for HTTP do you really need to send a HEAD request first?
You should send the IMS / INM headers on the GET request.
COOK-2444 has a link to a branch that appears to do so, you may want to
look at that.

That may even allow you to do away with grab_fileinfo_from_uri–that’s up
to you.

Also, it looks like some of the “wishlist” items in CHEF-2506 are still not
addressed–namely handling of Expires and Cache-Control.
Personally I would not consider these a blocker and would send the pull
request anyway; but I would leave the issue open (or split these into a new
issue).

try_multiple_sources doesn’t look like it’s really iterating over sources?

Thanks for tackling this!

try_multiple_sources definitely does iterate over many sources.

you’re right, though, IMS / INM may make it possible to use just a single
request… there’s a reason i’ve got this on the discussion forum instead
of in a pull request :slight_smile:

i’ll ponder this for a bit i think.

On Tue, Feb 26, 2013 at 2:58 AM, Andrea Campi
andrea.campi@zephirworks.comwrote:

On Mon, Feb 25, 2013 at 6:38 PM, Jesse Campbell hikeit@gmail.com wrote:

and here, solving CHEF-2506 http://tickets.opscode.com/browse/CHEF-2506and
COOK-2444 http://tickets.opscode.com/browse/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

Looks good overall, however it also increases complexity and I’m not sure
that’s warranted.

In particular, for HTTP do you really need to send a HEAD request first?
You should send the IMS / INM headers on the GET request.
COOK-2444 has a link to a branch that appears to do so, you may want to
look at that.

That may even allow you to do away with grab_fileinfo_from_uri–that’s up
to you.

Also, it looks like some of the “wishlist” items in CHEF-2506 are still
not addressed–namely handling of Expires and Cache-Control.
Personally I would not consider these a blocker and would send the pull
request anyway; but I would leave the issue open (or split these into a new
issue).

try_multiple_sources doesn’t look like it’s really iterating over sources?

Thanks for tackling this!

I know this topic is ancient, but I still find it quite relevant. The deploy resource is currently quite tied to SCM providers, but in large-scale operations, does anyone really do a git clone on every server and build locally? That does not seem optimal.

I opened an issue yesterday [1], and happened to stumble upon this thread today. I think generalizing the deploy resource would come in quite handy for many people and many use cases. I don’t think it needs to support http downloads or anything fancy; for that scenario, remote_file can be used instead, and the local filename can be given as a parameter.

What are the major objections, if any, to supporting more than just git/svn?

[1] https://github.com/chef/chef/issues/4362