Juju devel 1.19.0 is released

[Curtis Hovey-Canonical]

juju-core 1.19.0

A new development release of Juju, juju-core 1.19.0, is now available.


Getting Juju

juju-core 1.19.0 is available for trusty and backported to earlier
series in the following PPA:
    https://launchpad.net/~juju/+archive/devel

Upgrading from stable releases to development releases is not
supported. You can upgrade test environments to development releases
to test new features and fixes, but it is not advised to upgrade
production environments to 1.19.0.

If you are using a development release of juju-core, and find you need
to go back to a stable release, you can find it in the juju stable PPA:
    https://launchpad.net/~juju/+archive/stable

If you have multiple sources of juju-core, you can select the version
you want using apt:
    sudo apt-get install juju-core=1.18.1*


New and Notable

* Juju debug-log command supports filtering and works with lxc

* Juju supports Azure availability sets


Resolved issues

* Juju MUST not strip binaries
  Lp 1301719

* Manual provisioned systems stuck in pending on arm64
  Lp 1302205

* Version reports "armhf" on arm64
  Lp 1304742

* Use network tags in the API
  Lp 1304905

* Juju destroy-environment on openstack should remove sec groups
  Lp 1227574

* Bootstrapping juju from within a juju deployed unit fails
  Lp 1285256

* Restarting API server with lots of agents gets hung
  Lp 1290843

* Manual provisioning requires target hostname to be directly resolvable
  Lp 1300264

* Local provider behaves poorly when juju-mongodb is not installed
  on trusty
  Lp 1301538

* Juju deploy --to lxc:0 cs:trusty/ubuntu creates precise container
  Lp 1302820

* Nasty worrying output using local provider
  Lp 1304132

* Intermittent error destroying local provider environments
  Lp 1307290


Juju debug-log command supports filtering and works with lxc

The "debug-log" command shows the consolidate logs of all juju agents
running on all machines in the environment. The command operates like
"tail -f" to stream the logs to the your terminal. The feature now
support local-provider LXC environments. Several options are available
to select which log lines to display.

The "lines" and "limit" options allow you to select the starting log
line and how many additional lines to display. The default behaviour is
to show the last 10 lines of the log. The "lines" option selects the
starting line from the end of the log. The "limit" option restricts the
number of lines to show. For example, you can see just 20 lines from
last 100 lines of the log like this:
    juju debug-log --lines 100 --limit 20

There are many ways to filter the juju log to see just the pertinent
information. A juju log line is written in this format:
    <entity> <timestamp> <log-level> <module>:<line-no> <message>

The "include" and "exclude" options select the entity that logged the
message. An entity is a juju machine or unit agent. The entity names are
similar to the names shown by "juju status". You can exclude all the log
messages from the bootstrap machine that hosts the state-server like
this:
    juju debug-log --exclude machine-0

The options can be used multiple times to select the log messages. This
example selects all the message from a unit and its machine as reported
by status:
    juju debug-log --include unit-mysql-0 --include machine-1

The "level" option restricts messages to the specified log-level or
greater. The levels from lowest to highest are TRACE, DEBUG, INFO,
WARNING, and ERROR. The WARNING and ERROR messages from the log can seen
thusly:
    juju debug-log --level WARNING

The "include-module" and "exclude-module" are used to select the kind of
message displayed. The module name is dotted. You can specify all or
some of a module name to include or exclude messages from the log. This
example progressively excludes more content from the logs
    juju debug-log --exclude-module juju.state.apiserver
    juju debug-log --exclude-module juju.state
    juju debug-log --exclude-module juju

The "include-module" and "exclude-module" options can be used multiple
times to select the modules you are interested in. For example, you can
see the juju.cmd and juju.worker messages like this:
    juju debug-log --include-module juju.cmd --include-module juju.worker

The "debug-log" command output can be piped to grep to filter the
message like this:
    juju debug-log --lines 500 | grep amd64

You can learn more by running "juju debug-log --help" and "juju help
logging"


Juju supports Azure availability sets

Azure environments can be configured to use availability sets. This
feature ensures services are distributed for high availability; as long
as at least two units are deployed, Azure guarantees 99.95% availability
of the service overall. Exposed ports will be automatically load
balanced across all units within the service.

New Azure environments will have support for availability sets by
default. To revert to the previous behaviour, the
"availability-sets-enabled" option must be set in environments.yaml like
so:
    availability-sets-enabled: false

Placement is disabled when "availability-sets-enabled" is true. The
option cannot be disabled after the environment is bootstrapped.


Finally

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


-- 
Curtis Hovey
Canonical Cloud Development and Operations
http://launchpad.net/~sinzui