Juju devel 1.24-beta1 is available

Fri May 8 21:02:18 UTC 2015

# juju-core 1.24-beta1

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

## Getting Juju

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

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

Windows and OS X users will find installers at:

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

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

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

## Notable Changes

  * VMWare (vSphere) Provider
  * Storage (experimental) MAAS Provider Support
  * Storage (experimental) Unit Placement

### 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 nearly all vSphere installations.

### 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

  * 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

Finally

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

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