tas50
commented
8 years ago @ChefRycar I'm on vacation right now, but I'll get this fixed when I get back at the end of the month. It's a straight forward enough scenario
Closed NickRycar closed 8 years ago
tas50
commented
8 years ago @ChefRycar I'm on vacation right now, but I'll get this fixed when I get back at the end of the month. It's a straight forward enough scenario
Cookbook version
3.1.0
Chef-client version
12.8.1
Platform Details
Ubuntu 14.04 & CentOS 6.7
Scenario:
Attempt to upgrade push jobs cookbook from 2.6.6 to 3.1.0
Steps to Reproduce:
Update the cookbook on the chef server to 3.1.0, and update the attributes for role/environment/node such that allow_unencrypted = true (required for interacting with push server 1.x).
Expected Result:
Upgrade of push jobs client, keeping nodes available.
Actual Result:
Upgrade will complete successfully, but with no attributes set beyond allow_unencrypted, the cookbook will now use systemd or upstart instead of the previous default, runit. However it will not remove the existing runit service, and so the server will have two processes running, and availability will flap until the runit service is manually removed.
Looking at the resource provided, it looks as though if you set the init scheme to runit explicitly in the cookbook attributes, the associated push_jobs_service_runit resource will remove the old runit service in favor of the new (see: https://github.com/chef-cookbooks/push-jobs/blob/master/resources/service_runit.rb#L71-L85), however similar logic does not exist for the upstart or systemd services, which look to lead to the above scenario.