A new release of Juju, 2.1-rc2, and Conjure-up, are here!

Fri Feb 17 17:22:44 UTC 2017

## What's new?

### [juju] Changes to the GUI

The `juju gui` command has changed to improve the user experience. By
default this command now uses the old 'no-browser' behaviour (i.e. it
doesn't automatically open the URL in your default web browser) and also
displays the login credential. There is a new --hide-credential option
not to show the credential.

The --no-browser option is supported but deprecated (it is effectively a
no-op). To bring up a browser, use the --browser option. For example, to
output the URL and credential, run:

    juju gui

To print the Juju GUI URL only:

    juju gui --hide-credential

To open the Juju GUI in the default browser and show admin credential
used to log into it:

    juju gui --browser

Juju now supports the new model path based URLs; these replace the URLs
containing the model UUID. So if you know the owner and name of a model,
you can easily point a browser to the following location to access the
GUI for that model:

    https://<controller-ip>:17070/gui/u/<owner>/<modelname>/

There is more information on using the built-in GUI in the online
documentation at:

    https://jujucharms.com/docs/master/controllers-gui

### [juju] Improved Openstack keystone v3 authentication

Juju now supports authentication for project and domain scopes. The
following environment variables or ~/.novarc attributes are supported:

- OS_DOMAIN_NAME
  domain name of the requested domain level authorisation scope
- OS_USER_DOMAIN_NAME
  domain name of the user
- OS_PROJECT_DOMAIN_NAME
  domain name of the requested project level authorisation scope
- OS_DEFAULT_DOMAIN_NAME
  common domain name of the user and project

The Juju autoload-credentials command may be used to import credential
attributes from either environment variables or ~/.novarc into the Juju
credential store.

See the online Openstack documentation here:

    https://developer.openstack.org/api-ref/identity/v3/

### [juju] LXD credentials

Juju now support credentials to access controllers on remote LXD hosts.
If you are just bootstrapping and adding models on your laptop there is
no change in workflow, but there is a change if you want to add models
from another machine.

Users are now expected to have a "certificate" credential for creating
LXD models. If you are on the LXD host, bootstrap and add-model will
both auto-generate a credential as needed, assuming you have access to
the LXD Unix socket.

When working with remote users on different machines, LXD-hosted
controllers need to to manually import the certificate credential from
the host machine.

To do this, first run juju autoload-credentials on the LXD host. This
will generate output similar to the following:

    Looking for cloud and credential information locally...

    1. LXD credential "localhost" (new)
    Select a credential to save by number, or type Q to quit:

Select the LXD credential (1 in the above example) and you will be asked
for the name of a cloud to link to this credential. Enter "localhost" to
specify the local LXD deployment. When the prompt re-appears, type "q"
to quit. The new certificate credential will have been created.

To export this certificate credential to a file called
localhost-credentials.yaml,
type the following:

    juju credentials localhost --format=yaml > localhost-credentials.yaml

The output file now needs to be moved to the machine and account that
requires access to the local LXD deployment. With this file on the
remote machine, the certificate credential can be imported with the
following command:

    juju add-credential localhost -f localhost-credentials.yaml

### [juju] New cloud-regions supported

Juju supports two more Google region and six more Azure regions:
- google/us-west1
- google/asia-northeast1
- azure/canadacentral
- azure/canadaeast
- azure/uksouth
- azure/ukwest
- azure/westcentralus
- azure/westus2

### [conjure-up]

- Canonical Kubernetes Spell now provides a non destructive kubectl
  experience based on Juju model names along with a wrapper
  `kubectl.$JUJU_MODEL` that can quickly be used to access that cluster.

- [documentation] Documented how to setup a simple proxy to access
  localhost deployments on remote systems
  http://conjure-up.io/docs/en/users/#running-conjure-up-remotely

- You can now customize your controller and model names during headless
  deployments
  http://conjure-up.io/docs/en/users/#customize-deployment-names

## Bugs Addressed

Check the milestones for a detailed breakdown of Juju and conjure-up
bugs corrected.

    https://launchpad.net/juju/+milestone/2.2-rc2
    https://github.com/conjure-up/conjure-up/milestone/14?closed=1

## How do I get it?

If you are running Ubuntu, you can get Juju from the juju devel ppa:

   sudo add-apt-repository ppa:juju/devel; sudo apt-get update

   sudo apt-get install juju

Or install Juju from the snap store:

   snap install juju --beta --devmode

Install conjure-up from the snap store:

   snap install conjure-up --classic --candidate

If you are on Trusty, you'll need to run a few extra commands:

   sudo apt-get install snapd
   sudo groupadd lxd && sudo usermod -a -G lxd $USER
   sudo reboot

Now you can install snaps, including conjure-up, as normal:

   snap install conjure-up --classic --candidate

Windows, CentOS, and MacOS users can get a corresponding Juju
installer at:

   https://launchpad.net/juju/+milestone/2.1-rc2

## Feedback Appreciated!

We encourage everyone to let us know how you're using Juju. Send us a
message on Twitter using #jujucharms, join us at #juju on freenode, and
subscribe to the mailing list at juju at lists.ubuntu.com.

-- 
Curtis Hovey
Canonical Cloud Development and Operations
http://launchpad.net/~sinzui