### New Bootstrap and Cloud Management Experience

This release introduces a new way of bootstrapping and managing clouds and credentials that involves less editing of files and makes Juju work out of the box with major public clouds like AWS, Azure, Joyent, Rackspace, Google, Cloudsigma.

Firstly, there is no more environments.yaml file to edit. Clouds and credentials are defined in separate files, and the only cloud information that requires editing is for private MAAS and Openstack deployments.

#### Public Clouds

So, we’ve installed Juju, let’s see what clouds are available:

    juju list-clouds

CLOUD              TYPE        REGIONS
aws                ec2         us-east-1, us-west-1, us-west-2, eu-west-1, eu-central-1, ap-southeast-1, ap-southeast-2 ...
aws-china          ec2         cn-north-1
aws-gov            ec2         us-gov-west-1
azure              azure       japanwest, centralindia, eastus2, westeurope, japaneast, brazilsouth, westindia ...
azure-china        azure       chinaeast, chinanorth
cloudsigma         cloudsigma  mia, sjc, wdc, zrh, hnl
google             gce         us-east1, us-central1, europe-west1, asia-east1
joyent             joyent      us-east-1, us-east-2, us-east-3, us-west-1, eu-ams-1, us-sw-1
rackspace          rackspace   LON, SYD, HKG, DFW, ORD, IAD

To see more detail on a particular cloud, use show-cloud:

    juju show-cloud azure

We want to bootstrap a controller on AWS. In this case, as is possible with previous versions of Juju, our credentials are already set up as environment variables so we can just get straight to it:

    juju bootstrap mycontroller aws

The default region is shown first in the list-clouds output so we’ll get a controller called “mycontroller” on us-east-1. But we can also specify a different region.

    juju bootstrap mycontroller aws/us-west-2

(Note that in the “list-clouds” output above, the order of regions is incorrect. There is a bug in the command that will be resolved in 2.0-beta2.)

#### Managing Controllers and Models

We can see what controllers I can talk to:

    juju list-controllers

CONTROLLER    MODEL         USER         SERVER
mycontroller*  mycontroller  admin@local  10.0.1.12:17070
test           test          admin@local  10.0.3.13:17070

The default controller is indicated with an *.

Note: currently the controller model (see multi-model above) is named after the controller. You would then create a new hosted model in which workloads are run. The next Juju beta will create the controller model as “admin” and an initial hosted model as part of bootstrap.

Note: locally bootstrapped controllers will be prefixed by the “local.” label in the next Juju beta. So “mycontroller” above becomes “local.mycontroller”.

It’s possible to use juju switch to select the current controller and/or model.

    juju switch mymodel        (switch to mymodel on current controller)
    juju switch mycontroller   (switch current controller to mycontroller)
    juju switch mycontroller:mymodel   (switch to mymodel on mycontroller)

To see the name of the current controller (and model), run switch with no arguments:

    juju switch

To see the full details of the current controller, run show-controller with no arguments:

    juju show-controller

Note: The model commands used for multi-model support, as outlined in the previous section, work across multiple controllers also.

  juju create-model mynewmodel -c mycontroller

The above command creates a new model on the nominated controller and switches to that controller and model as the default for subsequent commands.

#### LXD and Manual Providers 

Bootstrapping models using the LXD or manual providers also Just Works.

    juju bootstrap mycontroller lxd

    juju bootstrap mycontroller manual/<hostname>

For now, LXD just supports localhost as the LXD host which is the default.  
The manual provider sees the hostname (or IP address) specified as shown above rather than a config setting.

#### Private Clouds

For MAAS and Openstack clouds, it’s necessary to edit a clouds.yaml file. This can be done from anywhere and then the juju add-cloud command is used to add these to Juju.

clouds:
   homestack:
      type: openstack
      auth-types: [userpass, access-key]
      regions:
         london:
         endpoint: http://london/1.0
   homemaas:
      type: maas
      auth-types: [oauth1]
      endpoint: http://homemaas/MAAS

Assuming you save the above to personal-clouds.yaml, you can add the openstack cloud to Juju:

   juju add-cloud homestack personal-clouds.yaml

Then when you juju list-clouds:

CLOUD            TYPE        REGIONS
aws              ec2         us-west-2, eu-west-1, ap-southeast-2 ... aws-china        ec2         cn-north-1
aws-gov          ec2         us-gov-west-1
azure            azure       eastus, southeastasia, centralindia ... azure-china      azure       chinaeast, chinanorth
cloudsigma       cloudsigma  hnl, mia, sjc, wdc, zrh
google           gce         us-east1, us-central1, europe-west1, asia-east1
joyent           joyent      eu-ams-1, us-sw-1, us-east-1, us-east-2 ... rackspace        rackspace   ORD, IAD, LON, SYD, HKG, DFW
local:homestack  openstack   london

And now you can bootstrap that openstack cloud:

    juju bootstrap mycontroller homestack

#### Credential Management

Credentials are managed in a separate credentials.yaml file located in ~/.local/share/juju. For now, we don’t support auto discovery of credentials so this file needs to be maintained by hand. Credentials are per cloud. If there’s only one credential, that’s what’s used. Or you can define the default credential in the file. Otherwise you can specify the credential name when bootstrapping:

    juju bootstrap mycontroller aws --credential mysecrets

The credentials file supports the necessary credential types for each cloud. This is where it’s also possible to define the default region to use for a cloud if none is specified when bootstrapping.
An example credentials.yaml file:

credentials:
  aws:
    default-credential: peter
    default-region: us-west-2
    peter:
      auth-type: access-key
      access-key: key
      secret-key: secret
    paul:
      auth-type: access-key
      access-key: key
      secret-key: secret
  homemaas:
    peter:
      auth-type: oauth1
      maas-oauth: mass-oauth-key
  homestack:
    default-region: region-a
    peter:
      auth-type: userpass
      password: secret
      tenant-name: tenant
      username: user
  google:
    peter:
      auth-type: jsonfile
      file: path-to-json-file
  azure:
    peter:
      auth-type: userpass
      application-id: blah
      subscription-id: blah
      application-password: blah
  joyent:
    peter:
      auth-type: userpass
      sdc-user: blah
      sdc-key-id: blah
      private-key: blah (or private-key-path)
      manta-user: blah
      manta-key-id: blah
      algorithm: blah

#### Model Configuration at Bootstrap

When bootstrapping, it’s sometimes also necessary to pass in configuration values. These was previously done via the environments.yaml file. For this release, you can specify config values as bootstrap arguments or via a file:

    juju bootstrap
        mycontroller aws/us-west-2
        --config key1=value1 --config key2=value2 --config /path/to/file


Values as name pairs take precedence over the content of any file specified. Example:

    juju bootstrap mycontroller aws --config image-stream=daily