Juju launching Ubuntu Pro instances in AWS/Azure

Is Juju capable of using Ubuntu Pro instead of Ubuntu LTS when launching units in AWS/Azure?

Ubuntu Pro is essentially Ubuntu LTS with the ubuntu advantage client enabled out of the box, with ESM and livepatch running. Is there an easy way to tell Juju to use Pro?

1 Like

It looks like this might be possible by specifying a custom machine image, per https://discourse.charmhub.io/t/new-feature-in-juju-2-8-add-custom-machine-images-with-the-juju-metadata-command/3171 it should be possible to tell juju to use a pro image with:

juju metadata add-image --series <series> <image-id>

Where series is {trusty,xenial,bionic,focal} and image-id would be the AMI of the Ubuntu Pro image.

The AMI for Ubuntu Pro 18.04 is ami-09109b16d2d9d5779, so you should in theory be able to use:

juju metadata add-image --series bionic ami-09109b16d2d9d5779

I haven’t tested this yet, but it seems possible. It might be necessary to first subscribe to Ubuntu Pro in AWS Marketplace, in order to be able to access the AMI.

It would be nice if Juju could make it easier to enable Ubuntu Pro on models in public clouds where Pro is available.

Update: It doesn’t seem to work :frowning:

I tried the above, obtaining the AMI ID from AWS marketplace two ways:

  • Using the AMI displayed on the “Configure” page for the Pro listing
  • Adding it to Service Catalog and copying the AMI out of the template for the product

In both cases, Juju can’t find the image:

Every 2.0s: juju status                                                                                                                                                               slate: Wed Jul 29 12:36:53 2020

Model  Controller     Cloud/Region   Version  SLA          Timestamp
test   aws-us-west-2  aws/us-west-2  2.8.1    unsupported  12:36:54-05:00

App     Version  Status   Scale  Charm   Store       Rev  OS      Notes
ubuntu           waiting    0/1  ubuntu  jujucharms   15  ubuntu

Unit      Workload  Agent       Machine  Public address  Ports  Message
ubuntu/0  waiting   allocating  0                               waiting for machine

Machine  State    DNS  Inst id  Series  AZ  Message
0        pending       pending  bionic      failed to start machine 0 (cannot run instances: The image id '[ami-0fd6beacda77c37e2]' does not exist (InvalidAMIID.NotFound)), retrying in 10s (9 more attempts)

I’ll open a bug.

Update: LP#:1889458


I believe that this is non-trivial for Juju to support out of the box, sadly. Each cloud provider has a different mechanism for making Ubuntu Pro available to customers, which means that there’s no opportunity to create a generalised solution.


This is the right way to go at this stage. But I do recall issues (like the one you’ve identified).

If that model is still alive, could you please check juju debug-log to see if anything specific as been reported from AWS?

I’d already destroyed the model and controller so I bootstrapped another to reproduce.

This time it got a little farther and Juju seemed to provision a Pro instance! … but it failed to auto-attach. I’ve added details to https://bugs.launchpad.net/juju/+bug/1889458 and also https://github.com/canonical/ubuntu-advantage-client/issues/1136. Not sure if it’s a ua client bug, or something weird Juju is doing to the instance to break ua client…

As to why the instance completely failed to provision earlier… us-east-1 is my usual testing ground for Pro and I launch it regularly through the EC2 dashboard there, but it was acting up for me earlier, so I chose us-west-2. I suspect that because I’ve never launched 18.04 Pro in that region, somehow the AMI wasn’t available via APIs that Juju uses to provision instances – but this is just a wild guess!

That makes some sense. One of the quirks of AWS is that each of their AMI’s are region-specific.

1 Like

[Update] It turns out that it is possible to use Ubuntu Pro with Juju 2.8’s metadata add-image feature. However, using Pro images with Juju somehow uncovered a bug in cloud-init, which will be SRU’d. In the meantime, there is a workaround if you’d like to try it out.

1 Like

Thanks for doing the legwork on this, @cmars, and for documenting the workaround.