Awesome!!! congrats to all!! \o/ Abs, Sebas.
2014-04-05 15:21 GMT-03:00 Curtis Hovey-Canonical <[email protected]>: > 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 >
-- Juju mailing list [email protected] Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/juju
