Prevent resource from triggering multiple times in a single run

remote_file “/var/tmp/somefile” do
source “http://binfiles/somefile”
owner “root”
group “root”
mode “0644”
action :create
end

Lets just suppose that this is a somewhat expensive operation that may
need to get called multiple times during a converge depending on what
recipes the node is running. I would like to say “do not execute this
resource if it has already been triggered during this run”

I would also not like to use a marker file if I can avoid it.

I know we have delayed execution but that is not what I want. I need
this to trigger on the first call and then not again. Can I use the
run_status or run_context to accomplish this?

Thanks!

If its really a remote_file resource then those support etags and
last-modified-since so it won't be expensive to run multiple times.

Generally when you have a call-many-times-run-only-once pattern you're
looking at include_recipe'ing the expensive thing so it only gets
created once in the resource collection.

You can also use a definition to edit the resource collection and the
definition can check and exit if the resource always exists.

On 08/29/2015 01:42 PM, Mark Selby wrote:

remote_file “/var/tmp/somefile” do
source “http://binfiles/somefile”
owner “root”
group “root”
mode “0644”
action :create
end

Lets just suppose that this is a somewhat expensive operation that may
need to get called multiple times during a converge depending on what
recipes the node is running. I would like to say “do not execute this
resource if it has already been triggered during this run”

I would also not like to use a marker file if I can avoid it.

I know we have delayed execution but that is not what I want. I need
this to trigger on the first call and then not again. Can I use the
run_status or run_context to accomplish this?

Thanks!

On 08/30/2015 06:24 PM, Lamont Granquist wrote:

If its really a remote_file resource then those support etags and
last-modified-since so it won't be expensive to run multiple times.

Generally when you have a call-many-times-run-only-once pattern you're
looking at include_recipe'ing the expensive thing so it only gets
created once in the resource collection.

You can also use a definition to edit the resource collection and the
definition can check and exit if the resource always exists.

  • already exists.

Thanks for response. I fully see the utility of the include_recipe paradigm.

Out of real curiosity you mentioned this -- "use a definition to edit
the resource collection and the definition can check and exit if the
resource always exists"

Would you happen to have any example code that might show how that works.

Thanks!

On 8/30/15 6:24 PM, Lamont Granquist wrote:

If its really a remote_file resource then those support etags and
last-modified-since so it won't be expensive to run multiple times.

Generally when you have a call-many-times-run-only-once pattern you're
looking at include_recipe'ing the expensive thing so it only gets
created once in the resource collection.

You can also use a definition to edit the resource collection and the
definition can check and exit if the resource always exists.

On 08/29/2015 01:42 PM, Mark Selby wrote:

remote_file “/var/tmp/somefile” do
source “http://binfiles/somefile”
owner “root”
group “root”
mode “0644”
action :create
end

Lets just suppose that this is a somewhat expensive operation that
may need to get called multiple times during a converge depending on
what recipes the node is running. I would like to say “do not execute
this resource if it has already been triggered during this run”

I would also not like to use a marker file if I can avoid it.

I know we have delayed execution but that is not what I want. I need
this to trigger on the first call and then not again. Can I use the
run_status or run_context to accomplish this?

Thanks!

According to your description, and if you wish to keep each cookbook
independent you can do this to define the resource only if it does not
exist already in the collection (you have to update all recipes defining
this resource):

begin

r = resources("remote_file[/var/tmp/somefile")

rescue

remote_file "/var/tmp/somefile" do
source "http://binfiles/somefile" [1]
owner "root"
group "root"
mode "0644"
action :create
end

end

Le 2015-08-31 03:43, Mark Selby a écrit :

Thanks for response. I fully see the utility of the include_recipe paradigm.

Out of real curiosity you mentioned this -- "use a definition to edit the resource collection and the definition can check and exit if the resource always exists"

Would you happen to have any example code that might show how that works.

Thanks!

On 8/30/15 6:24 PM, Lamont Granquist wrote:
If its really a remote_file resource then those support etags and last-modified-since so it won't be expensive to run multiple times.

Generally when you have a call-many-times-run-only-once pattern you're looking at include_recipe'ing the expensive thing so it only gets created once in the resource collection.

You can also use a definition to edit the resource collection and the definition can check and exit if the resource always exists.

On 08/29/2015 01:42 PM, Mark Selby wrote: remote_file "/var/tmp/somefile" do
source "http://binfiles/somefile" [1]
owner "root"
group "root"
mode "0644"
action :create
end

Lets just suppose that this is a somewhat expensive operation that may need to get called multiple times during a converge depending on what recipes the node is running. I would like to say "do not execute this resource if it has already been triggered during this run"

I would also not like to use a marker file if I can avoid it.

I know we have delayed execution but that is not what I want. I need this to trigger on the first call and then not again. Can I use the run_status or run_context to accomplish this?

Thanks!

Links:

[1] http://binfiles/somefile

The "many recipes, one definition" example from:

http://docs.chef.io/definitions.html

On 08/30/2015 06:43 PM, Mark Selby wrote:

Thanks for response. I fully see the utility of the include_recipe
paradigm.

Out of real curiosity you mentioned this -- "use a definition to edit
the resource collection and the definition can check and exit if the
resource always exists"

Would you happen to have any example code that might show how that works.

Thanks!

On 8/30/15 6:24 PM, Lamont Granquist wrote:

If its really a remote_file resource then those support etags and
last-modified-since so it won't be expensive to run multiple times.

Generally when you have a call-many-times-run-only-once pattern
you're looking at include_recipe'ing the expensive thing so it only
gets created once in the resource collection.

You can also use a definition to edit the resource collection and the
definition can check and exit if the resource always exists.

On 08/29/2015 01:42 PM, Mark Selby wrote:

remote_file “/var/tmp/somefile” do
source “http://binfiles/somefile”
owner “root”
group “root”
mode “0644”
action :create
end

Lets just suppose that this is a somewhat expensive operation that
may need to get called multiple times during a converge depending on
what recipes the node is running. I would like to say “do not
execute this resource if it has already been triggered during this run”

I would also not like to use a marker file if I can avoid it.

I know we have delayed execution but that is not what I want. I need
this to trigger on the first call and then not again. Can I use the
run_status or run_context to accomplish this?

Thanks!

Thanks - just what I was looking for - much appreciated

On 8/31/15 8:45 AM, Lamont Granquist wrote:

The "many recipes, one definition" example from:

http://docs.chef.io/definitions.html

On 08/30/2015 06:43 PM, Mark Selby wrote:

Thanks for response. I fully see the utility of the include_recipe
paradigm.

Out of real curiosity you mentioned this -- "use a definition to edit
the resource collection and the definition can check and exit if the
resource always exists"

Would you happen to have any example code that might show how that
works.

Thanks!

On 8/30/15 6:24 PM, Lamont Granquist wrote:

If its really a remote_file resource then those support etags and
last-modified-since so it won't be expensive to run multiple times.

Generally when you have a call-many-times-run-only-once pattern
you're looking at include_recipe'ing the expensive thing so it only
gets created once in the resource collection.

You can also use a definition to edit the resource collection and
the definition can check and exit if the resource always exists.

On 08/29/2015 01:42 PM, Mark Selby wrote:

remote_file “/var/tmp/somefile” do
source “http://binfiles/somefile”
owner “root”
group “root”
mode “0644”
action :create
end

Lets just suppose that this is a somewhat expensive operation that
may need to get called multiple times during a converge depending
on what recipes the node is running. I would like to say “do not
execute this resource if it has already been triggered during this
run”

I would also not like to use a marker file if I can avoid it.

I know we have delayed execution but that is not what I want. I
need this to trigger on the first call and then not again. Can I
use the run_status or run_context to accomplish this?

Thanks!

We are having an issue with the
12.4.1 chef client for windows 2012 R2 (12.4.0 fails as well). No matter if
we install the service via the msi or the chef_service_manager command the
chef service will not start on its own and reports to windows that it has
timed out. I have read online that if you set it to Automatic delayed that
this fixes the issue however that has not worked for us. I have also added DNS and wmi as dependencies. I can start it
manually and it runs as it should but it will not start on its own. Any help is appreciated.

Thanks

Julian

We’ve run into this issue as well on our Windows 2012R2 hosts. In our cases, it seems that setting startup to Automatic (Delayed) does indeed fix the startup problem, but from the documentation for chef_service_manager I’m not sure how to do this automatically, or if it would require some mangling via windows_service in a recipe.

We haven’t noticed this issue on other non-2012R2 Windows hosts.

Thanks,

Gregory

--
Gregory K. Ruiz-Ade gkra@unnerving.org

On Aug 31, 2015, at 9:04 AM, Julian Varanini jvaranini@hotmail.com wrote:

We are having an issue with the
12.4.1 chef client for windows 2012 R2 (12.4.0 fails as well). No matter if
we install the service via the msi or the chef_service_manager command the
chef service will not start on its own and reports to windows that it has
timed out. I have read online that if you set it to Automatic delayed that
this fixes the issue however that has not worked for us. I have also added DNS and wmi as dependencies. I can start it
manually and it runs as it should but it will not start on its own. Any help is appreciated.

Thanks

Julian

Thanks Gregory,

I forgot to mention these are AWS instances. I going to try other windows 2012r2 instances and see if the behavior changes.

Thanks again,

Julian

Sent from my iPhone

On Aug 31, 2015, at 10:12 AM, Gregory K. Ruiz-Ade gkra@unnerving.org wrote:

We’ve run into this issue as well on our Windows 2012R2 hosts. In our cases, it seems that setting startup to Automatic (Delayed) does indeed fix the startup problem, but from the documentation for chef_service_manager I’m not sure how to do this automatically, or if it would require some mangling via windows_service in a recipe.

We haven’t noticed this issue on other non-2012R2 Windows hosts.

Thanks,

Gregory

--
Gregory K. Ruiz-Ade gkra@unnerving.org
https://keybase.io/gkra

On Aug 31, 2015, at 9:04 AM, Julian Varanini jvaranini@hotmail.com wrote:

We are having an issue with the
12.4.1 chef client for windows 2012 R2 (12.4.0 fails as well). No matter if
we install the service via the msi or the chef_service_manager command the
chef service will not start on its own and reports to windows that it has
timed out. I have read online that if you set it to Automatic delayed that
this fixes the issue however that has not worked for us. I have also added DNS and wmi as dependencies. I can start it
manually and it runs as it should but it will not start on its own. Any help is appreciated.

Thanks

Julian