Add clouds

Juju needs to know how to connect to clouds. The process of adding a cloud, consolidates information about the cloud’s endpoints and authentication requirements into a cloud definition file.

This page contains information about adding clouds with the add-cloud command, which has both interactive and manual modes.

You don’t need to run this command if your cloud has out of the box support.

Adding clouds interactively

For new users, interactive mode is the recommended method for adding a cloud. This mode currently supports the following clouds: MAAS, Manual, OpenStack, Oracle, and vSphere.

To start the wizard, enter:

juju add-cloud

Adding clouds manually

More experienced Juju administrators can add their clouds manually. This can assist with automation.

Specific guides on manually adding a cloud can be found here:

Creating the YAML file

The manual method uses a YAML configuration file with the following format:

    type: <cloud type>
    auth-types: [<authenticaton types>]
        endpoint: <https://xxx.yyy.zzz:35574/v3.0/>

The table below shows the authentication type available for each cloud type. It does not include the interactive type as it does not apply in the context of adding a cloud manually.

cloud type authentication type
azure service-principal-secret
cloudsigma userpass
ec2 access-key
gce jsonfile,oauth2
lxd n/a, certificate (v.2.5)
maas oauth1
manual n/a
oci httpsig
openstack access-key,userpass
oracle userpass
rackspace userpass
vsphere userpass

To add a cloud manually, we supply the path to the configuration as an argument:

juju add-cloud --local <cloud-name> -f <cloud-file>

In versions prior to v.2.6.1 the add-cloud command only operates locally (there is no --local option).

Managing multiple clouds with one controller

A cloud can be added to an existing controller, thereby saving a machine and the trouble of setting up a controller within that cloud.

For example, to manage a MAAS cloud with a LXD controller making the controller "multi-cloud:

juju bootstrap localhost lxd
# Add MAAS cloud to the local client.
juju add-cloud --local maas -f maas-cloud.yaml
juju add-credential maas -f maas-credentials.yaml
# Add the same MAAS cloud to the LXD controller.
juju add-cloud --controller lxd maas

The output to the list-clouds command becomes:

Clouds on controller "lxd":

Cloud      Regions  Default    Type  Description
localhost        1  localhost  lxd   
maas             0             maas

A Kubernetes cluster can be added to an existing controller. Assuming you have a kube config with cluster credentials, adding a new controller cloud called “k8s-cloud” would be as simple as:

juju add-k8s k8s-cloud --controller lxd

And vice-versa, in a situation where services running on Kubernetes needed to interact with a stateful workload running on metal, a traditional cloud can be added to a controller running on Kubernetes.

juju bootstrap microk8s mk8s
juju add-cloud maas -f maas-cloud.yaml --controller mk8s --force
juju add-credential maas -f maas-credentials.yaml --controller mk8s

Both controller machine and workload machine(s) must be able to initiate a TCP connection to one another. There are also latency issues that may make some scenarios infeasible.

New cloud-based ‘add-model’ permissions can be set up via new commands grant-cloud and revoke-cloud.

When adding a model on a multi-cloud controller specifying the cloud name is mandatory. To continue with the example above then, to add model ‘xanadu’ to the ‘maas’ cloud:

juju add-model xanadu maas

This whole sections seems to be out of date and will need proper technical reviewing.

For instance,

When running juju add-cloud --controller lxd maas aren’t you basically duplicating what you’ve done on the 3 previous commands? At least on v 2.8

multi-cloud is not in flags.go (v2.9).

Remove this section. It is now default behaviour.

1 Like

No; we have a “lxd” cloud and we add a new cloud to the local client with the next 2 commands. Then we add that same cloud to the controller in the last command.

This is what makes it a multi-cloud controller, allowing us to add the MAAS model in the last step.

Not particularly illustrative though. We might consider skipping the local step and adding the cloud/cred directly to the controller with --controller.

A better example would illustrate the real power this affords, like bootrapping to MAAS, deploying O7k into a MAAS model, then adding the O7k as a cloud (even get more fancy and tease that one could deploy K8s onto the O7k and add that to the same controller).

We could then allude to relating applications on the different clouds and link to some cross-model relations docs.

1 Like

Is this still true? I’ve definitely added a K8s cloud to a Bare Metal controller and I’ve never set this feature flag. Is a K8s cloud a special type perahapse? I’ve never added a 2nd cloud of another type.

1 Like

No longer true! Thanks for flagging it!

  1. Joe, can you please draft something on these lines?
  1. How the list of commands would look like?

Here are a few suggestions after proofreading the doc:

There is a typo in this line above, it should read your cloud

You could simplify the sentence above, to something like this:
The manual method uses a [YAML]( configuration file with the following format:

Can a file path be something other than relative or absolute? Just say: To add a cloud manually, we supply the path to the configuration as an argument:

1 Like

I edited, adding a couple of examples for lxd->k8s and k8s->MAAS.

1 Like