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 proof rule, which is currently a WARNING level (meaning it does not interrupt juju operation, but can affect tools within the ecosystem), we've taken to adding `default: ` to these missing keys. The reason being we had no way previously to set a None/NULL type value via the command line. Given that we now have the ability to do so via `juju unset` I'd like to propose we drop the requirement of having strict type checking and allow None/NULL as a valid configuration default for both string and int types (but not bool). In doing so we will still require you have a default: key present but it set to an appropriate value of either a value of the type the configuration is OR None/NULL[0] A WARNING will still be raised if no default key is present or if the default key is not the type the configuration option expects (and in the case of string or int, also not NULL/None) Looking for some +1's or feedback on this policy change, hoping to get it released in the next version of charm-tools. Thanks, Marco Ceppi [0]: http://yaml.org/type/null.html -- Juju mailing list Juju@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/juju
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 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 proof rule, which is currently a WARNING level (meaning it does not interrupt juju operation, but can affect tools within the ecosystem), we've taken to adding `default: ` to these missing keys. The reason being we had no way previously to set a None/NULL type value via the command line. Given that we now have the ability to do so via `juju unset` I'd like to propose we drop the requirement of having strict type checking and allow None/NULL as a valid configuration default for both string and int types (but not bool). In doing so we will still require you have a default: key present but it set to an appropriate value of either a value of the type the configuration is OR None/NULL[0] A WARNING will still be raised if no default key is present or if the default key is not the type the configuration option expects (and in the case of string or int, also not NULL/None) Looking for some +1's or feedback on this policy change, hoping to get it released in the next version of charm-tools. Thanks, Marco Ceppi [0]: http://yaml.org/type/null.html -- Juju mailing list Juju@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/juju -- - Matt -- Juju mailing list Juju@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/juju
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 possibly reinvented the wheel, but I've just written a simple program to filter a package list by those that depend on a specified list of packages. You can get it here: https://github.com/axw/rdep For example, I just modified the environs and provider/manual packages in a WIP. From the juju-core directory, I run rdep -tests ./... ./environs/ ./provider/manual | xargs go test and this ran tests for 39 packages rather than 155. I may or may not write another tool at some point to list which packages have changed since a specified rev, but it's easy enough to do that bit by hand (bzr status -r -N). Cheers, Andrew -- Juju-dev mailing list Juju-dev@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/juju-dev
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 for real logic other than control flow and error handling, but it can involve things like passing an error back through several levels, sending an error over a channel from one goroutine to another, masking errors we don't want exposed, handling third party errors, and using internal custom error types. I think this is the best way to compare the error packages, since we'll see first hand how they would look being used in real code. -- Juju-dev mailing list Juju-dev@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/juju-dev
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 wrote:
Hi! I'm with the same issue with juju-local and the mysql charm, maybe is
because the version of the Ubuntu is Trusty.
I tried a lot of things, like creating swap into the container, and
lowering the innodb_buffer_pool_size, but it seems that nothing is
working, so mysql isn't starting.
Some help would be great!
Cheers!,
Sebas.
2014-02-06 12:39 GMT-02:00 Marco Ceppi marco.ce...@canonical.com:
Hi Daniele,
That's expected behavior with Amulet, as it caches the charm locally to
do some verification against the charms in the deployment. So it deploys
from local: rather than the charm store.
As for the dataset-size, if 80% isn't a sane value, I'll try various
other default values to make sure it deploys consistently and everytime on
all cloud providers. I'm in the process of writing tests for the MySQL
charm so we'll have better exposure of this issue sooner.
Thanks,
Marco Ceppi
On Thu, Feb 6, 2014 at 9:23 AM, Daniele Stroppa
daniele.stro...@joyent.com wrote:
David,
I missed that requirements, I was using the 3.5 kernel. I've updated to
the raring kernel, and deploying mysql using 'juju deploy' with no
additional configuration still give the same issue. Setting the
innodb_buffer_pool_size as mentioned yesterday works fine.
@Marco: One thing I've noticed is that when deploying mysql with juju
deploy the charm being deployed is 'cs:precise/mysql-33', while when
running the test the charm is 'local:precise/mysql-310' (in the .py file I
do specify 'd.add('mysql', charm='cs:precise/mysql-33')'). Is this normal?
Daniele
On Wed, Feb 5, 2014 at 8:05 PM, David Cheney david.che...@canonical.com
wrote:
You said earlier that you were using the local provider. Have you
applied the raring kernel update to this machine ? This is required if you
want to use LXC on Precise.
On Thu, Feb 6, 2014 at 3:44 AM, Daniele Stroppa
daniele.stro...@joyent.com wrote:
David,
I'm using juju 1.16.4.1 on Ubuntu 12.04. If I just deploy mysql with
no config changes, the issue still exists. However, if I decrease the size
of the innodb_buffer_pool_size setting (using juju set mysql
dataset-size='512M') as stated in
https://bugs.launchpad.net/juju-core/+bug/1236994 it works fine.
Daniele
On Wed, Feb 5, 2014 at 9:30 AM, David Cheney
david.che...@canonical.com wrote:
https://bugs.launchpad.net/juju-core/+bug/1236994 is a dup of
https://bugs.launchpad.net/juju-core/+bug/1247299, both of which are
claimed to be resolved.
Daniele, if this is still a problem with the latest development
release of Juju please reopen one of these or open a new issue as soon as
possible.
On Wed, Feb 5, 2014 at 8:25 PM, Jorge O. Castro jo...@ubuntu.comwrote:
On Tue, Feb 4, 2014 at 11:10 PM, David Cheney
david.che...@canonical.com wrote:
Looks like an apparmor issue to me.
We've had this problem in the past with MySQL/apparmor/local
provider:
https://bugs.launchpad.net/juju-core/+bug/1236994
https://bugs.launchpad.net/juju-core/+bug/1247299
--
Jorge Castro
Canonical Ltd.
http://juju.ubuntu.com/ - Automate your Cloud Infrastructure
--
Juju mailing list
j...@lists.ubuntu.com
Modify settings or unsubscribe at:
https://lists.ubuntu.com/mailman/listinfo/juju
--
Juju-dev mailing list
Juju-dev@lists.ubuntu.com
Modify settings or unsubscribe at:
https://lists.ubuntu.com/mailman/listinfo/juju-dev
