Comment 5 for bug 1743901

While debugging, it seems we had both juju-mongodb and juju-mongodb3.2 installed. And the database on disk was *actually* juju-mongodb and a 2.4 version database.
From what I can put together in the code we have:
func packagesForSeries(series string) ([]string, []string) {
 switch series {
 case "precise", "quantal", "raring", "saucy", "centos7":
  return []string{"mongodb-server"}, []string{}
 case "trusty", "wily", "xenial":
  return []string{JujuMongoPackage, JujuMongoToolsPackage}, []string{"juju-mongodb"}

And we have code that says "if there is any error trying to install the first list of packages fallback to the second list of packages".
So the timeline as near as I can tell is that on this machine

1) There was something wrong with the cloud archive telling us about juju-mongodb3.2 so we failed to install it.
2) We triggered the fallback code to install juju-mongodb instead, and somehow that succeeded.
3) We then configured everything to run using mongo 2.4 and mmapv1 storage engine.
4) Many moons later someone came along to install juju-mongo-tools3.2, which probably has a dependency on juju-mongodb3.2
5) When Juju restarted, it noticed that it now had mongo-3.2 available, and so changed the systemd startup script to use it, and thought it could just run in the same place, which it cannot.
We'll need a bunch of upgrade steps to actually get from 2.4 on-disk-w-mmapv1 to 3.2-on-disk-with-wiredTiger.