originally reported as a github issue.
Currently, when running Automate 2, it manages its own supervisor and rejects any additional habitat packages. A requirement of our organization is that we have our effortless config (chef-client habitat package) managing the node that Automate is running on.
This causes a conflict as Automate will immediately unload the effortless habitat package.
We think this is a good idea and agree that we want to support people who want to use Habitat for other services (effortless config, log gathering services etc) on the same machine as Automate.
Addressing this requires that we answer a few questions:
Are users OK with Chef Automate maintaining control of the hab-sup and hab-launch versions? Currently, we carefully manage these versions as Chef Automate requires specific Habitat behavior.
Are users OK with Chef Automate potentially restarting their other services on upgrade? Right now, we control the systemd unit file for hab-sup and occasionally need to restart the entire hab-sup process tree when updates to the unit file are required: https://github.com/chef/automate/blob/master/components/automate-deployment/pkg/target/local_target.go#L62-L84
Proxy variables. Right now we set our HTTP_PROXY variables in the systemd unit file to ensure they are universally applied and to ensure that hab-sup itself always respected those variables. My guess is that users who need an HTTP proxy for automate would also need it for other services so perhaps this isn't much of an issue.
How would we handle users who want to join their hab-sup to a larger habitat ring?