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 [email protected], or join us on #juju-dev on freenode. PS Juju just got 20% for f**king amazing. -- Curtis Hovey Canonical Cloud Development and Operations http://launchpad.net/~sinzui -- Juju mailing list [email protected] Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/juju
