Conjure-up dev summary: Week 25

by Adam Stokes on 26 June 2017

With conjure-up 2.2.2 out the door we bring a whole host of improvements!

Improved Localhost

We recently switched over to using a bundled LXD and with that change came a few hiccups in deployments. We've been monitoring the error reports coming in and have made several fixes to improve that journey. If you are one of the ones unable to deploy spells please give this release another go and get in touch with us if you still run into problems.

Juju

Our biggest underlying technology that we utilise for deployments is Juju. Version 2.2.1 was just released and contains a number of highly anticipated performance improvements:

• frequent database writes (for logging and agent pings) are batched to significantly reduce database I/O
• cleanup of log noise to make observing true errors much easier
• status history is now pruned whereas before a bug prevented that from happening leading to unbounded growth
• update-status interval configurable (this value must be set when bootstrapping or performing add-model via the --config option; any changes after that are not noticed until a Juju restart)
• debug-log include/exclude arguments now more user friendly (as for commands like juju ssh, you now specify machine/unit names instead of tags; "rabbitmq-server/0" instead of "unit-rabbitmq-server-0".

Capturing Errors

In the past, we’ve tracked errors the same way we track other general usage metrics for conjure-up. This has given us some insight into what issues people run into, but it doesn’t give us much to go on to fix those errors. With this release, we’ve begun using the open source Sentry service (https://sentry.io/) to report some more details about failures, and it has already greatly improved our ability to proactively fix those bugs. Sentry collects information such as the conjure-up release, the lxd and juju version, the type of cloud (aws, azure, gce, lxd, maas, etc), the spell being deployed, the exact source file and line in conjure-up where the error occurred, as well as some error specific context information, such as the reason why a controller failed to bootstrap.

As with the analytics tracking, you can easily opt out of reporting via the command line. In addition to the existing --notrack option, there is now also a --noreport option. You can now also set these option in a ~/.config/conjure-up.conf file. An example of that file would be:

[REPORTING]
notrack = true  
noreport = true  

Future

Our next article is going to cover the major features planned for conjure-up 2.3! Be sure to check back soon!