Juju stable 1.18.0 is released

Sat Apr 5 20:44:41 UTC 2014

Awesome!!! congrats to all!! \o/

Abs,
Sebas.

2014-04-05 15:21 GMT-03:00 Curtis Hovey-Canonical <curtis at canonical.com>:

> 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 at lists.canonical.com, 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
> Juju at lists.ubuntu.com
> Modify settings or unsubscribe at:
> https://lists.ubuntu.com/mailman/listinfo/juju
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.ubuntu.com/archives/juju/attachments/20140405/e3f924a6/attachment.html>