juju-core 1.11.3

juju-core 1.11.3
================

A new release of Juju, juju-core 1.11.3, is now available for testing.

Getting Juju
------------

The location of the PPA has changed, please note the new location.

juju-core 1.11.3 is available from the Juju development PPA

https://launchpad.net/~juju/+archive/devel

New and Notable
---------------

 * The new experimental local provider is now included (see below for details)
 * The --force-machine parameter used with deploy has been renamed to --to.
 * add-unit now supports direct placement via --to.
 * The assignment policy has changed to support choosing existing suitable clean machines (including containers) to which to deploy. If no clean machines are found, or if no machine specifying the configured constraints is available, a new instance is created.
 * The sync-tools command now supports a --source option.
 * Hardware information is now reported for the bootstrap machine.

Resolved issues
---------------

 * Upgrading from an environment bootstrapped with juju-1.10.0 to juju-1.11.3 should work without issues. (bug #1199680, bug #1199913, bug #1199915)

Configuration changes
---------------------

 * None

Local Provider
--------------

The local provider has been enabled. There is currently one serious restriction with it right now, IP addresses are not available on the machines shown in status. This means that you’ll see “instance-state: missing” for the machines in “juju status”.

We are working on fixing this ASAP. As a result, you aren’t able to “juju ssh” using the machine id. You can however use an installed unit name, like “juju ssh wordpress/0”.

If you have a local provider defined as follows:

    mylocal:
        type: local
        admin-secret: pork

the log files for all the running machine agents and unit agents can be found in

        ~/.juju/mylocal/log

A primary difference between the current local provider and the Juju 0.6/0.7 version is that this local provider tries to be as similar as possible to a real cloud environment. This means that each machine that is created is its own LXC container. Each container operates in exactly the same way a cloud provisioned machine would, which means that as the machine is booted the first time, it does an apt-get update and upgrade. This is why there is a delay between the LXC machine showing as started, and the status being updated to show that.

Machine-0 in this case is just the host machine, and as such, cannot host units. This is also why machine-0 will show the series to be that of the host, while the other machines use the value of default-series in your configuration.

Since the host machine operates as the bootstrap node, it has two services that are installed and managed by upstart. These are namespaced by the user and environment name. The mongodb service is called juju-db-<user>-<environment>, and the machine agent service is juju-agent-<user>-<environment>. The container names are similarly namespaced. This means that you should be able to have multiple concurrent local environments running providing the port addresses have been specified as different. This limitation however does mean that “juju bootstrap” and “juju destroy-environment” need to be run as root (using sudo). Once the environment is running though, other juju commands can be run as a regular user.

Local environments should also survive reboots. The upstart services should bring up the database and machine agent, and the containers are set to auto-start on boot.

There is no need to expose services for the local provider as there is no firewall to worry about.

New Assignment Policy
---------------------

The default out-of-the-box behaviour is unchanged. If a Juju environment is bootstrapped and charms deployed, new machine instances will be instantiated to host each new service. What the new policy does provide though is the ability to speculatively create machines using the add-machine command. These instances, being unused, will be considered when deploying a charm. Previously, a new machine instance would have been created irrespective of a suitable existing instance being available.

Testing on Canonistack and HP Cloud
-----------------------------------

A publicly readable bucket has been created for holding the Juju tools on Canonistack. To use it, put this in your ~/.juju/environments.yaml (all on one line):
public-bucket-url: https://swift.canonistack.canonical.com/v1/AUTH_526ad877f3e3464589dc1145dfeaac60

For HP Cloud the public bucket is available at:

    public-bucket-url: https://region-a.geo-1.objects.hpcloudsvc.com/v1/60502529753910

As an unstable release we do not make guarantees about clean upgrade paths of running environments from one 1.11.x version to another. However, live-upgrades should work now, and will be a supported feature of stable releases.

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

Dave Cheney
On behalf of the Juju team
https://launchpad.net/juju-core