juju-core 1.18.0

juju-core 1.18.0

A new stable release of Juju, juju-core 1.18.0, is now available.
This release replaces 1.16.6.

Getting Juju

juju-core 1.18.0 is available in trusty and backported to earlier
series in the following PPA
  https://launchpad.net/~juju/+archive/stable

If you use the local provider, be sure to install the juju-local package
if it is not already installed. Juju’s local requirements have changed.
Upgrading local juju environments without the juju-local package is not
advised.

New and Notable

* Support for proxies

* Managing authorised ssh keys

* Backup and restore the state-server (bootstrap node)

* Run arbitrary commands on some or all instances

* Use metadata generate-tools instead of sync-tools to generated
  simple streams metadata

* The bootstrap --source option was replaced with --metadata-source

* Timeouts for bootstrap are configurable for environments

* Bootstrapping the local provider for lxc no longer requires sudo

* Juju local provider can use clone for faster LXC

* Juju now supports juju-mongodb, a mongodb tuned for juju’s needs

* The "null" provider is now called "manual" in the juju config.

* The destroy-environment command requires the environment name

* Juju unset-env

* Juju retry-provisioning

* Bash completions include flags, machines, services, and units

Resolved issues

* --upload-tools failure preventing bootstrap completing.
  Lp 1239558

* Invalid SSL certificate after rebootstrapping.
  Lp 1130255

* Killing instance outside of juju, doesn't get noticed.
  Lp 1205451

* Juju bootstrap fails with openstack provider (failed unmarshaling the
  response body)
  Lp 1209003

* Manual provider bootstrap fails with error about sftp scheme.
  Lp 1235717

* Manual provider doesn't install mongo from the cloud archive.
  Lp 1238934

* Manual provider uses reverse-lookup result instead of "bootstrap-host"
  Lp 1246905

* Manual provider requires that machines have DNS records.
  Lp 1254629

* Juju broken with OpenStack Havana for tenants with multiple networks.
  Lp 1241674

* Juju destroy-environment no longer returns error when no environment
  exists
  Lp 1225238

* Local provider isn't usable after an old environment has been
  destroyed
  Lp 1238541

* Manual provider client cache prevents reuse of env by name
  Lp 1238948

* destroy-environment no longer removes .jenv
  Lp 1246343

* Manual bootstrap / provisioning does not add the ubuntu user
  Lp 1261343

* Concurrent charm deployments corrupts deployments
  Lp 1067979

* Juju status reports 'missing' instance-state when not run as root
  Lp 1237259

* Juju uses tools for the wrong architecture when unable to find correct
  tools
  Lp 1227722

* Call to relation-get failing with 'permission denied'
  Lp 1239681

Support for proxies

Proxies can now be configured for the providers in the environments.yaml
file, or added to an existing environment using "juju set-env" The
configuration options are:

    - http-proxy
    - https-proxy
    - ftp-proxy
    - no-proxy

The protocol-specific options accept a URL. The "no-proxy" option
accepts a comma-separated list of host names or addresses.

The proxy options are exported in all hook execution contexts, and also
available in the shell through "juju ssh" or "juju run".

There are three additional proxy options specific for apt. These are set
to be the same as the non-apt proxy values, but can be overridden
independently:

    - apt-http-proxy
    - apt-https-proxy
    - apt-ftp-proxy

For example, with a squid-deb-proxy running on a laptop, you can specify
the apt-http-proxy to use it for the containers by specifying the host
machine’s network-bridge:

    apt-http-proxy: http://10.0.3.1:8000

Managing authorised ssh keys

Juju's ssh key management allows people other than the person who
bootstrapped an environment to ssh into Juju machines/nodes.
The authorised-keys command accepts 4 subcommands:

    add - add ssh keys for a Juju user
    delete - delete ssh keys for a Juju user
    list - list ssh keys for a Juju user
    import - import Launchpad or Github ssh keys

"import" can be used in clouds with open networks to pull ssh keys from
Launchpad or Github. For example:

    $ juju authorised-keys import lp:wallyworld

"add" can be used to import the provided key, which is necessary for
clouds that do not have internet access.

Use the key fingerprint or comment to specify which key to delete.
You can find the fingerprint for a key using ssh-keygen.

Juju cannot not manage existing keys on manually provisioned machines.
Juju will prepend "Juju:" to the comments of all keys that it adds to a
machine. These are the only keys it can "list" or "delete".

Note that keys are global and grant access to all machines. When a key
is added, it is propagated to all machines in the environment. When a
key is deleted, it is removed from all machines. You can learn more
details by running "juju authorised-keys --help".

Backup and restore state-server (bootstrap node)

Juju provides backup and restore commands to recover the juju
state-server in case or failure. The juju backup command creates a
tarball of the state-server’s configuration, keys, and environment data.

    $ juju switch my-env
    $ juju backup

The juju restore command creates a new juju bootstrap instance using a
backup file. It updates the existing instances in the environment to
recognise the new state-server. The command ensures the state-server is
not running before it creates the replacement. As with the normal
bootstrap command, you can pass --constraints to setup the new
state-server.

    $ juju switch my-env
    $ juju restore juju-backup-2014-02-21.tgz

You can learn more details by running "juju restore --help".

Run arbitrary commands on some or all instances

The run command can be used by devops or scripts to inspect or do
work on services, units, or machines. Commands for services or units
are executed in a hook context. Charm authors can use the run
command to develop and debug scripts that run in hooks.

For example, to run "uname" on every instance:

    $ juju run "uname -a" --all

Or to run uptime on some instances:

    $ juju run "uptime" --machine=2
    $ juju run "uptime" --service=mysql

You can learn more details by running "juju run --help".

Use metadata generate-tools instead of sync-tools to generated simple
streams metadata

The sync-tools command previously generated simple streams metadata for
local juju tools when provided with the --destination option. This is no
longer the case. You can create the simple streams metadata for tools
thusly:

    $ mkdir -p $MY_DIR/tools/streams/v1
    $ mkdir -p $MY_DIR/tools/releases
    $ cp $PUBLIC_TOOLS/*tgz $MY_DIR/tools/releases
    $ juju metadata generate-tools -d $MY_DIR

Upload the tools directory to your private cloud. Set the
tools-metadata-url option in the environment’s yaml to point to the
tools URL. For more details, run "juju metadata --help".

The bootstrap --source option was replaced with --metadata-source

The juju bootstrap command previously accepted the --source option which
was the local path to a directory of juju tools. The bootstrap command
now has a --metadata-source option that accepts the local path to simple
streams metadata and tools. If your workflow previously was to download
the juju tools to a local directory, then bootstrap with the --source
option to upload the tools to your environment, you need to run "juju
metadata generate-tools" per the previous section. For more details,
run "juju bootstrap --help".

Timeouts for bootstrap are configurable for environments.

Environments that need more time to provision an instance can configure
3 options the environments.yaml. MAAS environments often need to set
bootstrap-timeout to 1800.

  - bootstrap-timeout (default: 600s)
  - bootstrap-retry-delay (default: 5s)
  - bootstrap-addresses-delay (default: 10s)

Bootstrapping the local-provider for lxc no longer requires sudo

The juju bootstrap command cannot be run as root. Bootstrap will prompt
for a password to use sudo as needed to setup the environment. This
addresses several issues that arose because the owner and permissions of
the local environment files were different from the owner of the
process. The juju status command for example now reports the status of
the machines without the need to run it with sudo.

If you have used the local provider before, you may need to manually
clean up some files that are still owned by root. The environment’s jenv
file commonly needs to be removed. If your local environment is named
"local" then there may be a local.jenv owned by root with the JUJU_HOME
directory (~/.juju). After the local environment is destroyed, you can
remove the file like this

    $ sudo rm ~/.juju/environments/local.jenv

Juju local provider can use clone for faster LXC

The local provider can use lxc-clone to create the containers used as
machines. This feature is controlled by the "lxc-clone" option. The
default is "true" for Trusty and above, and "false" for earlier Ubuntu
releases. You can try to use lxc-clone on earlier releases, but it is
not a supported. It may well work. You can enable lxc-clone in
environments.yaml thusly:

    lxc-clone: true

The local provider is btrfs-aware. If your LXC directory is on a btrfs
filesystem, the clones use snapshots and are much faster to create and
take up much less space. There is also support for using aufs as a
backing-store for the LXC clones, but there are some situations where
aufs doesn’t entirely behave as intuitively as one might expect, so this
must be turned on explicitly.

    lxc-clone-aufs: true

When using clone, the first machine to be created will create a
"template" machine that is used as the basis for the clones. This will
be called "juju-<series>-template", so for a precise image, the name is
"juju-precise-template". Do not modify or start this image while a
local provider environment is running because you cannot clone a running
lxc machine.

Juju now supports juju-mongodb, a mongodb tuned for juju’s needs

The Juju state-server (bootstrap node) prefers juju-mongodb. The package
is available in Ubuntu Trusty, the new db will be used when a Trusty
environment is bootstrapped. The juju-local package on Trusty will
install juju-mongodb if it is not already installed. Upgrades of the
juju-local package will continue to use mongodb-server to preserve
continuity with existing local environments.

Destroying environments

The destroy-environment command requires you to specify the environment
name:

    $ juju destroy-environment my-press-site

Previously, destroy-environment would destroy the current environment,
which might not be the one you want to destroy.

Juju unset-env

The unset-env command allows you to reset one or more the environment
configuration attributes to its default value in a running Juju
instance. Attributes without defaults are removed. Attempting to
remove a required attribute with no default will result in an error.
Multiple attributes may be removed at once; keys are space-separated.

    $ juju unset-env

Juju retry-provisioning

You can use the retry-provisioning command in cases where deploying
services, adding units, or adding machines fails. The command allows you
to specify machines which should be retried to resolve errors reported
in status.

For example, after you deployed 100 units and machines, status reports
that machines 3, 27 and 57 could not be provisioned because of a rate
limit exceeded error. You can ask juju to retry:

    $ juju retry-provisioning 3 27 5

Bash completions include flags, machines, services, and units

Bash command line completions are improved. Pressing the TAB key will
complete juju commands and their flags. Completion will also look up the
machines, services, and units in an environment and suggest them.

Finally

We encourage everyone to subscribe the mailing list at
juju-dev@lists.canonical.com, or join us on #juju-dev on freenode.