Prevent the nodejs applications restarting on every Chef run #5

Closed
opened 2019-01-02 22:16:42 +00:00 by greg · 7 comments
Owner

It is the application_npm_install resources that are causing the nodejs services to be restarted on every Chef run

I have reported the issue upstream: https://github.com/poise/poise-javascript/issues/9 but no response. We need to find a way to use this unreleased version that fixes it (it's distributed as a gem that's a dependency in the application_javascript cookbook)

It is the `application_npm_install` resources that are causing the nodejs services to be restarted on every Chef run I have reported the issue upstream: https://github.com/poise/poise-javascript/issues/9 but no response. We need to find a way to use this unreleased version that fixes it (it's distributed as a gem that's a dependency in the application_javascript cookbook)
Owner

It would seem that poise-javascript is dead now.

It would seem that `poise-javascript` is dead now.
Author
Owner

All the application/poise projects are dead, the maintainer isn't working on them anymore. I'm currently taking a look at Chef's new app build/deployment/management system, Habitat, that looks very interesting: https://www.habitat.sh

All the application/poise projects are dead, the maintainer isn't working on them anymore. I'm currently taking a look at Chef's new app build/deployment/management system, Habitat, that looks very interesting: https://www.habitat.sh
Author
Owner

I have started from the unreleased master branch of poise-javascript (rake chef:build). That includes a change that supports the new behavior of npm install, writing "up to date" to stdout when no changes have been performed.

However, npm install now runs security auditing by default, even with the --production switch, so even the newer version of poise-javascript still causes the service to restart

audited 1654 packages in 3.93s
found 4 vulnerabilities (2 moderate, 2 high)
  run `npm audit fix` to fix them, or `npm audit` for details

I have then added the --no-audit switch to prevent the service from restart at every run, caused by the output of the npm install command missing the "up to date" string, and pushed that to a new repo: d85078fe59.

I'm going to do a PR to use that repo in our Berksfile, that works great in a VM

I have started from the unreleased master branch of poise-javascript (`rake chef:build`). That includes a change that supports the new behavior of `npm install`, writing "up to date" to stdout when no changes have been performed. However, `npm install` now runs security auditing by default, even with the `--production` switch, so even the newer version of poise-javascript still causes the service to restart ``` audited 1654 packages in 3.93s found 4 vulnerabilities (2 moderate, 2 high) run `npm audit fix` to fix them, or `npm audit` for details ``` I have then added the `--no-audit` switch to prevent the service from restart at every run, caused by the output of the `npm install` command missing the "up to date" string, and pushed that to a new repo: https://github.com/67P/poise-javascript/commit/d85078fe59bd4f16d05a9ffe6e0fc449015e4440. I'm going to do a PR to use that repo in our Berksfile, that works great in a VM
raucao reopened this issue 2019-07-03 13:57:55 +00:00
Owner

This happened again just now. I changed an env var for hal8000, but botka still restarted.

This happened again just now. I changed an env var for hal8000, but botka still restarted.
Author
Owner

It can be any of the resources inside of the application resource, I'm checking what's causing it

It can be any of the resources inside of the application resource, I'm checking what's causing it
Author
Owner

I can't reproduce the issue in a VM, but I can confirm it still happens on barnard. Subresources of the application resource aren't updating, but still the service restarts. Logs:

Recipe: kosmos-hubot::hal8000_xmpp
  * service[hal8000_xmpp] action restart
    - restart service service[hal8000_xmpp]
  * application[/opt/hal8000_xmpp] action restart
    * service[hal8000_xmpp] action restart
      - restart service service[hal8000_xmpp]
     (up to date)
Recipe: kredits-github::default
  * application[/opt/kredits-github] action restart
    * service[kredits-github] action restart
      - restart service service[kredits-github]
     (up to date)
Recipe: kosmos-hubot::botka_freenode
  * application[/opt/botka_freenode] action restart
    * service[botka_freenode] action restart
      - restart service service[botka_freenode]
     (up to date)
Recipe: kosmos-hubot::hal8000
  * application[/opt/hal8000] action restart
    * service[hal8000_nodejs] action restart
      - restart service service[hal8000_nodejs]
     (up to date)
Recipe: sockethub::default
  * application[/opt/sockethub] action restart
    * service[sockethub_nodejs] action restart
      - restart service service[sockethub_nodejs]
     (up to date)

Not high priority, to investigate more later

I can't reproduce the issue in a VM, but I can confirm it still happens on barnard. Subresources of the application resource aren't updating, but still the service restarts. Logs: ``` Recipe: kosmos-hubot::hal8000_xmpp * service[hal8000_xmpp] action restart - restart service service[hal8000_xmpp] * application[/opt/hal8000_xmpp] action restart * service[hal8000_xmpp] action restart - restart service service[hal8000_xmpp] (up to date) Recipe: kredits-github::default * application[/opt/kredits-github] action restart * service[kredits-github] action restart - restart service service[kredits-github] (up to date) Recipe: kosmos-hubot::botka_freenode * application[/opt/botka_freenode] action restart * service[botka_freenode] action restart - restart service service[botka_freenode] (up to date) Recipe: kosmos-hubot::hal8000 * application[/opt/hal8000] action restart * service[hal8000_nodejs] action restart - restart service service[hal8000_nodejs] (up to date) Recipe: sockethub::default * application[/opt/sockethub] action restart * service[sockethub_nodejs] action restart - restart service service[sockethub_nodejs] (up to date) ``` Not high priority, to investigate more later
Author
Owner

This is not an issue anymore, confirmed after working on #104 and running Chef multiple times

This is not an issue anymore, confirmed after working on #104 and running Chef multiple times
greg closed this issue 2019-10-10 10:50:19 +00:00
Sign in to join this conversation.
No Milestone
No project
No Assignees
2 Participants
Notifications
Due Date
The due date is invalid or out of range. Please use the format 'yyyy-mm-dd'.

No due date set.

Dependencies

No dependencies set.

Reference: kosmos/chef#5
No description provided.