I believe we apt update but as part of "enable-os-update" that can be set to False.
As for what is specifically failing, it is this line:
[initandlisten] exception in initAndListen: 28662 Cannot start server. Detected data files in /var/lib/juju/db created by the 'mmapv1' storage engine, but the specified storage engine was 'wiredTiger'., terminating
AFAICT, we have always started Mongo 3.2 with the --storageEngine wiredTiger (it is part of the systemd script).
So I don't know how the directory could have been created with an mmap storage pool.
Has this been running a while? Is there some reason why a different mongo would have been installed on the machine?
(Its possible that some other package decided it wanted to have /usr/bin/mongo installed, and we had failed to install /usr/lib/juju/mongo3.2/bin/mongo, and thus we fell back to the system mongo during startup, which seemed to be working, until you installed the real mongo, and it decided to try to use it?)
I believe we apt update but as part of "enable-os-update" that can be set to False.
As for what is specifically failing, it is this line:
[initandlisten] exception in initAndListen: 28662 Cannot start server. Detected data files in /var/lib/juju/db created by the 'mmapv1' storage engine, but the specified storage engine was 'wiredTiger'., terminating
AFAICT, we have always started Mongo 3.2 with the --storageEngine wiredTiger (it is part of the systemd script).
So I don't know how the directory could have been created with an mmap storage pool.
Has this been running a while? Is there some reason why a different mongo would have been installed on the machine? juju/mongo3. 2/bin/mongo, and thus we fell back to the system mongo during startup, which seemed to be working, until you installed the real mongo, and it decided to try to use it?)
(Its possible that some other package decided it wanted to have /usr/bin/mongo installed, and we had failed to install /usr/lib/