Over the past month and a half we have done 3 releases of the Juju GUI and with each release came a lot of great functionality. If you are not on 0.13.0 you should definitely upgrade your GUI charm to take advantage of these great new features.

Bundles!

This is probably the biggest release of the Juju GUI since it was officially unveiled. The GUI now supports importing, exporting, browsing and deploying bundles. A Bundle is a collection of charms, settings and their relations allowing you to deploy entire environments with one click. There is an excellent overview of this feature on the Juju GUI Blog.

Jorge Castro also wrote a great blog post on bundles and juju quickstart where he deploys a bundle with 17 charms, their settings and relations all with a single command.

Juju Quickstart plugin (Alpha)

The alpha release of the Juju Quickstart plugin was also released in the past month. The Juju Quickstart plugin is an opinionated plugin for Juju which makes for quick and easy deployment of the Juju bootstrap node and the Juju GUI. Follow the link for detailed information on it’s functionality.

As always, if you would like more information about Juju or full details about each release they can be found in our changelog.

While writing code for the next features in the Juju GUI I needed to test instances when charms would fail in various stages of their setup or execution. After a lot of messing around it became apparent that most charms are just too stable for this kind of testing so, I wrote a Juju Charm which is designed to fail in a large number of hooks depending on the configuration set on deploy (or later), and can relate to itself to test relation failures.

The charm, innovatively named ‘failtester’, can be found on jujucharms.com. In depth details on proper use can be found in its README but it’s really simple to use:

NOTE: THIS CHARM SHOULD ONLY BE USED FOR JUJU OR JUJU GUI DEVELOPMENT. IT HAS NO OTHER FUNCTIONALITY THAN TO FAIL PREDICTABLY.

// bootstrap your juju environment
juju bootstrap

// deploy the failtester charm
juju deploy cs:~hatch/precise/failtester

// set the failure type you want to occur
// the failtester charm will now fail in its install hook
juju set failtester install=true

KNOWN ISSUE

The charm settings are at the service level which means that any failures happen to every unit of the failtester service. The fix for this should be fairly simple to do but I don’t have any use for it at this time. If you need it feel free to ask or issue a pull request.

About a week after releasing the new service inspector in the Juju GUI we are following it up with another quick release which consists primarily of bug fixes.

The largest of those fixes are:

• Changing settings did not work in Juju Core. (Fixed)
• The GUI was unable to deploy charms without config options. (Fixed)
• Remove unit button did not work in Juju Core. (Fixed)
• Plus a number of additional fixes. You can read the full changelog here. Additional information on Juju can be found on https://jujucharms.com or join us in #juju on irc.freenode.net.

After a few months of hard work we have released the Juju GUI v0.10.0 which has the awesome new service Inspector as the default!

Quickly following up on v0.9.0 which added IE10 support, this release switches the new deployment and service inspector to be the default, switches to the new Go sandbox by default, and adds internal support for the upcoming charm bundles!

Additional information on Juju can be found on the newly redesigned https://jujucharms.com or join us in #juju on irc.freenode.net. Interested about more of the changes in this release? You can read the full changelog to see all of the other updates that come with this version and what we have been up to over the past few releases.

A couple weeks ago I had an issue…I needed to send the number values contained in an object to the server as integers. The only catch was, I didn’t know how many elements were in the object or which ones were supposed to be integers and which were supposed to be strings. I could however trust that the values in the object were appropriate for each key.

I ended coming up with a little hack using some of JavaScripts type coercion to get the results I needed.

var parsed;
Object.keys(values).forEach(function(key) {
  parsed = parseInt(values[key], 10);
  if (values[key] == parsed) {
    values[key] = parsed;
  }
});

So what’s happening here?

Object.keys(values).forEach(function(key) {

I am using the Object.keys() method to get the keys of each element in an array and then looping over them using Array.prototype.forEach() instead of using a for loop.

parsed = parseInt(values[key], 10);

In the loop I parseInt every value and store it in a temporary variable.

if (origVal == parsed) {
  values[key] = parsed;
}

Now I compare the parsed value to the original value allowing JavaScript to do it’s type coercion and if they are equal then I overwrite the original value with the parsed value, else I continue on to the next element. This works because parseInt(“2”, 10) === 2 and 2 == “2” but parseInt(“2Foo”, 10) === 2 and 2 != “2Foo”. You can see a working example here.

Although this has a fairly limited use case I hope you found the technique interesting albeit a little bit of a hack. Thanks for reading!