When enabling the "mongodb-snap" feature flag, a controller can be
successfully bootstrapped using the *develop* branch but bundle deployments
fail as the deployer worker *always* tries to use snap as the deployment
service implementation instead of the expected systemd.
To replicate:
```
export JUJU_DEV_FEATURE_FLAGS=mongodb-snap
juju bootstrap lxd lxd-test
cat > bundle.yaml <<EOT
relations:
- - keystone:shared-db
- mysql:shared-db
series: bionic
services:
keystone:
annotations:
gui-x: '500'
gui-y: '0'
charm: cs:keystone
num_units: 1
options:
admin-password: openstack
openstack-origin: cloud:bionic-rocky
worker-multiplier: 0.25
mysql:
annotations:
gui-x: '0'
gui-y: '250'
charm: cs:percona-cluster
num_units: 1
options:
max-connections: 20000
innodb-buffer-pool-size: 50%
EOT
juju deploy bundle.yaml
```
`juju debug-log` should eventually contain entries like:
machine-0: 13:11:18 INFO juju.worker.deployer checking unit "keystone/0"
machine-0: 13:11:18 INFO juju.worker.deployer deploying unit "keystone/0"
machine-1: 13:11:18 INFO juju.worker.deployer checking unit "mysql/0"
machine-1: 13:11:18 INFO juju.worker.deployer deploying unit "mysql/0"
machine-1: 13:11:18 ERROR juju.worker.dependency "unit-agent-deployer" manifold worker returned unexpected error: exit status 1
machine-0: 13:11:18 ERROR juju.worker.dependency "unit-agent-deployer" manifold worker returned unexpected error: exit status 1
The cause of this issue is that the underlying OS is running two init systems concurrently, and our service abstraction doesn't handle that well.
Specifically, snap is managing the services provided by the juju-db snap, whereas the rest of the services need to be managed by systemd. discoverInitSys