MySQL doesn't deploy due to oversized dataset

[Jorge Castro]

See https://bugs.launchpad.net/juju-core/+bug/1300899

We need to fix this, this makes MySQL undeployable on LXC.

[Ryan Beisner (1chb1n)]

Any time we change a default config value, we really need to take a hard look at the impact.

There are likely many enterprises out there, deploying this charm with the sensible default that it has. 80% is reasonable, when the charm is deployed into a machine. When it is co-located, or placed in a container, that may understandably not be reasonable.

I would suggest that if an alternate or lower value is necessary for users in a constrained environment (such as in a container), that the README should reflect that need, and the user should have to set the config option accordingly.

[Ryan Beisner (1chb1n)]

Alternatively, the charm could also grow "i'm in a container" logic, as mbruzek suggests @ https://bugs.launchpad.net/juju-core/+bug/1300899/comments/2. Although that could also be suboptimal or confusing to the user, in that the charm would then potentially be behaving inconsistently with the configured option value. It's a slick idea though, if there is a way to make the behavior it ultra-clear to the user.

[Marco Ceppi (marcoceppi)]

The feedback I received from Oracle is that 80% is a ridiculous number to use for dataset-size. I need to confirm, but I'm fairly certain defaults don't get updated on existing deploys. If that's the case I don't see the harm in setting a sane default regardless of containerized state.

I'll update the tests regarding this if my local upgrade test validates it remains the previous default.

[Marco Ceppi (marcoceppi)]

any configuration value that is a default value "default: True" will be changed and config-changed run on upgrade. I'm going to update this anyways to use the distro default of 134217728 bytes and fix the testing. There's a larger discussion on the mailing list about updating configuration options that I'll wait for the conclusion of

[Ryan Beisner (1chb1n)]

Right, 80% may not make a lot of sense actually, depending on the scenario. Unfortunately, it is an established default, and I think we would need to proceed carefully.

I'm all for sensible defaults. I do think we need to take a hard look at the potential impact of a default charm config option value change, any time that is considered. My main concern is that, in changing a default value, we risk breaking existing users. As long as we give advanced notice, eta, updated docs, release notes, etc., I think it should be a completely reasonable thing to pursue a default value change.

We would also need to take a look at the bundles in the charm store to identify and adjust any which rely on the established default value. For example... ;-) and I'm not at all biased:
https://jujucharms.com/openstack-base/36 (https://api.jujucharms.com/charmstore/v4/bundle/openstack-base-36/archive/bundle.yaml)

That one is easy enough to identify and fix. We just need to take the time to evaluate, discuss, identify the risks and the things-to-do, then do them, if that is the consensus.

[Andrew Wilkins (axwalk)]

Whether the dataset-size is changed or not, seems to me we should improve how we do LXC containers in Juju. I think this solution was talked about before:

- use lxcfs inside LXC containers, which would provide (among other things) a /proc/meminfo that respects the cgroup memory limit
- default LXC container memory limit to something smallish, and have it configurable via the "mem" constraint

If this is done, then I think it alleviates the main concern of mysql not working with LXC OOTB. It may still be the case that 80% is too much in general, but I think that's a separate concern.

(Caveat: I think lxcfs is only packaged for 15.04+?)

[Ryan Beisner (1chb1n)]

Re-ping to rebase the proposed changes in the linked branch so that we may test with the proposed default value change. Only through successful testing with fresh bread will we be able to +1. Thanks!

[andrew (ford885)]

Tested this on http://ultimatewebtraffic.com/ staging. Seems to work fine now, thanks!