Workers not reloading on Deploy about opsworks_delayed_job HOT 10 CLOSED

Have you associated the opsworks_delayed_job::deploy recipe with your stack's Deploy event? It runs this command to restart workers during the deploy:

If that doesn't seem to be working, I'd check the logs or try the command manually.

from opsworks_delayed_job.

I did associate the recipe, and it didn't work even if I ran the recipe by itself. The logs didn't indicate any errors or that the restart command was being run. Running the monit command itself worked, so I was able to get it to work by changing recipes/deploy.rb, from:

node.set[:opsworks][:rails_stack][:restart_command] = node[:delayed_job][application[:restart_command]

opsworks_deploy do
  deploy_data deploy
  app application
end

to

execute "restart delayed_job" do
  command node[:delayed_job][application][:restart_command]
end

This makes more sense to me, as I'm not 100% sure what Opsworks does with the restart command down the pipeline. Do you see a downside? This recipe is run after the built-in deploy recipe so it should restart with the correct code.

from opsworks_delayed_job.

I can confirm that my app doesn't restart after deploy.

Many log statements got me to the stage @robamaton mentioned. I was just about to look at the restart command opsworks uses and if this hooks into it or just node.set a new method, basically, that is never called.

cutting and pasting into terminal as the deploy user works... so I'm pretty(ish) sure it's not the command itself, but whether it runs.

---- Edit -----
tldr; the execute line was what i was looking for (newish to Chef here). Good job robamaton again! Also, you should include the node.set ... line too in your code snippet at the bottom of your post. And a pull request is in order if not done already, don't want to steal your thunder.

from opsworks_delayed_job.

@robamaton @pjammer I'm stumped. Our workers have been correctly restarting on deploy. You can see where the opsworks_delayed_job::deploy recipe calls opsworks_deploy here, and where the opsworks_deploy resource calls the restart command here. I'm presuming that you have a rails layer as well, and that it does restart correctly.

The AWS cookbooks have change a bunch. Maybe there are stack differences at play here? We're running on chef 11.4 with nginx/unicorn on Amazon linux.

from opsworks_delayed_job.

I figured it out! I'm using Chef 11.10, and in the recipe in that branch it only runs the restart command if it's in the 'rails-app' layer. In my case, I use a custom layer for my DJ servers.

I'll take this to the AWS team and see what the rationale was and if there could be a workaround. I'm not a fan of my fix since it might get in the way of the normal ordering of the deploy.

from opsworks_delayed_job.

Here's the Issue I filed: aws/opsworks-cookbooks#227

from opsworks_delayed_job.

Ugh I see that now... that's unfortunate and will block our chef upgrade for the time being.

I'm not too hopeful about seeing a change [in our direction] from AWS. The path forward may be to borrow more of the opsworks_deploy code into our own cookbook. If you end up doing any work to that end, I'd certainly consider PRs.

from opsworks_delayed_job.

@robamaton The line was introduced in pull request aws/opsworks-cookbooks#165 with rationale to not try to restart Unicorn/Passenger on an instance that has a copy of the Rails app, but isn't running a web server. To me this makes sense and I think we should implement our own mechanism to restart delayed_job here. What do you guys think? I'm having the same issue btw.

from opsworks_delayed_job.

Created pull request here: #10

from opsworks_delayed_job.

Closed via #10. Available starting in v0.6 of the cookbook.

from opsworks_delayed_job.