Comment 8 for bug 1344940

The initial op log size is calculated according to the Mongo recommendations:
http://docs.mongodb.org/manual/core/replica-set-oplog/

On 64bit Linux systems, it is 5% of the free disk space, but never less than 1GB and never more than 50GB.
So as Kapil says, on AWS deployments with an 8GB root disk, the op log size will be 1GB.

But for systems with a very big root disk, the size will indeed max out to 50GB. This is as per the documented Mongo behaviour.
What Juju does is pre-allocate the oplog prior to starting Mongo to reduce the start up delay and subsequent timing issues which were causing machine agent flakiness. But the pre-allocation is done according the the Mongo algorithm used for the file size.

On local provider, we do actually reduce the initial oplog size to improve startup times, but didn't feel the same decision to move away from the Mongo defaults would be pertinent for real cloud deployments.

The real issue is the fact that database writes appear to be occurring without an actual model change occurring. I've raised a separate bug for this, bug 1345832

The other 3 issues mentioned in this bug:

1. Mongo oplog size
I'd like to leave this the way it is since we're following Mongo recommendations (unless there's a technical reason not to and we get agreement from Kapil and William and whoever else that we should change).

2. Should the presence database be replicated.
I'll initiate a conversation but it does seem on the surface like it's not really required.

3. Don't configure a repliaset before we have one.
I'm not a Mongo expert but with ask the folks who implemented the repliaset stuff whether that's feasible.

These issues will be given top priority.