juju-core 1.17.0

juju-core 1.17.0

A new development release of Juju, juju-core 1.17.0, is now available.

Getting Juju

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

Upgrading from stable releases to development releases is not supported. You can upgrade test environments to development releases to test new features and fixes, but it is not advised to upgrade production environments to 1.17.0.

New and Notable

* “juju authorised-keys” to manage ssh keys within Juju.
  Lp 834930

* “juju destroy-environment” requires the environment name.
  Lp 1057665

* “juju upgrade-juju” chooses a safe and supported path.
  Lp 1233451

* “juju metadata generate-image” uses the environment to get
  much of the information written to the simple streams data.
  Lp 1237286

* The “tools-metadata-url” config option replaces “tools-url”.

Resolved issues

* --upload-tools failure preventing bootstrap completing.
  HTTP connections were not properly closed to allow retries.
  Lp 1239558

* Invalid SSL certificate after rebootstrapping.
  Certificates and keys are destroyed with the environment to
  prevent reuse.
  Lp 1130255

* Killing instance outside of juju, doesn't get noticed.
  The juju state server automatically removes machines when the
  connection is broken for a prolonged period.
  Lp 1205451

* Uniter: high frequency relation operations cause rate limits to
  be exceeded.
  Juju now caches the API address reducing the need to be chatty.
  Lp 1244766

* Juju bootstrap fails with openstack provider (failed unmarshaling the
  response body)
  Juju now supports OpenStack Havana with ceph-radosgw as a Swift
  back-end.
  Lp 1209003

* Manual provider bootstrap fails with error about sftp scheme.
  Juju now generates the proper metadata and uses the correct method
  to locate tools.
  Lp 1235717

* Manual provider doesn't install mongo from the cloud archive.
  Juju now uses apt repository sources and boot commands from the
  cloud-init config.
  Lp 1238934

* Manual provider uses reverse-lookup result instead of "bootstrap-host"
  Juju now uses the IP address of the bootstrap-host.
  Lp 1246905

* Manual provider requires that machines have DNS records.
  Juju no longer requires the DNS entries for manually
  provisioned machines.
  Lp 1254629

* Set-constraints example gives "error: malformed constraint"
  The help information now documents the --service option.
  Lp 1251095

* Sync-tools uploads 0kB juju tools when relative path is used
  for "--source"
  Relative paths are now accepted.
  Lp 1255006

* Juju env could be friendlier to scripts.
  Juju env and juju switch no longer quote the env name.
  Lp 1193244

* HP Cloud boilerplate doesn't contain enough info.
  The missing configuration is now included with the defaults set.
  Lp 1240116

Known issues

* Upgrades from stable releases to 1.17.0 may result in config-changed
  hook failures in units.

Managing authorised 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, eg "juju authorised-keys import lp:wallyworld".
But for clouds which do not have access to the internet, "add" can be used to import the provided key.

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 right now, 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.

For more details, run "juju authorised-keys --help" to read the help.

Destroying environments

The “destroy-environment” command requires you to specify the environment name, eg. “juju destroy-environment my-press-site”. Previously, “destroy-environment” would destroy the current environment, which might not be the one you want to destroy.

Upgrading Juju

The “juju upgrade-juju” command has changed to ensure that stable and supported versions of juju are selected.

The default behavior of “upgrade-juju” selects the *next* stable (major.minor+2) version first, failing that it selected the most recent *current* version. The Juju project uses odd minor numbers for devel releases, and even minor numbers for stable releases.

Use “--version” to explicitly specify the version to upgrade or downgrade to. The flag effectively forces an upgrade to the given
version, regardless if it's supported.

The “--dev” flag is removed, as the logic changed. The only way to
upgrade to a development version from 1.17.0 or latter is by using
“--version” to specify the exact version to upgrade to. Neither the
development flags in the environment config, nor the client's
development version are used to select the upgrade version.

Run “juju upgrade-juju --help” to read about the available options.

Generating image metadata

The “metadata generate-image” command requires fewer options to create the simple streams data. The cloud information needed to create the simple streams data comes from the environment. The environment information can may be overridden by specifying extra options.

Run “juju metadata generate-image --help” to read about the available options.

The “tools-metadata-url” config option replaces “tools-url”

The “tools-url” config option is deprecated. It will be removed in Juju 1.19.0. Use “tools-metadata-url” instead. The config option was renamed to follow the “image-metadata-url” pattern.

Finally

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