pre-install_method deployments end up with the snap and a new DB

[Paul Collins]

We recently upgraded prometheus in snappy-kpi to support the newer version of prometheus in the bootstack PPA. This resulted in the snap being installed and grafana therefore losing access to the existing prometheus database.

Setting install_method to "apt", manually removing the snap, and then starting the packaged prometheus back up, resolved the problem. But ideally when we upgrade to a version of the charm that supports the snap, it would assume that if prometheus is already installed that the snap should not be installed (or something along those lines). Related to RT#100652.

[Paul Collins (pjdc)]

There is a further side-effect: Installing snapd on trusty installs systemd, which tricks charmhelpers into thinking the systems's default init system is systemd, which causes it to (pointlessly) use "systemctl" to manipulate services instead of "service" (which works on all releases). So the charm won't deploy on trusty as is.

[Paul Collins (pjdc)]

"So the charm won't deploy on trusty as is." Michael Nelson reminds me that it deploys, but doesn't upgrade-charm successfully.

[Stuart Bishop (stub)]

Time to drop trusty support? Effort may be better spent moving forward to xenial+snap deploys.

[Stuart Bishop (stub)]

I've opened https://bugs.launchpad.net/charm-helpers/+bug/1670944 on charmhelpers vs snapd vs systemd.

[Jacek Nykis (jacekn)]

I think it would be the best to check whether deb/snap is installed and block hooks until config option is set to match current state.

This way the charm will not be able to break things and will also let user know that there is inconsistency that needs to be resolved.