A stable release of Juju, juju-core 1.25.5, is now available. This release replaces version 1.25.3

Getting Juju

juju-core 1.25.5 is available for Xenial and backported to earlier series in the following PPA:

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

Windows, Centos, and OS X users will find installers at:

https://launchpad.net/juju-core/+milestone/1.25.5

Notable Changes

This releases addresses stability and performance issues.

Resolved issues

• Jujud offers poodle vulnerable sslv3 on 17070 Lp 1536269

• Leadership dependency failures in ci deploy tests Lp 1539656

• Upgrade 1.24.7 -> 1.25.3 fails Lp 1546100

• Destroyed leader, new leader not elected. Lp 1511659

• New ec2 korea region Lp 1530957

• Maas bridge script handles vlan nics incorrectly Lp 1532167

• 1.25.0: bootstrap failure - warning discarding api open error: eof Lp 1538303

• Bootstrap node does not use the proxy to fetch tools from streams.c.c Lp 1515289

• Payload/persistence intermittent failure Lp 1519061

• 1.25.3 can't bootstrap xenial environments Lp 1550306

• Enable daily image stream in juju local provider Lp 1554073

• Juju's maas bridge script is echoed to the console by cloud-init during bootstrap Lp 1536587

• Cookies file locked for too long Lp 1534643

• 1.25.4: units attempt to go through the proxy to download charm from state server Lp 1556207

• Xenial juju 1.25.3 unable to deploy to lxc containers Lp 1557345

• Provider/maas bridge script is not idempotent Lp 1553915

• Unable to bootstrap lxd provider on s390x Lp 1554675

• Gce invalid volume id destroying environment Lp 1556293

• Juju_availability_zone not set in maas Lp 1559099

• Handle multi-series charms in 1.25 Lp 1563607

• Apt-mirror is not used in containers with maas provider Lp 1560391

• Proxy updater fails with "permission denied" Lp 1564694

• Can-upgrade-to suggests a downgrade Lp 1319890

A new stable release of Juju, juju-core 1.25.3, is now available. This release replaces version 1.25.0.

Getting Juju

juju-core 1.25.3 is available for Xenial and backported to earlier series in the following PPA:

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

Windows, Centos, and OS X users will find installers at:

https://launchpad.net/juju-core/+milestone/1.25.3

Notable Changes

This releases addresses stability and performance issues.

Resolved issues

• Unit loses network connectivity during bootstrap: juju 1.25.2 + maas 1.9 Lp 1534795

• "cannot allocate memory" when running "juju run" Lp 1382556

• Bootstrap with the vsphere provider fails to log into the virtual machine Lp 1511138

• Add-machine with vsphere triggers machine-0: panic: juju home hasn't been initialized Lp 1513492

• Using maas 1.9 as provider using dhcp nic will prevent juju bootstrap Lp 1512371

• Worker/storageprovisioner: machine agents attempting to attach environ-scoped volumes Lp 1483492

• Restore: agent old password not found in configuration Lp 1452082

• "ignore-machine-addresses" broken for containers Lp 1509292

• Deploying a service to a space which has no subnets causes the agent to panic Lp 1499426

• /var/lib/juju gone after 1.18->1.20 upgrade and manual edit of agent.conf Lp 1444912

• Juju bootstrap fails to successfully configure the bridge juju-br0 when deploying with wily 4.2 kernel Lp 1496972

• Incompatible cookie format change Lp 1511717

• Error environment destruction failed: destroying storage: listing volumes: get https://x.x.x.x:8776/v2//volumes/detail: local error: record overflow Lp 1512399

• Replica set emptyconfig maas bootstrap Lp 1412621

• Juju can't find daily image streams from cloud- images.ubuntu.com/daily Lp 1513982

• Improper address:port joining Lp 1518128

• Juju status broken Lp 1516989

• 1.25.1 with maas 1.8: devices dns allocation uses non-unique hostname Lp 1525280

• Increment minimum juju version for 2.0 upgrade to 1.25.3 Lp 1533751

• Make assignment of units to machines use a worker Lp 1497312

• juju environments fails due to missing ~/.juju/current- environment Lp 1506680

• Juju 1.25 misconfigures juju-br0 when using maas 1.9 bonded interface Lp 1516891

• Destroy-environment on an unbootstrapped maas environment can release all my nodes Lp 1490865

• On juju upgrade the security group lost ports for the exposed services Lp 1506649

• Support centos and windows image metadata Lp 1523693

• Upgrade-juju shows available tools and best version but did not output what it decided to do Lp 1403655

• Invalid binary version, version "1.23.3--amd64" or "1.23.3--armhf" Lp 1459033

• Add xenial to supported series Lp 1533262

A new stable release of Juju, juju-core 1.25.0, is now available. This release replaces version 1.24.7.

Getting Juju

juju-core 1.25.0 is available for Wily and backported to earlier series in the following PPA:

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

Windows Centos, and OS X users will find installers at:

https://launchpad.net/juju-core/+milestone/1.25.0

Notable Changes

• (Experimental) Improved networking features for AWS
  • New 'spaces' and 'subnet' commands
  • New 'spaces' constraints support
• Support for "devices" on MAAS 1.8+
• Storage support for GCE and Azure providers
• Payload management for charmers

(Experimental) Improved networking features for AWS

Juju has experimental support for deploying services on AWS in isolation, taking advantage of the enhanced AWS VPC networking features. This is just a first step towards a full-fledged networking model support in Juju.

New 'spaces' and 'subnet' commands

Juju introduces the 'space' and 'subnet' commands to manage the networks available to services. A Juju network space is a collection of related subnets that have no firewalls between each other and have the same ingress and egress policies.

You can create a new Juju space, and optionally associate existing subnets with it by specifying their CIDRs using the 'create' subcommand. The command looks like this:

juju space create <name> [<CIDR1> <CIDR2> …]

The list of registered spaces can be seen using the 'list' subcommand:

juju space list [--short] [--format yaml|json] [--output <path>]

You can add an existing AWS subnet to a space by CIDR or AWS ID, for example:

juju subnet add <CIDR>|<AWS-subnet-id> <space-name>

You can list all the subnets known by Juju and optionally filtering them by space and/or availability zone like so:

juju subnet list [--zone <name>] [--space <name>] [<zone1> <zone2> …]

For more information about these commands, type:

juju <command> --help

New 'spaces' constraints support

The new 'spaces' constraint instructs Juju to deploy a service's units in subnets of the given space.

Similar to the 'tags' constraint, the 'spaces' constraint takes a comma- delimited list of existing Juju network spaces. Both positive (without prefix) and negative (prefixed by "^") spaces are allowed in the list. For this alpha release, the first positive space name is used, the rest is ignored.

You can constrain a service to a space like this:

juju deploy <charm-URL> [<service-name>] [--constraints "spaces=<list>"]

For more information, run

juju help glossary

and

juju help constraints

Known issues

Deploying a service to a space that has no subnets will cause the agent to panic and is a known issue (https://launchpad.net/bugs/1499426). This issue can be mitigated by always adding at least one subnet to the space.

Support "devices" on MAAS 1.8+

MAAS 1.8 introduced a new feature called "devices". This allows the association of a "device", that requires an IP address, with a parent machine managed by MAAS. There is a view in the MAAS UI showing all devices.

Storage support for GCE and Azure providers

Juju's storage feature can now be used with the Google Compute Engine and Azure providers. Storage is now supported for local, AWS, Openstack, MAAS, GCE and Azure. See https://jujucharms.com/docs/devel/storage for more information.

Status for storage volumes

Volumes now have status associated, so provisioning progress can be observed. List the volumes to see their status:

juju storage volume list

Payload management for charmers

The new payload management feature allows charmers to more accurately define large and complex deployments by registering different payloads, such as LXC, KVM, and docker, with Juju. This lets the operator better understand the purpose and function of these payloads on a given machine.

You define these payloads in the metadata.yaml of the charm under the payloads section. You create a class for the payload, "monitoring" or "kvm- guest", and assign the type.

payloads:
    monitoring:
        type: docker
    kvm-guest:
        type: kvm

From your charm hook you can manage your payload with the following commands:

payload-register <type> <class> <ID> [tags]
payload-unregister <type> <class> <ID>
payload-status-set <type> <class> <ID> <starting, running, stopping, stopped>

From the Juju command line you can view your payloads like this:

  juju payloads <filter>

For more information run:

juju help payloads

Resolved issues

• Failed configuring a static ip for container "1/lxc/0": cannot allocate addresses: instid not supported Lp 1498982

• Addresses logged by apiaddressupdater aren't accurate Lp 1497098

• Server should handle tools of unknown or unsupported series Lp 1403689

• Provider/gce: devicenames populated in volume attachment info are invalid Lp 1500703

• Provider/ec2: volumes should be attached with name "xvdf" instead of "xvdf1" by default Lp 1500721

• Provider/ec2: "iops" should be per-gib in ebs pool config Lp 1501637

• Provider/ec2: min/max ebs volume sizes are wrong for ssd/iops Lp 1501642

• Worker/storageprovisioner: worker bounces upon finding invalid volume/filesystem params Lp 1501710

• Config-get returns scientific notation for large ints Lp 1302118

• Sending a sigabrt to jujud process causes jujud to uninstall (wiping /var/lib/juju) Lp 1464304

• Juju-core 1.20.11 crashes (sigsegv) if apiaddresses key is missing from agent.conf Lp 1392814

• Session closed in data source Lp 1497829

• Support use of cloud-images mirror for container images Lp 1357045

A new stable release of Juju, juju-core 1.24.7, is now available. This release replaces version 1.24.6.

Getting Juju

juju-core 1.24.7 is available for Wily and backported to earlier series in the following PPA:

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

Windows, Centos7, and OS X users will find installers at:

https://launchpad.net/juju-core/+milestone/1.24.7

Notable Changes

The default EC2 instance is m3.medium

AWS deprecated the m1.* instance type. Juju now uses the m3.medium as the default instance type when provisioning machines in EC2.

• m1.* instances will only be selected when specified using the "instance-type" constraint.

• When no constraints are specified, the m3.medium type will be selected.

• When constraints are specified, m1 instance types which satisfy the constraints will be ignored.

Use the "storage" feature flag to try charms that support storage.

Storage was classified as experimental in 1.24, and has been found to be problematic. Since storage is used implicitly by charms with default stores, the feature was placed behind a feature flag. You can test charms that support storage by bootstrapping a new environment with "storage" enabled like so:

JUJU_DEV_FEATURE_FLAG=storage juju bootstrap

Resolved issues

• Maas provider with maas 1.9 - /etc/network/interfaces "auto eth0" gets removed and bridge is not setup Lp 1494476

• Switch default instance type from m1.small to t2.small/m3.medium for ec2 provider Lp 1373516

• Destroy-environment reports warning cannot delete security group Lp 1335885

• Storage should be behind a feature flag in 1.24 Lp 1503740

• Configstore should break fslock if time > few seconds Lp 1500613

• Config-changed error does not cause error state Lp 1494542

• Setapihostports shouldn't record just one address per api server Lp 1497094

• Failed worker can result in large number of goroutines and open socket connections and eventually gets picked on by the oom killer Lp 1496750

• Upgrade in progress reported, but panic happening behind scenes Lp 1493123

• juju occasionally switches a units public-address if an additional interface is added post-deployment Lp 1435283

A new stable release of Juju, juju-core 1.24.6, is now available. This releases replaces 1.24.5.

Getting Juju

juju-core 1.24.6 is available for Wily and backported to earlier series in the following PPA:

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

Windows, Centos7, and OS X users will find installers at:

https://launchpad.net/juju-core/+milestone/1.24.6

Notable Changes

This releases addresses stability and performance issues.

Resolved issues

• Regression: juju ssh dies with (publickey) Lp 1472632

• Juju bootstrap fails to work due to incorrect identities restriction. Lp 1486074

• Cpu-power constraint conflicts with with instance-type when trying to launch a t2.medium Lp 1489142

• I/o timeout errors can cause non-atomic service deploys Lp 1486553

• Juju status should show if an upgrade is available Lp 1464633

• Juju bootstrap failed - cannot dial mongo to initiate replicaset: no reachable servers Lp 1468579

• Storage/provider: managedfs fails to create fs on full disks Lp 1483086

• Provider/maas: volume source won't work for physical machines/disks Lp 1483082

• Upgrade fails if no explicit version is specified Lp 1447899

• Juju upgrade from 1.24-beta2 to 1.24.5 broken Lp 1493444

• Cannot remove an environment user with upper case characters Lp 1467037

A new stable release of Juju, juju-core 1.24.5, is now available. This release replaces version 1.24.4.

Getting Juju

juju-core 1.24.5 is available for Wily and backported to earlier series in the following PPA:

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

Windows, Centos, and OS X users will find installers at:

https://launchpad.net/juju-core/+milestone/1.24.5

Notable Changes

This releases addresses stability and performance issues.

Resolved issues

• Deploy hangs: jujud-machine-0 upstart process running but juju status shows it down Lp 1481368

• Juju uses proxy to access bootstrap node Lp 1478660

A new stable release of Juju, juju-core 1.24.4, is now available. This release replaces version 1.24.3.

Getting Juju

juju-core 1.24.4 is available for Wily and backported to earlier series in the following PPA:

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

Windows and OS X users will find installers at:

https://launchpad.net/juju-core/+milestone/1.24.4

Notable Changes

This releases addresses stability and performance issues.

Resolved issues

• Looping config-changed hooks in fresh juju-core 1.24.3 openstack deployment Lp 1478024

• Cannot boostrap from custom image-metadata-url or by specifying metadata-source Lp 1452422

• No output from ssh problems during bootstrap Lp 1477358

• Leadership unreliable in HA Lp 1461890

• Juju 1.22.6 cannot upgrade to 1.24.3/1.24.4 Lp 1479931

A new stable release of Juju, juju-core 1.24.3, is now available. This release replaces version 1.24.2.

Getting Juju

juju-core 1.24.3 is available for Wily and backported to earlier series in the following PPA:

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

Windows, OS X, and Centos users will find installers at:

https://launchpad.net/juju-core/+milestone/1.24.3

Notable Changes

This releases addresses stability and performance issues.

Resolved issues

• Upgrade fails on windows machines Lp 1471332

• Juju 1.24.0: wget cert issues causing failure to create containers on 14.04.2 with lxc 1.07 Lp 1472014

• Juju environment not usable after the upgrade Lp 1473517

• Rsyslog connections fail with certificate verification errors after upgrade to 1.24.2 Lp 1474614

• Rebooting the virtual machines breaks juju networking Lp 1474508

• Failed upgrade, mixed up ha addresses Lp 1463480

• Debug-log does not work with local provider Lp 1464335

• Jujud hanging after upgrading from 1.24.0 to 1.24.1(and 1.24.2) Lp 1468653

• Juju bootstrap fails - waiting for api to become available error cannot get all blocks: eof Lp 1468581

• Tools migration fails when upgrading 1.20.14 to 1.24.1 on ec2 Lp 1469130

• State server seems to have died Lp 1469199

• Github.com/juju/utils has contradictory licences Lp 1472749

• Transient error with juju-unit-agent on windows hosts Lp 1430245

• Agent shutdown can cause cert updater channel already closed panic Lp 1472729

• Juju 1.24 memory leakage Lp 1474195

• $set updates may clear out the env-uuid field Lp 1474606

• Ec2: provisioning machines sometimes fails with "tagging instance: the instance id does not exist" Lp 1474788

• When the uniter fails to run an operation due to an error, the agent state is not set to "failed" Lp 1475163

A new stable release of Juju, juju-core 1.24.2, is now available. This release replaces version 1.24.0.

Getting Juju

juju-core 1.24.2 is available for Wily and backported to earlier series in the following PPA:

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

Windows, Centos, and OS X users will find installers at:

https://launchpad.net/juju-core/+milestone/1.24.2

Notable Changes

This releases addresses stability and performance issues.

Resolved issues

• Destroy-machine --force no longer forceably destroys machine Lp 1464616

• Inconsistent juju status from cli vs api Lp 1467690

• Dhcp addresses for containers should be released on teardown Lp 1348663

• "relation-set --file -" doesn't seem to work Lp 1454678

• Debug-hooks no longer works with 1.24-beta6 Lp 1466167

• Panic if jujud restarts while action is running Lp 1447895

• Mysterious env.lock held message Lp 1454323

• Upgrade fails moving syslog config files "invalid argument" Lp 1468815

• Leadership settings documents written out without env-uuid field Lp 1468994

• Debug-log does not work with local provider Lp 1464335

• A subordinate charm hook scheduled to run(but waiting for the principal charm hook to release the lock) goes to an error state after the principal charm hook triggers a reboot. Lp 1464470

• Upgrading 1.20.14 -> 1.24.0 fails Lp 1466969

• Subordinate charm action data not reported by api Lp 1457205

• Centos fails to bootstrap using juju 1.24 Lp 1470150

A new stable release of Juju, juju-core 1.24.0, is now available. This release replaces version 1.23.3.

Getting Juju

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

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

Windows and OS X users will find installers at:

https://launchpad.net/juju-core/+milestone/1.24.0

Notable Changes

• VMWare (vSphere) Provider
• Resource Tagging (EC2, OpenStack)
• MAAS root-disk Constraint
• Service Status
• CentOS 7 Preview
• Storage (experimental)

VMWare (vSphere) Provider

Juju now supports VMWare's vSphere ("Software-Defined Data Center") installations as a targetable cloud. It uses the vSphere API to interact with the vCenter server. The vSphere provider uses the OVA images provided by Ubuntu's official repository. API authentication credentials, as well as other config options, must be added to your environments.yaml file before running 'juju bootstrap'. The different options are described below.

The basic config options in your environments.yaml will look like this:

my-vsphere:
  type: vsphere
  host: <192.168.1.10>
  user: <some-user>
  password: <some-password>
  datacenter: <datacenter-name>
  external-network: <external-network-name>

The values in angle brackets need to be replaced with your vSphere information. 'host' must contain the IP address or DNS name of vSphere API endpoint. 'user' and 'password' are fields that must contain your vSphere user credentials. 'datacenter' field must contain the name of your vSphere virtual datacenter. 'external-network' is an optional field. If set, it must contain name of the network that will be used to obtain public IP addresses for each virtual machine provisioned by juju. An IP pool must be configured in this network and all available public IP addresses must be added to this pool. For more information on IP pools, see official documentation:

https://pubs.vmware.com/vsphere-51/index.jsp?topic=2Fcom.vmware.vsphere.vm_admin.doc%2FGUID-5B3AF10D-8E4A-403C-B6D1-91D9171A3371.html

NOTE that using the vSphere provider requires an existing vSphere installation. Juju does not set up vSphere for you. The OVA images we use support VMWare's Hardware Version 8 (or newer). This should not be a problem for most vSphere installations.

Resource Tagging (EC2, OpenStack)

Juju now tags instances and volumes created by the EC2 and OpenStack providers with the Juju environment UUID. Juju also adds any user- specified tags set via the "resource-tags" environment setting. The format of this setting is a space-separated list of key=value pairs:

resource-tags: key1=value1 [key2=value2 ...]

These tags may be used, for example, to set up chargeback accounting. Any tags that Juju manages will be prefixed with "juju-"; users must avoid modifying these.

Instances and volumes are now named consistently across EC2 and OpenStack, using the scheme "juju---", where is the human-readable name of the environment as specified in environments.yaml; is the type of the resource ("machine" or "volume") and is the numeric ID of the Juju machine or volume corresponding to the IaaS resource.

MAAS root-disk Constraint

The MAAS provider now honours the root-disk constraint, if the targeted MAAS supports disk constraints. Support for disk constraints was added to MAAS 1.8.

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 charm. 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 above commands set the status of the individual units. Unit leaders may also set and get the status of the service to which they belong:

print the status of all units of the service and the service itself: status-get --service

set the status of the service: status-set --service "message"

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+06:00  workload  unknown      Waiting for agent initialization to finish
01 May 2015 17:33:20+06:00  agent     allocating
01 May 2015 17:36:37+06:00  agent     executing    running install hook
01 May 2015 17:36:37+06:00  workload  maintenance  installing charm software
01 May 2015 17:36:38+06:00  workload  maintenance  installing dependencies
01 May 2015 17:39:11+06:00  workload  maintenance  installing components
01 May 2015 17:39:18+06:00  agent     executing    running leader-elected hook
01 May 2015 17:39:18+06:00  agent     executing    running config-changed hook
01 May 2015 17:39:19+06:00  workload  maintenance  configuring nginx
01 May 2015 17:39:34+06:00  workload  maintenance  restarting services
01 May 2015 17:39:38+06:00  workload  blocked      Waiting for database
01 May 2015 17:39:39+06:00  agent     executing    running start hook
01 May 2015 17:39:44+06:00  agent     idle

CentOS 7 Preview

Juju 1.24.0 has initial CentOS support. This is experimental and has a number of known issues. However, most of the functionality of Juju should be there and ready to be used and tested. CentOS should be deployable on any cloud that supports cloud-init in it's CentOS images. It is possible to use CentOS as both a state machine (taking the limitations at the bottom into account) and as a normal machine.

Deploying a charm on CentOS is no different than deploying one on Ubuntu or Windows. The only thing that needs to change is the series which is "centos7". For example, from Launchpad:

juju deploy lp:~me/centos7/charm

or Locally:

juju deploy --repository=/home/user/charms local:centos7/charm

However there are no charms currently available for CentOS. The process or writing one should be no different from the Ubuntu charms besides keeping in mind the fact that one shouldn't use Ubuntu specific calls (such as apt).

There is a guide for setting up a MaaS environment using CentOS at

http://wiki.cloudbase.it/juju-centos

Note that Centos 7 agents are already in streams. There is no need install Go, compile, tar, and running juju metadata. You can sync the streams to a web server visible to your Juju environment.

mkdir local
juju sync-tools --local-dir local
cp -r local/tools <path/to/webserver>

Some of the known issues are:

• Containers are not yet supported

• There is a lack of mongo tools at the moment so any functionality depending on those is not available(for example backups)

• There is no way to currently specify a proxy or mirror for yum in the environment configuration. The values that you specific for apt packages will be used for yum packages as well. This limitation will be fixed as soon as possible.

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), and MAAS 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.

Storage (experimental) MAAS Provider Support

The MAAS provider now supports storage. Storage directives are used to select machines which have the requisite number and size of volumes available on the machine (usually physical volumes such as SSD or magnetic drives).

Storage pools may be created to select volumes with specified tags.

juju storage create pool maas-ssd maas tags=ssd

The above creates a pool called "maas-ssd" and when used, will select volumes tagged in MAAS with the "ssd" tag. Tags may be a comma separated list.

Then to deploy a charm:

juju deploy mycharm --storage data=maas-ssd,50G

The above deploys a charm to a MAAS machine with the data store mounted on a volume at least 50GiB in size with the tag "ssd".

It is also possible to specify the size of the root-disk using the root disk constraint. This works the same way as for the AWS provider

juju deploy mysql --constraints root-disk=50G

Storage directives and root disk constraints may be combined.

juju deploy mysql --constraints root-disk=50G --storage data=maas-ssd,500G

NOTE: the root disk support has only just landed in MAAS trunk. the Juju/MAAS storage support has been smoke tested using the NEC MAAS test lab. It needs much more extensive testing!

NOTE: when using MAAS which does not support storage, if MAAS storage is requested, an error is returned and the node is cleaned up.

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.

Storage (experimental) Unit Placement

It is now possible to deploy units with storage to existing machines. This applies when using storage that is dynamically created, such as EBS/Cinder volumes, loop devices, TMPFS, rootfs. It can't be used with machine volumes on MAAS, but can be used to deploy charms to an existing MAAS machine if a dynamic storage source is specified. eg.

juju deploy charm --to 2 --storage data=loop,2G

An Openstack deployment example:

juju deploy charm --to 2 --storage data=cinder,2G

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

• Broken db field ordering when upgrading to juju compiled with go 1.3+ Lp 1451674

• Log files are lost when agents are restarted under systemd Lp 1452113

• Worker/uniter: charm does not install properly if storage isn't provisioned before uniter starts Lp 1452207

• Jujud does not restart after upgrade-juju on systemd hosts Lp 1452511

• Maas provider chokes on unexpected device labels Lp 1452725

• Juju 1.23-beta4 introduces ssh key bug when used w/ dhx Lp 1444861

• Retry-provisioning launches instances for containers; cannot retry containers at all Lp 1428439

• Debug-hooks exit 1 , doesn't mark hook as failed Lp 1415176

• Default storage constraints are not quite correct Lp 1452535

• Maas: implement root-disk constraint Lp 1212689

• Juju upgrade-juju failed to configure mongodb replicasets Lp 1441913

• Provider/openstack: volumes are recorded with 0 size Lp 1450740

• Persist iptables rules / routes for addressable containers across host reboots Lp 1442012

• Deployer sometimes fails with a unit status not found error Lp 1451283

• Logs don't rotate Lp 1452285

• Collect-metric hook failure, metric batch uuid already exists Lp 1452487

• Juju machine service for windows creates incorrect tools symlinks Lp 1453280

• /var/spool/rsyslog grows without bound Lp 1453801

• Instancepoller compares wrong address list and always requests updated state addresses Lp 1454043

  • Agents see "too many open files" errors after many failed api attempts Lp 1420057

• Container destruction doesn't mark ip addresses as dead Lp 1441206

• Debug-hooks not working with manually provisioned machines Lp 1429790

• Joyent machines get stuck in provisioning Lp 1446264

• Cannot process charms: finding charm revision info: cannot get metadata from the charm store: verification failed: no macaroon cookies in request Lp 1453238

• Juju log spams error juju.worker.diskmanager lsblk.go:111 error checking if "sr0" is in use: open /dev/sr0: no medium found Lp 1454481

• Failed to retrieve the template to clone - 500 internal server error - error creating container juju-trusty-lxc-template - Lp 1454676

• 1.20.x client cannot communicate with 1.22.x env Lp 1454829

• Received disconnect from ...: 2: too many authentication failures for ubuntu Lp 1456315

  • Lxc network.mtu setting not set consistently across hosts Lp 1442257

• Transaction collection (txns) grows without bound Lp 1453785

• Firewaller gets an exception if a machine is not provisioned Lp 1454599

• Jujud leaking file handles Lp 1454697

• Destroying a machine with a placed unit errors then destroys anyway. Lp 1455158

• Intermittent panic: rescanned document Lp 1449054

• juju upgrade-juju --upload-tools leaves local environment unusable Lp 1457728

• warning: log line attempted over max size - leadership related Lp 1457645

• Debug-log eof: invalid tag and panic seen in state server logs Lp 1461354

• Juju has conf files in /var/log/juju on instances Lp 1370896

• Juju restore fails with "/var/lib/juju/agents: no such file or directory" Lp 1431372

• Cannot destroy-environment with 'juju user add' .jenv file Lp 1403165

• Juju cannot create vivid containers Lp 1442308

• State: availability zone upgrade fails if containers are present Lp 1441478

• 1.23.2.1, mongo: document is larger than capped size Lp 1454891

• "relation-set --file -" doesn't seem to work Lp 1454678

• Maas provider doesn't know about "failed deployment" instance status Lp 1376246

• Juju status --utc does not display utc and is confused Lp 1459611

• Juju agent opens api when upgrade is pending Lp 1459912

• 'juju status' wall clock timestamps should display offset not tz abbrev Lp 1459616

• Harvest mode setting not used by container provisioner Lp 1459885

• Allow status-set/get to a service by its leader unit Lp 1461111

• Unit storage add should only accept count as constraint Lp 1461342

• Golang.org/x/sys/windows requires go 1.4 Lp 1463439

• Erroneous juju user data on windows for juju version 1.23 Lp 1451626

• Cmd/juju/storage: "add" fails to dynamically add filesystem for storage Lp 1462146

• Worker/diskmanager sometimes goes into a restart loop due to failing to update state Lp 1461871

• Juju 1.24-beta6.1 unit commands in debug-hooks hang indefinitely Lp 1463117

A new stable stable release of Juju, juju-core 1.23.3, is now available. This release replaces version 1.23.2.

Getting Juju

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

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

Windows and OS X users will find installers at:

https://launchpad.net/juju-core/+milestone/1.23.3

Notable Changes

This releases addresses stability and performance issues.

Resolved issues

• Broken db field ordering when upgrading to juju compiled with go 1.3+ Lp 1451674

• Log files are lost when agents are restarted under systemd Lp 1452113

• Jujud does not restart after upgrade-juju on systemd hosts Lp 1452511

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

• Local charms are not added to storage on upgrade to 1.22.x Lp 1447853

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

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

• Juju 1.23-beta4 introduces ssh key bug when used w/ dhx Lp 1444861

• Debug-hooks exit 1 , doesn't mark hook as failed Lp 1415176

• Unnecessary errors emitted during init system discovery Lp 1452114

A new stable release of Juju, juju-core 1.23.2, is now available. This release replaces version 1.22.1.

Getting Juju

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

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

Windows and OS X users will find installers at:

https://launchpad.net/juju-core/+milestone/1.23.2

Notable Changes

• New Support for Google Compute Engine (GCE)
• Support for systemd (and Vivid)
• New Style Restore
• Improved Proxy Support for Restrictive Networks
• New Charm Actions
• New blocks and Messages.
• Experimental: Service Leader Elections
• Experimental: Addressable LXC Containers and KVM Instances on AWS and MAAS

New Support for Google Compute Engine (GCE)

A new provider has been added that supports hosting a Juju environment in GCE. This feature leverages the support for Ubuntu cloud-images that GCE added late 2014. It uses Google's GCE API to interact with your account there. API authentication credentials, as well as other config options, must be added to your environments.yaml file before running 'juju bootstrap'. The different options are described below.

The basic config options in your environments.yaml will look like this:

yaml my-gce: type: gce project-id: <your-project-id> auth-file: <path-to-json-file-from-google> private-key: <your-private-key> client-email: <your-client-email> client-id: <your-client-id>

The values in angle brackets need to be replaced with your GCE information.

'project-id' must identify a GCE project that already exists before you run "juju bootstrap". This means creating a new one through the developer console (https://console.developers.google.com/project) before bootstrapping Juju. To make it easier to quickly identify in your GCE console, we recommend that the name start with 'juju-' and that it include the environment name you are planning to use. You could also use an existing project but we recommend against that if possible. Using a new project will make it easier for you to manage the environment's resources as well as to track the environment's cost and resource usage.

'auth-file' is the path to a JSON file you get from your GCE console that contains all the authentication credentials it needs. After you have created your project, download the file by pressing the 'Generate new JSON key' button in the 'Service Account' section of

https://console.developers.google.com/project//apiui/credential

If necessary, instead of 'auth-file' you may set the 'private-key', 'client-email', and 'client-id' fields in your environments.yaml. They are your GCE OAuth credentials (matching those in the JSON file). You may need to change "\u003d" in the private key to "=".

Either way, these details are associated with the 'service account' of the GCE project you will use for your Juju environment. For each GCE project, a service account is set up automatically when you create the project. Juju uses that service account to connect to the GCE API and does so with the proper authentication scope.

For more information please refer to

https://developers.google.com/accounts/docs/OAuth2ServiceAccount#creatinganaccount

and

https://developers.google.com/accounts/docs/OAuth2#serviceaccount

If the project's service account has any permissions problems go to the following page to fix them:

https://console.developers.google.com/project//permissions

(remember to insert the project id)

The GCE API should already be activated for the project. It it isn't, go to the following URL in your console:

https://console.developers.google.com/project//apiui/api

(insert the project name)

Also see step 2 on

https://cloud.google.com/compute/docs/api/how-tos/authorization.

The following config options in your environments.yaml file are optional:

region - (default us-central1) The location to place the
       environment.
image-endpoint - (default https://www.googleapis.com) This is
       where Juju will look for disk images when provisioning a
       new instance on GCE.

All Juju 1.23 provider capabilities are available for GCE except for networking.

Support for systemd (and Vivid)

In addition to upstart, Juju now supports Ubuntu hosts using systemd as their init system.

Support for systemd allows Juju to run on Ubuntu 15.04 (Vivid Vervet), which is the first Ubuntu release to boot with systemd. This means you can bootstrap Juju on a Vivid host. Note that the charm store (jujucharms.com) only support LTS releases. You can develop and test vivid charms in a local charm repository.

New Style Restore

You can now restore a backup with the new 'backups restore' command, which is more reliable and fast. New restore supports backups generated with the deprecated Juju backup plugin and with the recently added 'juju backups create' command. You can restore from a local backup file like so:

bash juju backups restore [-b] --file <backup file>

Which will optionally bootstrap a new state server, upload a backup file and restore it. The -b option will fail if there is a running state server.

You can also restore from a backup stored on the state-server:

bash juju backups restore --id <on server backup id>

To obtain a list of the existing backups in the state-server you can use:

bash juju backups list

Improved Proxy Support for Restrictive Networks

A few of issues around HTTP/HTTPS and apt proxy support were fixed (Lp 1403225, Lp 1417617). Charm downloads from the charm store which could not be completed due to connectivity issues are now retried every few minutes rather than once every 24 hours. Proxy settings from the environment (http-proxy, https-proxy, ftp-proxy, apt-http-proxy, apt-https-proxy, apt-ftp-proxy, and no-proxy) are properly propagated to all machines, and Juju agents use them for all external connectivity. The juju run command also uses proxy settings when defined, as well as debug-hooks and all hooks the a charm runs. You can specify one or more proxy settings via environment variables (http_proxy, https_proxy, etc.) or inside your environments.yaml. Other related proxies are configured as needed (e.g. you can specify just http-proxy, and that will also be used for https, ftp, and apt proxies).

New Charm Actions

Juju charms can describe actions that users can take on deployed services. These actions are scripts that can be triggered on a unit by the via the Juju CLI (support for triggering actions from the Juju GUI will follow soon). Schemas for each action are defined in an actions.yaml file in the charm root, and conform to JSON-Schema. When an action is invoked, passed parameters are validated against the respective schema as explained in "Actions for the Charm author" at both the API and the unit level:

https://jujucharms.com/docs/1.20/authors-charm-actions

CLI Actions are sub-commands of the 'juju action' command. For more details on their usage, 'juju action help' has examples and further material.

The following subcommands are currently specified:

• defined - show actions defined for a service
• do - queue an action for execution
• fetch - show results of an action by ID
• status - show results of actions filtered by optional ID prefix

New Blocks and Messages

You can now specify block message when you enable a block. For example, you can add a message to 'destroy-environment':

bash juju block destroy-environment "Don't destroy this environment" juju destroy-environment ERROR Don't destroy this environment

You can list the blocks enabled in the environment like so:

no-highlight juju block list destroy-environment=on, Don't destroy this environment remove-object=off all-changes=off

The Multiwatcher now has information about blocks. There is now block client capable of switching blocks on/off as well as listing all enabled blocks.

Experimental: Service Leader Elections

Services can now coordinate leadership among the deployed units using Juju's service leader election support.

Charms now have access to three new hook tools:

no-highlight is-leader - returns true only if the executing unit is guaranteed service leadership for the next 30s leader-get - as relation-get; accessible only within the service leader-set - as relation-set; will fail if not executed on leader

...and two new hooks:

no-highlight leader-elected - runs when the unit takes service leadership leader-settings-changed - runs when another unit runs leader-set

When a unit starts up, it will always run either leader-elected or leader-settings-changed as soon as possible, delaying only doing so only to run the install hook; complete any queued or in-flight operation; or resolve a hook or upgrade error.

Known limitations:

• Amazon limits the number of addresses the containers an instance can have based on its size.
• Statically allocated addresses are not released on container shutdown.
• Container addressability does not survive a host reboot.
• No public IP address is added on AWS, and we don’t yet support dynamic port mapping -- so you can not yet expose containerized services on Amazon.

Resolved issues

• Allow annotations to be set on charms Lp 1313016

• Juju-backup is not a valid plugin Lp 1389326

• Juju needs to support systemd for >= vivid Lp 1409639

• Joyent provider uploads user's private ssh key by default Lp 1415671

• Unable to bootstrap on cn-north-1 Lp 1415693

• Debug messages show when only info was asked for Lp 1421237

• Juju default logging leaks credentials Lp 1423272

• Juju resolve doesn't recognize error state Lp 1424069

• Juju status --format=tabular Lp 1424590

• Ec2 provider unaware of c3 types in sa-east-1 Lp 1427840

• Ec2 eu-central-1 region not in provider Lp 1428117

• Ec2 provider does not include c4 instance family Lp 1428119

• Allwatcher does not remove last closed port for a unit, last removed service config Lp 1428430

• Make kvm containers addressable (esp. on maas) Lp 1431130

• Fix container addressability issues with cloud-init, precise, when lxc-clone is true Lp 1431134

• Dhcp's "option interface-mtu 9000" is being ignored on bridge interface br0 Lp 1403955

• Juju-1.23beta3 breaks glance <-> mysql relation when glance is hosted in a container Lp 1441811

• Juju ensure-availability should be able to target existing machines Lp 1394755

• Juju 1.23b4 vivid panic: runtime error: invalid memory address or nil pointer dereference Lp 1443541

• 1.23-beta4 sporadically fails autotests Lp 1443440

• 1.23.1: bootstrap failure, vivid, local provider Lp 1447446

• Hooks don't fire after upgrade 1.23.0 Lp 1447846

A new supported release of Juju, juju-core 1.22.8, is now available. This release replaces version 1.22.6.

Getting Juju

juju-core 1.22.8 is available for Wily and backported to earlier series in the following PPA:

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

Windows and OS X users will find installers at:

https://launchpad.net/juju-core/+milestone/1.22.8

Notable Changes

This releases addresses stability and performance issues.

Resolved issues

• Juju uses proxy to access bootstrap node Lp 1478660

• Juju environment not usable after the upgrade Lp 1473517

A new supported release of Juju, juju-core 1.22.6, is now available. This release replaces version 1.22.5.

Juju 1.22.x is an older supported version of Juju. The current Juju version is 1.24.0.

Getting Juju

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

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

Windows and OS X users will find installers at:

https://launchpad.net/juju-core/+milestone/1.22.6

Notable Changes

This releases addresses stability and performance issues.

Resolved issues

• State: availability zone upgrade fails if containers are present Lp 1441478

• LXC provisioning fails on joyent Lp 1461150

• Worker/diskmanager sometimes goes into a restart loop due to failing to update state Lp 1461871

• Package github.com/juju/txn has conflicting licences Lp 1463455

A new stable release of Juju, juju-core 1.22.5, is now available. This release replaces version 1.22.1.

Juju 1.22.x is an older supported version of juju. The current Juju version is 1.23.3

Getting Juju

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

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

Windows and OS X users will find installers at:

https://launchpad.net/juju-core/+milestone/1.22.5

Notable Changes

This releases addresses stability and performance issues.

Resolved issues

• Transaction collection (txns) grows without bound Lp 1453785

• /var/spool/rsyslog grows without bound Lp 1453801

• Instancepoller compares wrong address list and always requests updated state addresses Lp 1454043

• Firewaller gets an exception if a machine is not provisioned Lp 1454599

• Jujud leaking file handles Lp 1454697

• Agents see "too many open files" errors after many failed api attempts Lp 1420057

• 1.20.x client cannot communicate with 1.22.x env Lp 1454829

• Intermittent panic: rescanned document Lp 1449054

• Harvest mode setting not used by container provisioner Lp 1459885

A new stable release of Juju, juju-core 1.22.1, is now available. This release replaces 1.22.0.

Getting Juju

juju-core 1.22.1 is available for utopic and backported to earlier series in the following PPA:

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

Notable Changes

This releases addresses stability and performance issues.

Vivid local-provider limitations

Juju 1.22.x on Vivid is suitable for creating and maintaining Juju environments in public and private clouds, including MAAS. Local-provider support for Vivid's default systemd installation will land in 1.23. To use Juju 1.22 on Vivid for local testing and charm development you must take some additional steps.

You can switch back to upstart, as explained at:

https://wiki.ubuntu.com/SystemdForUpstartUsers

Alternatively you can run Ubuntu Trusty inside a KVM or Docker running on your localhost. Many charm authors prefer to use Vagrant for development to separate the Juju from their localhost. We provide Juju Vagrant boxes:

https://jujucharms.com/docs/stable/config-vagrant

The Juju (1.23.x) will support systemd on Vivid. You can test and develop using the local-provider. 1.23.x will first be available via the official stable PPA:

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

And will appear in the release shortly thereafter.

Resolved issues

• Juju cannot deploy when distro-info-data gets a new series Lp 1427879

• Juju backup fails when journal files are present Lp 1423936

• Copyright information is not available for some files Lp 1435974

• Juju restore failed with "error: cannot update machines: machine update failed: ssh command failed:" Lp 1434437

• Unit test failure: testnewdefaultserver.n40_github_com_juju_juju_cert_test.certsuite Lp 1437040

• Certsuite.testnewdefaultserver failure Lp 1435860

• Apt-http-proxy being reset to bridge address Lp 1437296

A new stable release of Juju, juju-core 1.22.0, is now available. This release replaces 1.21.3.

Getting Juju

juju-core 1.22.0 is available for utopic and backported to earlier series in the following PPA:

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

Windows and OS X users will find installers at:

https://launchpad.net/juju-core/+milestone/1.22.0

Notable Changes

• Blocking changes to the environment
• LXC image caching and the cached-images command
• Juju state backup improvements
• Static internal route for Joyent instances
• The instance availability zone is exposed to charms
• Relaxed checked for container scoped relations
• Windows workloads preview
• New annotations client includes charms and bulk calls
• Upgrade robustness
• Multi-environment infrastructure

Blocking changes to the environment

The 'block' and 'unblock' commands control which changes can be made to a running environment. Use the 'block' command to lockdown the environment to prevent accidental changes. Three levels of restrictions can be applied, 'destroy-environment', 'remove-object', and 'all-changes'.

The 'destroy-environment' level blocks just the 'destroy-environment' command. You can prevent an environment from being destroyed like this:

bash juju block destroy-environment

The 'remove-object' level blocks the 'destroy-environment', 'remove-machine', 'remove-relation', 'remove-service', and 'remove-unit' commands from being run. You can prevent the machines, services, units and relations from being removed thusly:

bash juju block remove-object

The 'all-changes' level blocks commands that add, alter, or remove things in the running environment. These commands are blocked: 'add-machine', 'add-relation', 'add-unit', 'authorised-keys add', 'authorised-keys delete', 'authorised-keys import', 'deploy', 'destroy-environment', 'ensure-availability', 'expose', 'resolved', 'remove-machine', 'remove-relation', 'remove-service', 'remove-unit', 'retry-provisioning', 'run', 'set', 'set-constraints', 'set-env', 'unexpose', 'unset', 'unset-env', 'upgrade-charm', 'upgrade-juju', 'user add', 'user change-password', 'user disable', and 'user enable' You can lockdown the environment to prevent all changes like this:

bash juju block all-changes

When a command is blocked, and you are certain you need to alter the environment, you can remove the block using the 'unblock' command. For example, to permit the remove-relation command blocked by the 'remove-object' level, run:

bash juju unblock remove-object

You can restore the block after you complete your changes.

Note that some commands have a '--force' option bypasses the restrictions set by 'block'. Only use the '--force' option after the command was run without it to ensure you are aware of the restrictions set on the environment by the 'block' command.

For more information run 'juju help block' and 'juju help unblock'.

LXC image caching and the cached-images command

From Juju 1.22 onwards, LXC images are cached in the Juju environment when they are retrieved to instantiate a new LXC container. This applies to the local provider and all other cloud providers. This caching is done independently of whether image cloning is enabled.

Note: Due to current upgrade limitations, image caching is currently not available for machines upgraded to 1.22. Only machines deployed with 1.22 will cache the images.

In Juju 1.22, lxc-create is configured to fetch images from the Juju state server. If no image is available, the state server will fetch the image from http://cloud-images.ubuntu.com and then cache it. This means that the retrieval of images from the external site is only done once per environment, not once per new machine which is the default behaviour of lxc. The next time lxc-create needs to fetch an image, it comes directly from the Juju environment cache.

The 'cached-images' command can list and delete cached LXC images stored in the Juju environment. The 'list' and 'delete' subcommands support '--arch' and '--series' options to filter the result.

To see all cached images, run:

bash juju cached-images list

Or to see just the amd64 trusty images run:

bash juju cached-images list --series trusty --arch amd64

To delete the amd64 trusty cached images run:

bash juju cache-images delete --series trusty --arch amd64

Future development work will allow Juju to automatically download new LXC images when they becomes available, but for now, the only way update a cached image is to remove the old one from the Juju environment. Juju will also support KVM image caching in the future.

See 'juju cached-images list --help' and 'juju cached-images delete --help' for more details.

Juju state backup improvements

The backup CLI plugin is replaced by the native 'backups' command. The command can create, manage, and restore state backups. The new backup features are also available using the API endpoints too.

You can create a backup like this:

bash juju backups create

Backups are kept on the state-server by default, but you can use the 'download' and 'upload' subcommands to move backups between locations.

bash juju backups download <id> juju backups upload <filename>

You can list the backups and see info about a specific backup using these subcommands:

bash juju backups list juju backups info <id>

You can remove unwanted backups like this:

bash juju backups remove <id>

The juju 'restore' command is unchanged. You can learn more about backups by reading the details of 'juju help backups'.

The instance availability zone is exposed to charms

Charms can query the 'JUJU_AVAILABILITY_ZONE' environmental variable to learn the instance's availability zone. Not all clouds/providers support availability zones, but this information is available when the charm is deployed in EC2 and HP Cloud for example.

Relaxed checked for container scoped relations

Container scoped relations are now allowed as long a there is at least one subordinate service involved. Previously there had to be exactly one subordinate service in the relation.

Static internal route for Joyent instances

When running in Joyent, Juju creates a static route to ensure that it is always possible for instance to communicate over the internal network interface.

Windows workloads preview

Juju 1.22.0 has initial Windows workload support. This is BETA, and will be improved in the following releases.

Deploying Windows charms is just the same as it is for Ubuntu:

bash juju deploy lp:~me/win2012r2/my-charm

or from a local repository

bash juju deploy --repository=/home/me/charms local:win2012r2/my-charm

A Juju charm boilerplate is available:

https://github.com/cloudbase/windows-charms-boilerplate

Powershell is the language of choice when writing Juju charms for Windows, as it is tightly coupled to Windows automation. You may use any language you see fit.

There are a few notable differences between charms running on Ubuntu and charms running on Windows:

• All charm hooks must have one of the following extensions: .ps1, .cmd, .bat, .exe. The extensions will be searched in order, with powershell being default.
• All juju files/charms are located in: C:\juju . The folder structure should be the same as on ubuntu, with C:\juju as the root.
• Cloudbase-init installs a local copy of python 2.7 (soon to switch to 3.X). If you wish, you can write python code to deploy your applications, but keep in mind you would have to wrap the execution of your script with one of the supported filetypes (.ps1, .cmd, .bat, .exe).
• If the machine reboots, Juju machine agents and unit agents will have a delayed start. This means that Juju services will start 2 minutes after the last Windows service is started. So if the Juju services are listed as "Stopped" immediately after reboot, don't panic.
• All Juju services (and therefor charms) will run under an administrator account called: jujud. This will allow charms to use installers that require a real user, and not just the "system" user.

Juju requires Windows images with cloudbase-init to deploy Juju services. For public clouds which run KVM/Hyper-V and have one of the supported metadata services in cloudbase-init, there is a downloadable:

http://www.cloudbase.it/ws2012r2/

You need to upload custom images. So roughly, the steps would be:

1. Download image from http://www.cloudbase.it/ws2012r2/
2. Add it to your cloud provider
3. Generate necessary metadata using juju-metadata generate-image -s win2012r2 -i
4. Make the generated files available. A simple webserver or simply uploading the files to the provider's object storage should do. As long as they are accessible to the newly booted up instances.
5. Change agent-metadata-url in environments.yaml to point to the "tools" directory that 'generate-image' created.
6. Bootstrap your environment

If you want to use other Windows version in your cloud, or if you need image formats other then vhdx or qcow2, you can generate your own image using the following tools:

https://github.com/cloudbase/windows-openstack-imaging-tools

Current Windows limitations:

• Windows cannot be used as a bootstrap machine for the state-server. Only machine agents are supported.
• 'juju ssh' currently does not work with Windows. The implementation is tightly coupled with *nix systems, and having OpenSSH deployed on Windows machines might later become a security risk due to the fact that it is not part of normal Windows update systems. Work is being done to integrate WinRM support into Juju. This will allow us to offer the same level of integration using powershell remoting (http://msdn.microsoft.com/en-us/library/dd357801.aspx)
• Manual provider is not supported. Manual provider requires SSH to deploy. See above mention.
• Local provider is not supported. Local provider relies on LXC or KVM and it deploys a state-server to the host, which is not supported on Windows.
• Debug hooks are not yet supported yet. The current implementation requires SSH and tmux to work, which is very platform specific. This will be implemented for Windows soon.

New annotations client includes charms and bulk calls

The new api.annotations.client supports annotating charms, the environment, machines, services, and units. It supports bulk calls. The old api.client annotation functions are deprecated.

The SET annotations call takes this form:

json { "Type": "Annotations", "Request": "Set", "Params": { "Annotations": { { "EntityTag": a, "Annotations": pairs1 },{ "EntityTag": b, "Annotations": pairs2 } } }

The corresponding GET annotations call takes this form:

json { "Type": "Annotations", "Request": "Get", "Params": { "Entities": { {Entity {"Tag": a}}, {Entity {"Tag": b}, } } }

The GET response looks like this:

json { "Results": { {"EntityTag": a, "Annotations": pairs1, "Error": nil}, {"EntityTag": b, "Annotations": pairs2, "Error": nil}, } }

Juju upgrade robustness

During Juju upgrades (the 'upgrade-juju' command), steps specific to Juju state-servers are now run before other upgrade steps. Database migrations on the state-server are completed before machine updates and updates of the Juju agents on deployed units.

Multi-environment infrastructure

Juju will soon be able to support multiple environments managed by a single state server (or state server cluster). Although this is not yet visible, version 1.22 includes much of the infrastructure changes for multi-environment support.

Resolved issues

• Interface mtu management across maas/juju Lp 1355813

• State server certificate has empty san list Lp 1397909

• Api server restarts soon after state server comes up Lp 1403721

• Cmdline: implement juju environment jenv Lp 1409784

• Juju should wait until a node's status is 'deployed' to attempt ssh'ing into it Lp 1394680

• Lock contention running apt in bootstrap Lp 1384259

• Juju status --format summary panics with unresolvable ips Lp 1410320

• Machine hasvote/wantsvote should be included in allwatcher deltas Lp 1402965

• Open-stack provider breaks swift with standard config Lp 1312217

• 'juju switch' should not require an entry in environments.yaml Lp 1334768

• Provider/maas: stopinstances may fail if nodes are removed out of band Lp 1319016

• Unit "(anycharm)" is not assigned to a machine when deploying with juju 1.22-beta5 Lp 1430049

A new stable release of Juju, juju-core 1.21.3, is released. This release may replaces 1.21.1.

Getting Juju

juju-core 1.21.3 is available for utopic and backported to earlier series in the following PPA:

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

Windows and OS X users will find installers at:

https://launchpad.net/juju-core/+milestone/1.21.3

Notable Changes

This releases addresses stability and performance issues.

Resolved issues

• Unable to override network-bridge if container type is kvm (local provider) Lp 1416134

• Src/bitbucket.org/kardianos/osext/license is wrong Lp 1416425

• Github.com/juju/syslog has contradicting licensing info Lp 1416433

• Some files refer to an include license file that is not included Lp 1416430

• Github.com/juju/utils has contradictory licence info Lp 1416436

• Juju restore no longer works with azure: error: cannot re-bootstrap environment: cannot determine state server instances: environment is not bootstrapped Lp 1417178

• Unit ports not populated by api megawatcher Lp 1418433

• Apt-proxy can be incorrectly set when the fallback from http-proxy is used Lp 1417617

• Juju agent using lxcbr0 address as apiaddress instead of juju-br0 breaks agents Lp 1416928

• Juju-quickstart: bad api server response: 'nonetype' object is not iterable Lp 1420403

• Error juju.worker runner.go:219 exited "rsyslog": x509: certificate signed by unknown authority Lp 1417875

• Juju references old dns-name and ip addresses after restore. (failed juju ssh) Lp 1420316

• Ensure-availability fails with 'failed to find any voting machines' after backup/restore. Lp 1420306

A new stable release of Juju, juju-core 1.21.1, is now available. This release replaces 1.20.14.

Getting Juju

juju-core 1.21.1 is available for utopic and backported to earlier series in the following PPA:

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

Windows and OS X users will find installers at:

https://launchpad.net/juju-core/+milestone/1.21.1

Notable Changes

• Selecting provisioner harvest modes
• Using apt mirrors
• Configuring OS update and upgrade for faster provisioning
• Using daily image streams for faster provisioning
• Selecting the agent stream to get alternate version of Juju
• Tuning Juju to take advantage of NUMA
• Configuring the MAAS network rules
• Improved availability zone selection in OpenStack and MAAS
• Juju now prefers SSD storage in AWS
• Adding many machines
• Choosing the nodes used to ensure high availability
• Inspecting the API connection settings
• Managing who can connect to the Juju environment
• Upgrade robustness
• Rebooting units from charm hooks
• Improvements to ports management for charms
• Developing Juju providers for clouds without storage
• More mirrors for faster bootstraps

Selecting provisioner harvest modes

Juju keeps a model of what it thinks the environment looks like, and based on that model, can harvest machines which it deems are no longer required. This can help keep your costs low, and keep you out of web consoles. Juju supports several harvesting modes to suit your needs.

Destroyed: Juju will harvest only machine instances that are marked as dead, and that Juju knows about. Running instances unknown to Juju will not be harvested. This is the default mode.

Unknown: Juju will harvest only instances that Juju does not know about.

All: Juju will terminate all instances – destroyed or unknown – that it finds. This is a good option if you are only utilizing Juju for your environment.

None: Juju won't harvest any machines. This is the most conservative mode, and a good choice if you manage your machines utilizing a separate process outside of Juju.

Juju's harvesting behaviour is set through the environments.yaml file.

yaml provisioner-harvest-mode: <MODE>

provisioner-harvest-mode replaces safe-mode. Environments with safe-mode set will be converted to provisioner-harvest-mode when upgraded.

Using apt mirrors

You can now configure apt-mirror in environments.yaml to specify the mirror used by all the machines provisioned in the environment:

apt-mirror: http://my.archive.ubuntu.com

On precise, the cloud tools archive is now pinned before calling apt upgrade to ensure its packages are a lower priority than the default precise archives. Charms developed on precise will see the same packages when deployed into a Juju provisioned machine. If your precise charm requires packages from the cloud tool's archive, you can use the target-release option to specify the archive to select:

bash apt-get --target-release precise-updates/cloud-tools my-package

Configuring OS update and upgrade for faster provisioning

When Juju provisions a machine, its default behaviour is to update the list of available packages and upgrade the existing packages to the latest version. If your OS images are fresh or the services you deploy do not require updated packages, you can disable updates and upgrades to provision the machine faster.

Two configuration options are available to disable apt updates and upgrades. When your OS images are fresh, you can set both enable-os-refresh-update, and enable-os-upgrade to false. When you know that some charms want the latest packages to set up services, you will want to keep enable-os-refresh-update set to "true".

You can configure the options in environments.yaml for fast provisioning like so:

yaml enable-os-upgrade: false enable-os-refresh-update: false The local provider skips apt upgrades by default for faster provisioning. If you wish to enable upgrades in your local development, set enable-os-upgrade to "true" in your environments.yaml:

yaml enable-os-upgrade: true

If you are using the local-provider to develop charms or test, you will want to regularly purge the Juju template and LXC caches to be certain you are using fresh images. For example, before you start testing a new trusty charm, you can remove the template and cloud image like this:

bash sudo lxc-destroy -n juju-trusty-lxc-template sudo rm -r /var/cache/lxc/cloud-trusty

Using daily image streams for faster provisioning

Juju prefers to use the slow-changing "released" images when provisioning machines. The image-stream option in environments.yaml can be set to "daily" use more up-to-date images, thus shortening the time it takes to perform apt-get update/upgrade. While this feature has existed since 1.18.0, it was not applied consistently to KVM containers. KVM containers will now use "daily" when environments.yaml is set to:

yaml image-stream: daily

Selecting the agent stream to get alternate version of Juju

The agent-stream config option selects the versions of Juju that an environment can deploy and upgrade to. The default behaviour of Juju is to select agents from the "released" stream. These are the most stable versions of Juju. You can set agent-stream to select "devel" streams now to test the unstable versions of Juju:

yaml agent-stream: devel

You can evaluate the next stable version of Juju before it is the default version by selecting the "proposed" stream like this:

yaml agent-stream: proposed

The tools-metadata-url was renamed to agent-metadata-url and it does not need to be set to get "devel" or "proposed". You can remove it from environments.yaml if you have set it. agent-metadata-url is only needed to select a private stream.

If you have an existing test environment using tools-metadata-url or agent-metadata-url to test proposed versions, you can still upgrade to 1.21.0. After you upgrade, you can update the environment to use the devel streams at the default stream location:

bash juju unset-env agent-metadata-url juju set-env agent-stream=proposed

Subsequent upgrades will "just work".

Tuning Juju to take advantage of NUMA

Juju can be tuned to take advantage of NUMA machines. If your state-server will be on a machine with NUMA support, you can set set-numa-control-policy to true in environments.yaml like this:

yaml set-numa-control-policy: true

The default value is false.

Configuring the MAAS network rules

Juju and MAAS cannot both be in control of the network. When MAAS is managing the bridge and bringing networks up and down, set the disable-network-management option in environments.yaml to "true":

yaml disable-network-management: true

This tells Juju not to create a network bridge or to bring eth0 up and down during cloud-init. Juju will not make changes to the network config when its agents start.

Improved availability zone selection in OpenStack and MAAS

The OpenStack and MAAS providers now attempt to start instances in all available zones until they find one which succeeds, rather than trying just the first zone and failing. This aligns OpenStack and MAAS behaviour with that of AWS.

Juju now prefers SSD storage in AWS

When deploying workloads onto AWS, images with SSD volumes are now preferred. If no such images are available, an image using EBS storage will be used as a fallback.

Adding many machines

Juju's add-machine command now accepts the "-n" option to add many machines. For example, to add two machines:

bash juju add-machine -n 2

The "-n" option can be combined with placement. You can add two LXC containers to machine 1 thusly:

bash juju add-machine lxc:1 -n 2

Choosing the nodes used to ensure high availability

Just as juju bootstrap supports the ability to specify a particular node using "--to" placement directives, so too can juju ensure-availability specify a comma separated list of machines to use for any newly required state servers. For example:

bash juju ensure-availability -n 3 --to name1,name2

Inspecting the API connection settings

The juju api-info command shows the settings used to connect to the Juju state-server's API. You can see the settings for all the fields (except for password) like so:

bash juju api-info

If you want to see the password being used, you need to either use the "--password" option:

bash juju api-info --password

or specify the password field as the only field to show:

bash juju api-info password

You can learn the value of any field by including it in the command line. For example, to learn the name of user created during bootstrap, type:

bash juju api-info user

Managing who can connect to the Juju environment

Juju now supports multiple people connecting to the environment with their own identity and credentials.

When an environment is bootstrapped the "admin" user is created (this will change with 1.22 to reflect the name of the logged in user).

Even though there is support for multiple users, there is not yet support for fine grain permissions. These will come in time. The only permission checked at this stage is that only the "admin" user can create or disable other users. Any user is now able to change their own password.

The user commands are grouped under the juju user command:

bash juju user usage: juju user <command> ... purpose: manage user accounts and access control

"juju user" is used to manage the user accounts and access control
in the Juju environment.

commands:
    add - adds a user
    change-password - changes the password of the current user
    disable - disable a user to stop the user logging in
    enable - reenables a disabled user to allow the user
                      to log in
    help - show help on a command or other topic
    info - shows information on a user
    list - shows all users

You can add a user like this:

bash juju user add test "Test User"

To generate a random strong password, use the --generate option.

bash password: type password again: user "Test User (test)" added environment file written to /home/tim/some-dir/test.jenv

The generated environment file still needs to be copied into the user's $JUJU_HOME/environments directory in order to be used. Future versions of Juju will make this more simple. The name of the environments file is the name that the user needs to use to talk to the environment, so the user will probably want to rename it too. For example, an environment named app-stack will have an env named:

no-highlight $JUJU_HOME/environments/app-stack.jenv

Juju will ask for a password to be typed in. If you'd prefer a strong random password, you can use the "--generate" option. You can also control the location and name of the environments file that is created.

You can see which users have been created using the juju user list command:

bash juju user list NAME DISPLAY NAME DATE CREATED LAST CONNECTION admin admin 23 minutes ago just now test Test User 5 minutes ago never connected thumper Tim 5 seconds ago never connected

The output of this command can also be in YAML or JSON using the usual "--format" options.

Any user that is created will be able to access the environment. To stop this, you can disable the user.

```bash juju user disable test User "test" disabled

juju api-info user -e local-test test

juju user info -e local-test WARNING discarding API open error: environment "local-test" not found ERROR invalid entity name or password ```

Unfortunately the warning there is due to legacy environment support that is checked as a fallback when the initial connection failed due to the user being disabled.

Disabled users are not shown by default with the listing:

bash juju user list NAME DISPLAY NAME DATE CREATED LAST CONNECTION admin admin 30 minutes ago just now thumper Tim 6 minutes ago never connected

But they can be included with the '--all' option:

bash juju user list --all NAME DISPLAY NAME DATE CREATED LAST CONNECTION admin admin 32 minutes ago just now test Test User 13 minutes ago 2 minutes ago (disabled) thumper Tim 8 minutes ago never connected

Disabled users can be enabled again using the enable command:

```bash juju user enable test User "test" enabled

juju user info -e local-test user-name: test display-name: Test User date-created: 14 minutes ago last-connection: just now ```

Upgrade robustness

Many improvements have been made to make Juju software upgrades more reliable.

The upgrade process is now synchronised which is especially important in HA environments where multiple state servers exist. The master Juju state server now upgrades first, then the other state servers, followed by the remaining machines. If one or more state servers fail to start the upgrade process within a certain time, the upgrade is aborted and a rollback to the previous tools version occurs.

Upgrade progress is now shown in the Juju status output. A machine will now report when it is upgrading and both transient and permanent upgrade errors will also be indicated.

If a machine has trouble with the steps it needs to run to complete an upgrade, it will now retry several times. This helps to deal with some transient failures.

Rebooting units from charm hooks

There are several cases where a charm needs to reboot a machine, such as after a kernel upgrade, or to upgrade the entire system. The charm may not be able to complete the hook until the machine is rebooted.

The juju-reboot command allows charm authors schedule a reboot from inside a charm hook. The reboot will only happen if the hook completes without error. You can schedule a reboot like so:

bash juju-reboot

The --now option can be passed to block hook execution. The juju-reboot command will hang until the unit agent stops the hook and re-queues it for next run. This will allow you to create multi-step install hooks.

Charm authors must wrap calls to juju-reboot to ensure it is actually necessary, otherwise the charm risks entering a reboot loop. The preferred work-flow is to check if the feature/charm is in the desired state, and reboot when needed. This bash example assumes that "$FEATURE_IS_INSTALLED" variable was defined by a check for the feature, then 'juju-reboot' is called if the variable is false:

bash if [[ $FEATURE_IS_INSTALLED == "false" ]] then install_feature juju-reboot --now fi

The juju-reboot command can be called from any hook. It can also be called using the juju run command.

Improvements to ports management for charms

Your charm hooks can call the new opened-ports shell command to get a listing of the open ports on the unit.

bash opened-ports

The open-port and close-port commands both support single ports and ranges, for example, to open ports 80 through 100 on tcp:

bash open-port 80-100/tcp

And you can close a range like so:

bash close-port 90-100/tcp

Juju now keeps track of what ports are opened by other units on the same machine and does not allow conflicting ports to be opened. The open-port and close-port commands can return a conflict error when the port was opened or closed by another charm. Additionally, both these commands work transactionally, in common with other hook commands; until the hook is committed no actual changes are made (opening or closing ports).

Developing Juju providers for clouds without storage

Storage associated with a particular cloud (S3 for AWS, Swift for Openstack etc) was a mandatory requirement when developing a provider to allow Juju to deploy workloads to any particular cloud platform. This requirement is no longer necessary. Although existing providers still use cloud storage (to some extent), new providers can be written without needing to provide a storage implementation.

More mirrors for faster bootstraps

Juju agents are mirrored in the certified public clouds (AWS, Azure, HP Cloud, and Joyent) to make bootstraps fast. You do not need to do anything to use them, they just work when we add and update them.

We added mirrors to Joyent. We registered the new regions recently added to AWS, Azure, and HP Cloud.

Resolved issues

• We should remove direct db access for clients Lp 1253652

• Allow specifying a key when doing manual provisioning Lp 1270466

• Juju doesn't use maas' knowledge of system architecture when picking tools Lp 1303853

• Local provider is very slow to transition from agent-status: pending Lp 1322302

• Juju should wrap apt-get invocations with eatmydata when provisioning cloud instances Lp 1335822

• Cloudinit does not use ssh client Lp 1339976

• Provisioner-safe-mode is undocumented Lp 1342729

• Networker restarts every 3 seconds with the local provider (missing /etc/network/interfaces) Lp 1343219

• Describe harvesting strategy rather than using "safe mode" name Lp 1345553

• Configstore: if the size of the serialised jenv decreases the .jenv file will be corrupt Lp 1348458

• Juju ignores environments.yaml on failed bootstrap if $provider.jenv exists Lp 1361680

• Saved addresses should omit link-local addresses Lp 1362453

• Blobstore's hashing needs improvement Lp 1364750

• Removing a unit on an unclean machine should remove that machine Lp 1206532

• Juju log files should not be world readable Lp 1286518

• Juju uses hard-coded regions Lp 1319474

• Cmd/juju: deploy --to a non existent machine fails too late in the process Lp 1212538

• Cmd/juju: add-machine should take a -n param Lp 1214209

• Container provisioner may choose bad tools Lp 1347984

• Juju set help is written but not shown Lp 1359187

• Status panics if environment not running Lp 1372264

• Rsyslog worker continuously restarts due to x509 error following upgrade Lp 1375507

• Allow open-port to expose several ports Lp 1216644

• Failed add-machine ssh: leaves behind garbage in state Lp 1356886

• Azure fails with juju bootstrap --upload-tools --upload-series Lp 1357511

• Support maas zones for automatic az placement Lp 1360605

• Juju should support an apt alternate mirror for private clouds Lp 1364200

• "juju ssh" doesn't work during tools upgrade Lp 1367009

• Bootstrap failed: unexpected error type *errors.errorstring Lp 1367896

• Ensure-availability command doesn't support placement directives Lp 1370332

• Api logins fail with "invalid entity name or password" before db migrations have run Lp 1372752

• Juju needs to support the maas api's not_tags constraint Lp 1373385

• Error message when trying to deploy to node 0 on lxc needs to be more user friendly Lp 1378792

• Use ssd image types on amazon ec2 Lp 1381009

• Configuration item tools-stream deprecated in favour of agent-stream Lp 1383070

• Azure bootstrap fails when 'location' and 'storage-account-name' are not in the same region Lp 1236136

• Juju run doesn't work with subordinate units Lp 1286613

• Need to reset user passwords (+ui) Lp 1288750

• Bootstrap without a jenv destroys an existing environment Lp 1336843

• Juju doesn't retry hard enough when destroying maas environments Lp 1384001

• Bad apt proxy config file in deployed nodes Lp 1309207

• Juju deploy hangs for a long time and then fails Lp 1386405

• Cmd/juju: add help on placement directives (zones, maas host name) Lp 1387421

• Juju scp help text is unclear on how to pass additional arguments Lp 1387640

• Juju set-env/get-env work with arbitrary strings Lp 1304126

• Cannot set user for juju scp Lp 1387766

• Status --errors only to show only things with errors Lp 1309260

• Provider/azure: boilerplate uses <> inconsistently around values that require replacing Lp 1381289

• Juju set should give feedback that the value is already set Lp 1384622

• Logs are not logrotated Lp 1078213

• Juju db should use numactl when running mongo on multi-socket nodes Lp 1350337

• Juju status panic if state conn is shutdown || closing. Lp 1361316

• Container failed to start with lxc-clone-aufs=true Lp 1364939

• No defined 'state-servers' on environment file after bootstrap, works after run 'juju status' Lp 1370149

• Juju add-unit --to fails too late, leaving unit unassigned Lp 1384732

• Ec2 says agent-state-info: 'cannot run instances: no default subnet for availability zone: ''us-east-1e''. (invalidinput)' Lp 1388860

• Provider/ec2: try alternative az on insufficientinstancecapacity error Lp 1389037

• Provider should test and verify credentials as first operation before bootstrap Lp 1362072

• Non subordinate container scoped relations broken Lp 1382751

• --debug dumps sensitive information to terminal Lp 1289038

• Juju destroy-environment could fail on MaaS with disk erasing enabled, or manually released nodes Lp 1381619

• Unit-get public-address on ec2 returns split horizon dns Lp 1308374

• Juju tries to use lxcbr0 when local provider is configured with kvm containers Lp 1307677

• Add juju_machine_id to the hooks environment Lp 1359714

• Openstack provider, instance-state doesn't change on instance shutdown Lp 1382709

• Config-get error inside config-changed: "settings not found" Lp 1301996

• Open-stack provider breaks swift with standard config Lp 1312217

A new stable release of Juju, juju-core 1.20.14, is now available. This release replaces 1.20.13.

Getting Juju

juju-core 1.20.14 is available for utopic (Ubuntu 14.10) and backported to earlier series in the following PPA:

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

Notable Changes

This releases addresses stability and performance issues.

Resolved issues

• Container scoped relations between 2 subordinates broken in 1.20.12 Lp 1396625

• Azure instance-types and regions missing Lp 1389422

• Ec2 says agent-state-info: 'cannot run instances: no default subnet for availability zone: ''us-east-1e''. (invalidinput)' Lp 1388860

• Lxc containers in pending state due to juju-br0 misconfiguration Lp 1395908

A new stable release of Juju, juju-core 1.20.13, is now available. This release replaces stable 1.20.12.

Getting Juju

juju-core 1.20.13 is available for utopic and backported to earlier series in the following PPA:

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

Notable Changes

This releases addresses stability and performance issues.

Resolved issues

• 1.20.12 breaks neutron-gateway, since all interfaces are brought up Lp 1395081

A new stable release of Juju, juju-core 1.20.12, is now available. This release replaces stable 1.20.11.

Getting Juju

juju-core 1.20.12 is available for utopic and backported to earlier series in the following PPA:

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

Notable Changes

This releases addresses stability and performance issues.

Resolved issues

• Juju run doesn't after upgrade to 1.20.11 Lp 1392745

• Non subordinate container scoped relations broken Lp 1382751

• Juju add-machine lxc:0 fails to start due to incorrect network name in trusty config Lp 1340261

• Cloud-init network error when using maas/juju Lp 1345433

• Juju deploy --to lxc:0 works ok but juju deploy --to lxc:1 fails Lp 1368976

• Juju deploy to kvm:0 fails for br0 Lp 1386575

A new stable release of Juju, juju-core 1.20.11, is now available. This release replaced stable 1.20.10.

Getting Juju

juju-core 1.20.11 is available for utopic and backported to earlier series in the following PPA:

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

Notable Changes

This releases addresses stability and performance issues.

Resolved issues

• Local environment machine deployments fail after "juju destroy- machine" has been used Lp 1379802

• Juju does not consider whether it has permission to an availability zone Lp 1380557

A new stable release of Juju, juju-core 1.20.10, is now available. This release replaces stable 1.20.9.

Getting Juju

juju-core 1.20.10 is available for utopic and backported to earlier series in the following PPA:

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

Notable Changes

This releases addresses packaging and documentation issues.

Resolved issues

• make-release-tarball could check the packages with dependencies.tsv Lp 1368417

A new stable release of Juju, juju-core 1.20.9, is now available. This release replaces stable 1.20.8.

Getting Juju

juju-core 1.20.9 is available for utopic and backported to earlier series in the following PPA:

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

Notable Changes

This releases addresses stability and performance issues.

Resolved issues

• Not okforstorage error when deploying local charm Lp 1308146

• Cloud-archive on precise not pinned when juju calls apt-get upgrade Lp 1370781

A new stable release of Juju, juju-core 1.20.8, is now available. This release may replace stable 1.20.7.

Getting Juju

juju-core 1.20.8 is available for utopic and backported to earlier series in the following PPA:

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

Notable Changes

This releases addresses stability and performance issues.

Resolved issues

• Maas provider assumes machine uses dhcp for eth0 Lp 1361374

• Relation-get with invalid relation name panics agent Lp 1365412

• Bootstrap on maas fails trying to access cloud-images.ubuntu.com Lp 1365135

• Not okforstorage error when deploying local charm Lp 1308146

• Add-machine containers should default to latest lts Lp 1363971

• Juju add-machine still assumes precise (maas) Lp 1315473

• Juju-core client panics with juju set empty string Lp 1348829

• --keep-broken option still allows instance to be stopped Lp 1365772

• Some third party embedded sources in the source tarball are missing dependencies.tsv entries Lp 1368321

• Licensing is inconsistent Lp 1368358

• Sshstorage fails in non-english locale Lp 1367695

A new stable release of Juju, juju-core 1.20.7, is now available. This release replaces 1.20.6.

Getting Juju

juju-core 1.20.7 is available for utopic and backported to earlier series in the following PPA:

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

Noteworthy

This release contains various bug fixes.

Resolved issues

• --keep-broken bootstrap option to keep failed environments Lp 1362923

• LXC was not created, no errors, no logs -> pending state. Lp 1354027

• Juju status still returns private IP in 'public-ip' field Lp 1364419

A new stable release of Juju, juju-core 1.20.6, is now available. This release replaces 1.20.5.

Getting Juju

juju-core 1.20.6 is available for utopic and backported to earlier series in the following PPA:

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

Noteworthy

This releases addresses stability issues, particularly with LXC.

Resolved issues

• Arguments no longer passed to plugins if you don't have an environment set Lp 1359170

• ERROR Nonce already used Lp 1190986

• Juju status returns private IP in 'public-ip' field. Lp 1348287

• Juju status nil pointer reference. Lp 1357482

• LXC containers created, juju can't seen or communicate with them Lp 1357552

• Cannot get tools from machine for lxc container Lp 1359800

• Tools download can fail and is not always retried Lp 1360994

• Containers not starting on machine Lp 1362360

• Update the add machine api to accept both environment name and UUID Lp 1360063

A new stable release of Juju, juju-core 1.20.5, is now available. This release replaces 1.20.1.

Getting Juju

juju-core 1.20.5 is available for utopic and backported to earlier series in the following PPA:

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

Noteworthy

This releases addresses stability and performance issues.

Resolved issues

• Juju is stripping underscore from options Lp 1243827

• Juju api-endpoints cannot distinguish public and private addresses Lp 1311227

• API server inaccessible for roughly 5 seconds after bootstrap Lp 1351083

• Juju bootstrap in an existing environment destroys the environment Lp 1340893

• The jujud on state server panic misses transaction in queue Lp 1318366

• Juju machine agents suiciding Lp 1345014

• Juju state server database is overly large Lp 1344940

• Jujud rewrites /etc/init/juju-db.conf constantly Lp 1349969

• Juju writes to mongo without an actual change occurring Lp 1345832

• Talking to mongo can fail with "TCP i/o timeout" Lp 1307434

• Bootstrap fails if /usr/lib/juju/bin/mongod doesn't already exist Lp 1350700

• Support the new v4 signing format used by the new China region Lp 1319475

• Azure: secondary state servers do not load balance API server port Lp 1347371

• Network error causes tools download to fail Lp 1349989

• Maas provider: allow users to specify network bridge interface. Lp 1337091

• ppc64 architecture miss match for MAAS ppc64el Lp 1349771

• MAAS provider uses dead instance address Lp 1353442

• Juju bootstrap fails if kvm-ok not in path Lp 1342747

• Juju-local needs new dep dbus -- specifically to work in lxc Lp 1343301

• LXC clonetemplate lock can be left stale Lp 1311668

• LXC deploys broken on precise Lp 1350011

• LXC template fails to stop Lp 1348386

• Distribution tarball has licensing problems that prevent redistribution Lp 1341589

A new stable release of Juju, juju-core 1.20.1, is now available. This release replaces 1.20.0.

Getting Juju

juju-core 1.20.1 is available for utopic and backported to earlier series in the following PPA:

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

Noteworthy

This release fixes several issues seen in slower environments. The performance improvements also improved reliability. Juju CI saw a 35% speed improvement in the test suite. While we had planned to release 1.20.1 on 2014-07-17, the performance improvements were just too good to delay a whole week.

Resolved issues

• Juju 1.20 consistently fails to bootstrap a MAAS environment Lp 1339240

• Juju bootstrap fails because mongodb is unreachable Lp 1337340

• Juju 1.20.x slow bootstrap Lp 1338179

• API-endpoints fails if run just after bootstrap Lp 1338511

• Machines are killed if mongo fails Lp 1339770

• Restore doesn't Lp 1336967

A new stable release of Juju, juju-core 1.20.0, is now available.

Getting Juju

juju-core 1.20.0 is available for utopic and backported to earlier series in the following PPA:

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

New and Notable

• High Availability
• Availability Zone Placement
• Azure Availability Sets
• Juju debug-log Command Supports Filtering and Works with LXC
• Constraints Support instance-type
• The lxc-use-clone Option Makes LXC Faster for Non-Local Providers
• Support for Multiple NICs with the Same MAC
• MaaS Network Constraints and Deploy Argument
• MAAS Provider Supports Placement and add-machine
• Server-Side API Versioning

Resolved issues

• Juju client is not using the floating ip to connect to the state server Lp 1308767

• Juju help promotes the 'wrong' versions of commands Lp 1299120

• Juju backup command fails against trusty bootstrap node Lp 1305780

• The root-disk constraint is broken on ec2 Lp 1324729

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

• Images are not found if endpoint and region are inherited from the top level in simplestreams metadata Lp 1329805

• Missing @ syntax for reading config setting from file content Lp 1216967

• Deploy --config assumes relative path if it starts with a tilde (~) Lp 1271819

• local charm deployment fails with symlinks Lp 1330919

• Git usage can trigger disk space/memory issues for charms with blobs Lp 1232304

• Juju upgrade-charm fails because of git Lp 1297559

• .pyc files caused upgrade-charm to fail with merge conflicts Lp 1191028

• Juju debug-hooks should display a start message Lp 1270856

• Can't determine which relation is in error from status Lp 1194481

• Dying units departure is reported late Lp 1192433

• Juju upgrade-juju needs a dry run mode Lp 1272544

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

• Juju destroy-environment >=256 nodes fails Lp 1316272

• Azure destroy-environment does not complete Lp 1324910

• Azure bootstrap dies with xml schema validation error Lp 1259947

• Azure provider stat output does not show machine hardware info Lp 1215177

• Bootstrapping azure causes memory to fill Lp 1250007

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

• Floating IPs are not recycled in OpenStack Havana Lp 1247500

• LXC cloning should be default behaviour Lp 1318485

• Nasty worrying output using local provider Lp 1304132

• Intermittent error destroying local provider environments Lp 1307290

• Default bootstrap timeout is too low for MAAS environments Lp 1314665

• MAAS provider cannot provision named instance Lp 1237709

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

• Manual provider specify bash as shell for ubuntu user Lp 1303195

High Availability

The juju state-server (bootstrap node) can be placed into high availability mode. Juju will automatically recover when one or more the state-servers fail. You can use the 'ensure-availability' command to create the additional state-servers:

bash juju ensure-availability

The 'ensure-availability' command creates 3 state servers by default, but you may use the '-n' option to specify a larger number. The number of state servers must be odd. The command supports the 'series' and 'constraints' options like the 'bootstrap' command. You can learn more details by running 'juju ensure-availability --help'

Availability Zone Placement

Juju supports explicit placement of machines to availability zones (AZs), and implicitly spreads units across the available zones.

When bootstrapping or adding a machine, you can specify the availability zone explicitly as a placement directive. e.g.

bash juju bootstrap --to zone=us-east-1b juju add-machine zone=us-east-1c

If you don't specify a zone explicitly, Juju will automatically and uniformly distribute units across the available zones within the region. Assuming the charm and the charm's service are well written, you can rest assured that IaaS downtime will not affect your application. Commands you already use will ensure your services are always available. e.g.

bash juju deploy -n 10 <service>

When adding machines without an AZ explicitly specified, or when adding units to a service, the ec2 and openstack providers will now automatically spread instances across all available AZs in the region. The spread is based on density of instance "distribution groups".

State servers compose a distribution group: when running 'juju ensure-availability', state servers will be spread across AZs. Each deployed service (e.g. mysql, redis, whatever) composes a separate distribution group; the AZ spread of one service does not affect the AZ spread of another service.

Amazon's EC2 and OpenStack Havana-based clouds and newer are supported. This includes HP Cloud. Older versions of OpenStack are not supported.

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:

yaml availability-sets-enabled: false

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

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:

bash 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:

no-highlight <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:

bash 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:

bash 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:

bash 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

bash 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:

bash 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:

bash juju debug-log --lines 500 | grep amd64

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

Constraints Support instance-type

You can specify 'instance-type' with the 'constraints' option to select a specific image defined by the cloud provider. The 'instance-type' constraint can be used with Azure, EC2, HP Cloud, and all OpenStack-based clouds. For example, when creating an EC2 environment, you can specify 'm1.small':

bash juju bootstrap --constraints instance-type=m1.small

Constraints are validated by all providers to ensure values conflicts and unsupported options are rejected. Previously, juju would reconcile such problems and select an image, possibly one that didn't meet the needs of the service.

The lxc-use-clone Option Makes LXC Faster for Non-Local Providers

When 'lxc-use-clone' is set to true, the LXC provisioner will be configured to use cloning regardless of provider type. This option cannot be changed once it is set. You can set the option to true in environments.yaml like this:

yaml lxc-use-clone: true

This speeds up LXC provisioning when using placement with any provider. For example, deploying mysql to a new LXC container on machine 0 will start faster:

bash juju deploy --to lxc:0 mysql

Support for Multiple NICs with the Same MAC

Juju now supports multiple physical and virtual network interfaces with the same MAC address on the same machine. Juju takes care of this automatically, there is nothing you need to do.

Caution, network settings are not upgraded from 1.18.x to 1.20.x. If you used juju 1.18.x to deploy an environment with specified networks, you must redeploy your environment instead of upgrading to 1.20.0.

The output of 'juju status' will include information about networks when there is more than one. The networks will be presented in this manner:

no-highlight machines: ... services: ... networks: net1: provider-id: foo cidr: 0.1.2.0/24 vlan-tag: 42

MaaS Network Constraints and Deploy Argument

You can specify which networks to include or exclude as a constraint to the deploy command. The constraint is used to select a machine to deploy the service's units too. The value of 'networks' is a comma-delimited list of juju network names (provided by MaaS). Excluded networks are prefixed with a "^". For example, this command specify the service requires the "logging" and "storage" networks and conflicts with the "db" and "dmz" networks.

bash juju deploy mongodb --constraints networks=logging,storage,^db,^dmz

The network constraint does not enable the network for the service. It only defines what machine to pick.

Use the 'deploy' command's 'networks' option to specify service-specific network requirements. The 'networks' option takes a comma-delimited list of juju-specific network names. Juju will enable the networks on the machines that host service units.

Juju networking support is still experimental and under development, currently only supported with the MaaS provider.

bash juju deploy mongodb --networks=logging,storage

The 'exclude-network' option was removed from the deploy command as it is superseded by the constraint option.

There are plans to add support for network constraint and argument with Amazon EC2, Azure, and OpenStack Havana-based clouds like HP Cloud in the future.

MAAS Provider Supports Placement and add-machine

You can specify which MAAS host to place the juju state-server on with the 'to' option. To bootstrap on a host named 'fnord', run this:

bash juju bootstrap --to fnord

The MAAS provider support the add-machine command now. You can provision an existing host in the MAAS-based Juju environment. For example, you can add running machine named fnord like this:

bash juju add-machine fnord

Server Side API Versioning

The Juju API server now has support for a Version field in requests that are made. For this release, there are no RPC calls that require anything other than 'version=0' which is the default when no Version is supplied. This should have limited impact on existing CLI or API users, since it allows us to maintain exact compatibility with existing requests. New features and APIs should be exposed under versioned requests.

For details on the internals (for people writing API clients), see: this document

Finally

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

A new stable release of Juju, juju-core 1.18.3, is now available. This release replaces 1.18.2.

Getting Juju

juju-core 1.18.3 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.

Resolved issues

• juju sync-tools destroys the environment when given an invalid source Lp 1316869
• Local provider behaves poorly when juju-mongodb is not installed on trusty Lp 1301538
• Juju bootstrap defaults to i386 Lp 1304407
• LXC local provider fails to provision precise instances from a trusty host Lp 1306537
• LXC nested within kvm machines do not use lxc-clone Lp 1315216

A new stable release of Juju, juju-core 1.18.2, is now available. This release replaces 1.18.1.

Getting Juju

juju-core 1.18.2 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.

Resolved issues

• Manual provisioned systems stuck in pending on arm64 Lp 1302205
• Version reports "armhf" on arm64 Lp 1304742
• Juju deploy --to lxc:0 cs:trusty/ubuntu creates precise container Lp 1302820
• If the provisioner fails to find tools for one machine it fails to provision the others LP 1311676
• Juju status panic() when unable to parse .jenv Lp 1312136
• Juju authorised-keys should have an authorized-keys alias Lp 1312537
• Race condition on bootstrap machine addresses with manual provider Lp 1314430

A new stable release of Juju, juju-core 1.18.1, is now available. This release replaces 1.18.0.

Getting Juju

juju-core 1.18.1 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.

Notable

• Working with Ubuntu 12.04 Precise and 14.04 Trusty

Resolved issues

• Juju upgrade-juju 1.16.6 -> 1.18 (tip) fails Lp 1299802
• Peer relation disappears during upgrade of juju Lp 303697
• The public-address changed to internal bridge after juju-upgrade Lp 1303735
• juju cannot downgrade to same major.minor version with earlier patch number Lp 1306296
• Juju 1.18.0, can not deploy local charms without series Lp 1303880
• Juju scp no longer allows multiple extra arguments to pass through Lp 1306208
• Juju tests fail with release version number 1.18.0 Lp 1302313
• Charm store tests do not pass with juju-mongodb Lp 1304770

Working with Ubuntu 12.04 Precise and 14.04 Trusty

Juju 1.18.x is the first Juju that is aware of two Ubuntu LTS releases. In the past, when bootstrapping the state-server or deploying a charm, Juju selected Ubuntu 12.04 Precise when the serie was not specified. If you care about the version of Ubuntu used, then you want to specify the series

You can specify the series of the state-server and set the default charm series by adding "default-series" to environments.yaml. Setting "default- series" is the only way to specify the series of the state-server (bootstrap node). For example, if your local machine is Ubuntu 14.04 trusty, but your organisation only supports Ubuntu 12.04 Precise in the cloud, you can add this to your environment in environments.yaml:

yaml default-series: precise

There are many ways to specify the series to deploy with a charm. In most cases you don't need to. When you don't specify a series, Juju checks the environment's default-series, and if that isn't set, Juju asks the charm store to select the best series to deploy with the charm. The series of the state-server does not restrict the series of the charm. You can use the best series for a charm when deploying a service.

When working with local charms, Juju cannot fall back to the charm store, it falls back to the environment's default-series. You must specify the series in the environment or when deploying the charm. If your environment is running, you can add default-series like so:

bash juju set-environment default-series=precise

These commands choose Ubuntu 12.04 Precise when default-series is set to "precise" in the environment:

bash juju deploy cs:precise/mysql juju deploy precise/mysql juju deploy mysql juju deploy local:precise/mysql juju deploy loca:mysql

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:

yaml 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:

bash 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.

bash 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.

bash 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:

bash juju run "uname -a" --all

Or to run uptime on some instances:

bash 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 generate

simplestreams 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:

bash 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 set up 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

bash 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:

yaml 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.

yaml 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:

bash 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.

bash 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:

bash 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.

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

juju-dev on freenode.

A new stable release of Juju, juju-core 1.16.6, is now available. This release replaces 1.16.5.

Getting Juju

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

Resolved issues

• Azure provider handles 307 temporary redirects poorly Lp 1269835
• Loading state on bootstrap ignores ssl-hostname-verification setting Lp 1268913
• Provide remove-* aliases for destroy-service and destroy-machine Lp 1261628

Notable Changes

This release addresses intermittent failures observed in recent weeks in Azure. Users may have seen “(request failed...307: Temporary Redirect)” when issuing juju commands.

The destroy-service and destroy-machine commands were renamed to remove- service and remove-machine respectively. The commands are still available under their old names; no scripts were harmed in the making of this release.

A new stable release of Juju, juju-core 1.16.5, is now available. This release replaces 1.16.4.

Getting Juju

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

Resolved issues

• service with no units stuck in lifecycle dying Lp 1233457
• destroy-machine --force Lp 089291
• destroy-machine --force plays badly with provisioner-safe-mode Lp 1259473
• API incompatibility: ERROR no such request "DestroyMachines" on Client Lp 1252469
• juju destroy-machine is incompatible in trunk vs 1.16 Lp 1253643
• juju get give a "panic: index out of range" error Lp 1227952
• [maas] juju set-env fails after upgrading to 1.16.2+ Lp 1256179
• juju destroy-environment destroys other environments Lp 1257481

Notable Changes

Juju may report the status of a service and machine that was terminated outside of Juju. Juju did not notice that the machine is gone. This release provides minor fixes to identify the case, and a feature to explicitly tell juju that the machine is gone.

bash juju destroy-machine --force

The destroy-machine command will destroy the machine as needed, and remove it from its list of available machines. Machines that are responsible for the environment cannot be destroyed. Machines running units or containers can only be destroyed with the --force flag; doing so will also destroy all those units and containers without giving them any opportunity to shut down cleanly.

Future version of Juju will notice when machines disappear without the need of destroy-machine --force.

A new stable release of Juju, juju-core 1.16.4, is now available. This release replaces 1.16.3.

Getting Juju

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

Resolved issues

• Update Juju to make a "safe mode" for the provisioner Lp 1254729
• juju set-env fails for boolean attributes Lp 1254938
• juju-update-bootstrap-address plugin Lp 1254579

A new stable release of Juju, juju-core 1.16.3, is now available. This release replaces 1.16.0.

Getting Juju

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

Resolved issues

• local provider deploys fail with 'install hook failed' Lp 247299

A new stable release of Juju, juju-core 1.16.2, is now available. This release replaces 1.16.0.

Getting Juju

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

Resolved issues

• Azure bootstrap fails, versioning header is not specified. All versions of juju deploying to Azure experienced this bug when Azure updated its API on 2013-10-28. This release restores service. Lp 1246320.
• Local provider fails to start; connection refused or machines stuck in pending. Local deploys (LXC) are now given storage. Container information is now provided for MaaS config. Lp 1240709 and Lp 1246556
• Running destroy-environment with juju on MaaS must only destroy nodes that juju controls. Lp 1081247 and Lp 1081247
• Ensure the cloud-archive key is installed so that downloads work without additional verification. Lp 1243861.
• Relation names can contain underscores. Lp 1245004

Released:2013-10-31

A new stable release of Juju, juju-core 1.16.0, is now available.

Getting Juju

juju-core 1.16.0 is available in Saucy and backported to earlier series in the following PPA https://launchpad.net/~juju/+archive/stable

New and Notable

• bootstrap now matches on major and minor version numbers when locating tools
• public-bucket-url is deprecated, use tools-url and/or image-metadata-url instead
• users running from source no longer need to manually specify --upload-tools in order to have tools available for bootstrapping
• tools retrieval is now handled using simplestreams metadata, similar to how image id lookup works
• tools no longer have to be located in a publicly readable cloud storage instance; they can be served by any HTTP server eg apache
• new constraint: tags. This constraint is currently only supported by MaaS environments, and allows you to specify nodes by tags applied to them in MaaS. Example: juju deploy mysql --constraints tags=foo,bar will deploy mysql to a node that is tagged with both the "foo" tag and the "bar" tag.
• the "null" provider is now available, for creating environments with existing machines.
• admin-secret is now chosen automatically if omitted from the configuration of a new environment.
• control-bucket is now chosen automatically if omitted from the configuration for new ec2 and openstack environments.
• Logging has changed. You can specify an environment variable "JUJU_LOGGING_CONFIG", or you can specify --logging-config on the command line. To show the log on the command line, now use --show-log. The --debug has been kept to be short-hand for --logging-config==DEBUG --show-log, and --verbose has been deprecated with its current meaning.

Resolved issues

• "juju add-machine ssh:..." no longer fails when an IP address is specified instead of a hostname. LP #1225825
• Bootstrap nodes will now only run one copy of Mongodb, this will result in lower resource utilisation and faster startup of the bootstrap node. Closes LP #1210407
• EC2 accounts in default VPC mode now work with juju. LP #1221868
• The unset command is now available from the command line. LP #1237929 Configuration changes
• tools-url is a new configuration option used to specify the location where the tools tarballs may be found. If specified, this overrides the default tools repository.
• image-metadata-url is a new configuration option used to specify the location where image metadata may be found. This is only normally required for private Openstack deployments.
• public-bucket-url is deprecated - use tools-url to specify where tools are located (if not handled automatically by your cloud provider).

Testing on Canonistack and HP Cloud

Starting with this release, there is no longer any requirement to use a public-bucket-url configuration attribute when bootstrapping Canonistack or HP Cloud environments. The public-bucket-url attribute is deprecated and you are advised to remove it from your environment configuration.

Bootstrapping and tools

When Juju bootstraps an environment, it searches for a tools tarball matching the version of the Juju client used to run the bootstrap. Prior to this release, any tools with the same major version number as the Juju client were considered a match. Starting with this release, both the major and minor version numbers must match. This is to prevent any subtle and hard to find bugs due to version mismatch from manifesting themselves.

For users of Juju on EC2, HP Cloud, Azure, and Canonistack, where the tools are maintained by Canonical in the cloud itself, and MASS, with access to the web to download the tools, there will be no noticeable change. For private cloud setups, more care will be needed to ensure all the required tools tarballs are available.

Configuring tools

A focus of this release is to make bootstrapping a Juju environment work better out of the box, eliminating the need for manual configuration steps. To this end, the following improvements are delivered:

1. HP Cloud and Canonistack users no longer need any special configuration over and above what goes into any generic Openstack setup for Juju.
2. Users who compile and run Juju from source can bootstrap without manually having to tell Juju to upload a custom tools tarball. The upload-tools bootstrap option is still available to force a tools upgrade, but it is no longer required just to bootstrap the first time or when starting again after an environment has been destroyed.

Users who wish to run Juju in HP Cloud from scratch can now just follow the same steps as used for EC2:

1. run juju init
2. source a credentials file containing username, password, region etc, or edit the newly created ~/.juju/environments.yaml file to add username, password, region etc to the hpcloud environment block
3. run juju bootstrap -e hpcloud

HP Cloud users can run juju switch hpcloud to make the default environment hpcloud and remove the need to use the -e parameter with each Juju command.

Private Openstack deployments

Tools can now be served by any http server, or from a shared mounted directory accessible from the cloud, removing the requirement to place the tools in a cloud storage instance. Using a cloud storage instance is still possible of course, but this option may be more desirable for users who wish to set up a private cloud without outgoing web access. The steps are as follows:

1. Copy the tools tarballs for a given Juju version to a directory named like: /tools/releases
2. run juju sync-tools --all --source= --destination=
3. Configure your http server to serve to contents of under http://
4. Add tools-url: http:// to your environments.yaml file.

An alternative to using http is to copy the tools directory itself, from , to a shared drive which is accessible to client machines and cloud instances via a common mounted directory. In that case, add an entry like this to your environments.yaml:

yaml tools-url: file://mounted_dir

Users who still wish to place the tools in a cloud instance should copy the tools directory itself to a publicly readable storage instance. Thenadd the tools-url entry to environments.yml:

yaml tools-url: https:///tools

A final alternative for locating tools is to copy the entire tools directory created above to the cloud’s control bucket, as specified in the environments.yaml file. No tools-url configuration is required, but note that these tools will only be visible to that one particular Juju environment.

Configuring image metadata

Just as private Openstack deployments need to configure where tools are located, so too does the location of the image metadata need to be specified. This is not applicable for supported openstack clouds like HP Cloud and Canonistack, only private deployments. Prior to this release, the public- bucket-url was used to point to the location of the metadata. Now, configure the image-metadata-url as follows:

yaml image-metadata-url: /juju-dist

Note that the image metadata no longer has to be kept in a cloud storage instance. The above example simply assumes the metadata will be kept in the same location as prior to this release. But as with tools, the image metadata may be server from any http url or even a directory using file://

A new stable release of Juju, juju-core 1.14.1, is now available.

This release replaces juju-core 1.14.0. It reconciles differences between juju clients.

Getting Juju

juju-core 1.14.1 is available in Saucy and backported to earlier series in the following PPA

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

New and Notable

• The Microsoft Azure provider is now considered ready for use.
• lp # 1184786 juju cli now gives a clearer error message when the deprecated default-image-id key is found.
• When debugging hooks, juju will set the $PS1 value to $JUJU_UNIT_NAME:$JUJU_HOOK_NAME %. This results in a shorter and more useful prompt. Closes ##1212903
• Juju plugins no longer required the caller to escape all arguments passed to the plugin.
• The new command “juju unset …” allows a configuration setting for a service to be removed. Removing the configuration setting will revert it to the charm default. This is the first step in solving #1194945.
• The Windows Azure provider now defines a public storage container for tools. No configuration changes are required. Closes #1216770.
• The debug-hooks subcommand is now implemented. Closed issue #1027876
• The status subcommand now accepts service/unit filters, to limit output; see “juju help status” for more information. Partially addresses issue #1121916
• The juju cli command now returns a better error message when run against an environment that has not been bootstrapped. Closes issue #1028053.

Resolved issues

• The destroy-environment subcommand now requests confirmation before running, with an option to quietly proceed (-y/--yes). Closed issue #1121914.
• The cost calculation for the openstack provider was updated to bias towards the lowest number of CPU cores when choosing a machine type matching the provided instance constraints. This closes issue #1210086.
• The unit agent now removes stale sockets when restarting. Closes #1212916
• A bug relating to the formatting of tool versions has been resolved. This formatting error was only visible when using the -v or --debug flag. Closes #1216285.
• lp #1206628 a bug related to the name of an upstart job created for a service unit has been corrected.
• lp # 1207230 a bug related specifying the type of local provider container has been corrected.

Known issues

• The JUJU_ENV environment variable is not being passed down to plugins. LP #1216254.

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

A new stable release of Juju, juju-core 1.14.0, is now available.

Getting Juju

juju-core 1.14.0 is available in Saucy and backported to earlier series in the following PPA

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

New and Notable

• The Microsoft Azure provider is now considered ready for use.
• lp # 1184786 juju cli now gives a clearer error message when the deprecated default-image-id key is found.
• When debugging hooks, juju will set the $PS1 value to $JUJU_UNIT_NAME:$JUJU_HOOK_NAME %. This results in a shorter and more useful prompt. Closes ##1212903
• Juju plugins no longer required the caller to escape all arguments passed to the plugin.
• The new command “juju unset …” allows a configuration setting for a service to be removed. Removing the configuration setting will revert it to the charm default. This is the first step in solving #1194945.
• The Windows Azure provider now defines a public storage container for tools. No configuration changes are required. Closes #1216770.
• The debug-hooks subcommand is now implemented. Closed issue #1027876
• The status subcommand now accepts service/unit filters, to limit output; see “juju help status” for more information. Partially addresses issue #1121916
• The juju cli command now returns a better error message when run against an environment that has not been bootstrapped. Closes issue #1028053.

Resolved issues

• The destroy-environment subcommand now requests confirmation before running, with an option to quietly proceed (-y/--yes). Closed issue #1121914.
• The cost calculation for the openstack provider was updated to bias towards the lowest number of CPU cores when choosing a machine type matching the provided instance constraints. This closes issue #1210086.
• The unit agent now removes stale sockets when restarting. Closes #1212916
• A bug relating to the formatting of tool versions has been resolved. This formatting error was only visible when using the -v or --debug flag. Closes #1216285.
• lp #1206628 a bug related to the name of an upstart job created for a service unit has been corrected.
• lp # 1207230 a bug related specifying the type of local provider container has been corrected.

Known issues

• The JUJU_ENV environment variable is not being passed down to plugins. LP #1216254.

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