A new release of Juju, 2.1-rc2, and Conjure-up, are here!
## 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 j...@lists.ubuntu.com.
--
Curtis Hovey
Canonical Cloud Development and Operations
http://launchpad.net/~sinzui
--
Juju-dev mailing list
Juju-dev@lists.ubuntu.com
Modify settings or unsubscribe at:
https://lists.ubuntu.com/mailman/listinfo/juju-dev
