[ANN] juju-core 1.11.3 has been released

[David Cheney]

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. (see
below for details)
 * 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 name
spaced 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
name spaced. 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 at lists.canonical.com, or join us on #juju-dev on freenode.

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