Juju 1.24-alpha1 is released for testing

Curtis Hovey-Canonical curtis at canonical.com
Wed May 6 15:26:05 UTC 2015


# juju-core 1.24-alpha1

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


## Getting Juju

juju-core 1.24-alpha1 is available for vivid and backported to earlier
series in the following PPA:

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

Windows and OS X users will find installers at:

    https://launchpad.net/juju-core/+milestone/1.24-alpha1

Development releases use the "devel" simple-streams. You must configure
the `agent-stream` option in your environments.yaml to use the matching
juju agents.

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.24-alpha1.


## Notable Changes

  * Service status
  * storage (experimental)


### Service status

Juju provides new hooks for charm authors to report service status, and
'juju status' now includes the service status. This new functionality
allows charms to explicitly inform Juju of their status, rather than
Juju guessing. Charm authors have access to 2 new hook tools, and the
status report includes more information.

The 'status-set' hook tool allows a charm to report its status to Juju.
This is known as the workload status and is meant to reflect the state
of the software deployed by the chrm. Charm authors are responsible for
setting the workload's status to "Active" when the charm is ready to run
its workload, and "Blocked" when it needs user intervention to resolve a
problem.

    status-set:
        status-set <maintenance | blocked | waiting | active> "message"

The 'status-get' hook tool allows a charm to query the current workload
status recorded in Juju. Without arguments, it just prints the workload
status value eg maintenance. With '--include-data' specified, it prints
YAML which contains the status value plus any data associated with the
status.

    status-get:
        status-get [--include-data]

Charms that do not make use of these hook tools will still work as
before, but Juju will not provide details about the workload status.

The 'juju status' command includes the 'workload-status' and
'service-status' in the report. for example:

    services:
     ...
     wordpress:
       charm: local:trusty/wordpress-93
       exposed: false
       service-status:                    <-- new service status
         current: blocked
         message: Waiting for database
         since: 01 May 2015 17:39:38 AEST
       relations:
         loadbalancer:
         - wordpress
       units:
         wordpress/0:
           workload-status:                <-- new workload status
             current: blocked
             message: Waiting for database
             since: 01 May 2015 17:39:38 AEST
           agent-status:                   <-- new agent status
             current: idle
             since: 01 May 2015 17:39:44 AEST
             version: 1.24-alpha1.1
           agent-state: started            <-- legacy Juju agent state
           agent-version: 1.24-alpha1.1
           machine: "1"
           open-ports:
           - 80/tcp
           public-address: 23.20.250.14

Juju aggregates all the unit 'workload-status' values to represent the
'service-status'. The 'service-status' value is derived from the worst
case status of all the units; eg, if any unit is in error, then the
service is in error.

The 'status' command will use a table layout in the future, and you can
set the environmental variable 'JUJU_CLI_VERSION' to "2" to see it like
so:

    export JUJU_CLI_VERSION=2
    juju status

    NAME       STATUS  EXPOSED CHARM
    mysql      unknown false   local:trusty/mysql-326
    wordpress  blocked false   local:trusty/wordpress-93

The legacy status values are omitted from output. You can use the
'--yaml' option to see status in the Juju 1.x layout.

Juju also records a history of status changes for a unit, and tracks the
time when the status was last updated. The 'juju status-history' command
allows you to inspect a charm's status changes over time

    juju status-history [options] [-n N] <unit>

    options:
    -e, --environment (= "")
       juju environment to operate in
    -n  (= 20)
       size of logs backlog.
    --type (= "combined")
       type of statuses to be displayed [agent|workload|combined].
    --utc  (= false)
       display time as UTC in RFC3339 format

    This command will report the history of status changes for
    a given unit.
    The statuses for the unit workload and/or agent are available.
    -type supports:
       agent: will show statuses for the unit's agent
       workload: will show statuses for the unit's workload
       combined: will show agent and workload statuses combined
    and sorted by time of occurrence.

For example, to see the history of the unit wordpress/0

    juju status-history wordpress/0

    TIME                       TYPE     STATUS       MESSAGE
    01 May 2015 17:33:20 EST  workload  unknown      Waiting for agent
initialization to finish
    01 May 2015 17:33:20 EST  agent     allocating
    01 May 2015 17:36:37 EST  agent     executing    running install hook
    01 May 2015 17:36:37 EST  workload  maintenance  installing charm software
    01 May 2015 17:36:38 EST  workload  maintenance  installing dependencies
    01 May 2015 17:39:11 EST  workload  maintenance  installing components
    01 May 2015 17:39:18 EST  agent     executing    running leader-elected hook
    01 May 2015 17:39:18 EST  agent     executing    running config-changed hook
    01 May 2015 17:39:19 EST  workload  maintenance  configuring nginx
    01 May 2015 17:39:34 EST  workload  maintenance  restarting services
    01 May 2015 17:39:38 EST  workload  blocked      Waiting for database
    01 May 2015 17:39:39 EST  agent     executing    running start hook
    01 May 2015 17:39:44 EST  agent     idle


### storage (experimental)

Juju now models storage, charms can request storage (volumes and
filesystems), and you can specify constraints on how to satisfy those
requests (which provider, what options, how large, how many).

Initially, Juju supports native volumes for the EC2 (EBS) and OpenStack
(Cinder) providers. Juju also supports several cloud-independent storage
providers: tmpfs, loop (loop devices), root filesystem. Future versions
of Juju will extend this set with providers for Ceph, NFS, and others.

The storage feature is experimental: it has some known caveats, and has
not yet been battle hardened. Instructions on use and caveats are
documented at https://jujucharms.com/docs/devel/wip-storage.


## Resolved issues

  * Deploying into kvm with local provider, hostnames are not unique
    Lp 1326091

  * Juju status complains "config has no uuid" when no .jenv is
    present
    Lp 1436925

  * Agent panic on maas network with uppercase characters
    Lp 1446608

  * Debug-log spammed with leader-election messages
    Lp 1437015

  * Eu-central-1 aws region v4 signing required and not supported
    Lp 1447841

  * Environment variables are not propagated to jujud on vivid
    Lp 1449436

  * Rsyslog-gnutls is not installed when enable-os-refresh-update is
    false
    Lp 1424892

  * Juju stop responding after juju-upgrade
    Lp 1438489

  * Jujud won't start if apt-get of juju-mongodb package fails
    Lp 1441904

  * Juju cli compatibility option
    Lp 1450701

  * Upgrade from 1.18 to 1.23 fails: password for machine agent can't
    be set
    Lp 1451297


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



More information about the Juju-dev mailing list