Removing strict type-validation for string/int type configuration options (None is good!)

Hi all, Currently, one of the proof requirements within charm-tools is that all configuration options must have a default key with a matching type value for that key. Most notably, some charms omit the default key and use strict None/NULL checking within the charm. In order to statisfy this

Re: Removing strict type-validation for string/int type configuration options (None is good!)

Hi Marco, I have actually run in to this problem before you have my +1 for this! - Matt On Mon, Feb 10, 2014 at 8:49 AM, Marco Ceppi marco.ce...@canonical.comwrote: Hi all, Currently, one of the proof requirements within charm-tools is that all configuration options must have a default

Targeted unit testing pre-push

Hi folks, When I'm about to propose or land something, I'll typically run make check, or just go test ./... to ensure I haven't broken some far-away package. This can be quite slow, unnecessarily so if the packages changed don't feature in the dependencies of some of our longer running tests. I

Comparing Error packages

I propose we make a small sample program that exercises error returns in several typical ways, including the non-trivial scenarios, and then make one implementation for each competing error package, so we can see how they work out in real code. The code can be very terse, since there's no need

Re: MySQL charm: hook failed: config-changed

Hi Sebastian, I believe Marco is looking into this. In the meantime, a workaround that works for me is to set the dataset-size to a fixed (low) value, e.g.: juju deploy mysql juju set mysql dataset-size='512M' Cheers, Daniele On Mon, Feb 10, 2014 at 3:03 PM, Sebastian sebas5...@gmail.com