mysql charm blows up on out of memory error

The exact error I saw in my juju log was:

2014-03-18 19:32:27 INFO juju.worker.uniter uniter.go:348 running "start" hook 2014-03-18 19:32:27 INFO juju.worker.uniter context.go:255 HOOK mysql stop/waiting 2014-03-18 19:32:30 INFO juju.worker.uniter context.go:255 HOOK start: Job failed to start 2014-03-18 19:32:30 ERROR juju.worker.uniter uniter.go:350 hook failed: exit status 1

This appears to be affecting multiple people developing using LXC - https://lists.ubuntu.com/archives/juju/2014-February/003421.html

This needs a bit more discussion on what to do, but I propose reducing the overall innodb memory pool by default to a more manageable range pending a verified fix landing aside from reducing the innodb resources.

I wonder if this is a factor in the Hp cloud issue. The mysql charm works fine on aws, azure, and localhost when constrained 2G, but it fails on HP Cloud. The charm does work when mem is increased to 4G.

This is because dataset-size is defaulting to 80% of available memory, hence why you're seeing that huge innodb_buffer_pool_size. We have a maximum allotment for i386 architectures, we may just make that global. The problem is some people may actually want that much innodb_buffer_pool_size (probably a bad idea, but still). A first step would be to update the README for MySQL to note this caveat and how to work around it.

Probably not a bad idea. stuffing it in the Caveats/Known issues directive for specific callouts per environment as to what we see. I +1 this idea. I don't know that there's really much else we can do - as there's no real reliable way to determine what substrate we are running on.