juju-core devel 1.17.0 is released
curtis at canonical.com
Fri Dec 20 21:05:06 UTC 2013
A new development release of Juju, juju-core 1.17.0, is now available.
juju-core 1.17.0 is available in trusty and backported to earlier
series in the following PPA
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.
* “juju destroy-environment” requires the environment name.
* “juju upgrade-juju” chooses a safe and supported path.
* “juju metadata generate-image” uses the environment to get
much of the information written to the simple streams data.
* The “tools-metadata-url” config option replaces “tools-url”.
* --upload-tools failure preventing bootstrap completing.
HTTP connections were not properly closed to allow retries.
* Invalid SSL certificate after rebootstrapping.
Certificates and keys are destroyed with the environment to
* 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.
* Uniter: high frequency relation operations cause rate limits to
Juju now caches the API address reducing the need to be chatty.
* Juju bootstrap fails with openstack provider (failed unmarshaling the
Juju now supports OpenStack Havana with ceph-radosgw as a Swift
* Manual provider bootstrap fails with error about sftp scheme.
Juju now generates the proper metadata and uses the correct method
to locate tools.
* Manual provider doesn't install mongo from the cloud archive.
Juju now uses apt repository sources and boot commands from the
* Manual provider uses reverse-lookup result instead of "bootstrap-host"
Juju now uses the IP address of the bootstrap-host.
* Manual provider requires that machines have DNS records.
Juju no longer requires the DNS entries for manually
* Set-constraints example gives "error: malformed constraint"
The help information now documents the --service option.
* Sync-tools uploads 0kB juju tools when relative path is used
Relative paths are now accepted.
* Juju env could be friendlier to scripts.
Juju env and juju switch no longer quote the env name.
* HP Cloud boilerplate doesn't contain enough info.
The missing configuration is now included with the defaults set.
* 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.
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.
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.
We encourage everyone to subscribe the mailing list at
juju-dev at lists.canonical.com, or join us on #juju-dev on freenode.
Canonical Cloud Development and Operations
More information about the Juju