Issue running write_config recipe on its own

[swrobel]

I get an error when trying to run opsworks_custom_env::write_config on my instances that aren't rails app servers (these are worker instances). Here is a gist of the stacktrace: https://gist.github.com/swrobel/933f8bac7279b5767fde

The issue seems to have something to do with this line: https://github.com/joeyAghion/opsworks_custom_env/blob/master/definitions/custom_env_template.rb#L16

Aside from that, I'm at a bit of a loss ... any ideas?

[joeyAghion]

Hi @swrobel. Yes--the write_config recipe is unfortunately pretty coupled to the rails-app layer. Note the comment mentioning the dependency.

That said, I achieve this for our worker layer by instead invoking a wrapper recipe that looks something like:

# This name matches the restart resource notified by opsworks_custom_env.
execute "restart Rails app myapp for custom env" do
  command "sleep 30 && sudo monit restart -g delayed_job_myapp_group"
  action :nothing
end

include_recipe "opsworks_custom_env::write_config"

You'd replace the execute command with whatever's needed by your workers. Let me know if that works for you. Also, I'm very open to suggestions about how to improve this (while still allowing it to work seamlessly for standard rails layers).

[swrobel]

Hm, I don't really understand how notifies/execute work but why not just do it this way in an alternative wrapper recipe?

include_recipe "opsworks_custom_env::write_config"
include_recipe "sidekiq::restart"

[swrobel]

Here's my fix: https://github.com/CultConspiracy/opsworks_custom_env/commit/38351bb9374618d9856417401bd482e3da980827

[joeyAghion]

The notifies ensures the app gets restarted if there are changes in the template's output, but doesn't if there are none.

I think I have an idea about how to make the recipe a little easier to re-use. I'll leave this open and follow up if I get that to work.

[alexchumak]

Hey @joeyAghion did you have a chance to check out @swrobel's fix? Or play around with the idea you had?

I am also facing the problem of running DJ on a non 'rails-app' worker instance... His fix appears to be a good solution to that problem.