Juju devel 1.25-alpha1 is released

Fri Aug 28 18:26:19 UTC 2015

# juju-core 1.25-alpha1

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

## Getting Juju

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

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

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

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

Development releases use the "devel" simple-streams. This release
will automatically select the devel stream. You do not need to update
your config in environments.yaml to bootstrap.

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

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

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

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

With the "address-allocation" feature flag enabled, Juju will register lxc and
kvm containers as devices on MAAS 1.8+. They are visible in the MAAS UI. If
the environment is forcibly shut down, the IP addresses allocated to the
containers will be released by MAAS.

You can enable "address-allocation" is new Juju environments like so:

    JUJU_DEV_FEATURE_FLAG=address-allocation juju bootstrap

### 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.
To show the status of volumes, use "juju storage volume list".

## Resolved issues

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

  * Cli rejects placement directives
    Lp 1358941

  * Feature flags don't propagate to windows agents
    Lp 1401368

  * Upgrade fails if no explicit version is specified
    Lp 1447899

  * Provider/openstack: cinder provider should reject attempts to
    create non-persistent volumes
    Lp 1450737

  * Storage: loop devices leaked by lxc containers
    Lp 1452649

  * Deployments fail when juju implicitly upgrade after bootstrap
    Lp 1455260

  * Openstack provider should work without object-store
    Lp 1456265

  * Apiserver run method doesn't validates if machines, services or
    units are present on the request.
    Lp 1456343

  * Upgrade fails if there's a series in streams juju doesn't
    recognize
    Lp 1459093

  * Init system discovery script has bashisms
    Lp 1459775

  * Juju should use devices api on maas 1.8+ for addressable
    containers
    Lp 1464237

  * "attachmentcount" and "binding" fields not set when upgrading from
    1.24
    Lp 1467379

  * Charms with storage don't use cloud-native default if size is
    specified, but provider is omitted
    Lp 1468153

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

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

  * Destroying local provider environments sometimes emits "error" log
    messages
    Lp 1477263

  * Automatic devel streams selection for beta releases
    Lp 1481500

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

  * Provider/openstack: default block source not set to "cinder"
    Lp 1484403

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

  * Incorrectly disconnected debug-hooks does not reconnect to tmux
    Lp 1265871

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

  * After "juju destroy-service <charm-name>" is executed,  the
    corresponding windows charm service is not uninstalled
    Lp 1471771

Finally

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