Skip to main content

Your submission was sent successfully! Close

Thank you for signing up for our newsletter!
In these regular emails you will find the latest updates from Canonical and upcoming events where you can meet our team.Close

Thank you for contacting us. A member of our team will be in touch shortly. Close

  1. Blog
  2. Article

Adam Stokes
on 26 June 2017

Conjure-up dev summary: Week 25


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

sudo snap install conjure-up --classic

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!

Related posts


Serdar Vural
20 September 2024

Canonical and OpenAirInterface to collaborate on open source telecom network infrastructure

5G Article

Canonical is excited to announce that we are collaborating with OpenAirInterface (OAI) to drive the development and promotion of open source software for open radio access networks (Open RAN). Canonical will bring automation in software lifecycle management to OAI’s RAN stack, alongside additional infrastructure capabilities. This will be ...


Michael C. Jaeger
29 April 2024

Kubernetes backups just got easier with the CloudCasa charm from Catalogic

Charms Article

For a native integration for Canonical’s Kubernetes platform, Juju was the perfect fit, and the charm makes consuming CloudCasa seamless for users. ...


Michael C. Jaeger
23 February 2024

What is a Kubernetes operator?

Charms Article

Kubernetes is the open source, industry-standard platform for deploying, managing and scaling containerized applications – and applications on Kubernetes are easier with operators. ...