juju devel 1.19.4 is released

Thu Jun 26 17:29:12 UTC 2014

juju-core 1.19.4

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

Getting Juju

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

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

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

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

New and Notable

* Availability zone placement

* Network constraints and deploy argument for MasS

* Server side API Versioning

* New juju-local-kvm package

Resolved issues

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

* Replicaset initiation fails when mongo is on a big, slow disk
  Lp 1327940

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

* Upgrading 1.18 to 1.19 breaks agent.conf
  Lp 1333682

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

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

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

* local charm deployment fails with symlinks
  Lp 1330919

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

* Creating a local environment stops the syslog (1.19.3)
  Lp 1332358

* Can't destroy MAAS environment with LXCs
  Lp 1325830

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

* 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

* Floating IPs are not recycled in OpenStack Havana
  Lp 1247500

Availability zone placement

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

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

    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.

    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 uses an inverted concept of availability sets, and Juju announced
support for this in 1.19.0

Network constraints and deploy argument for MasS

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.

    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" argument to specify
service-specific network requirements. The "--networks" argument 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.

The "--exclude-network" argument 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 next several releases.

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:
    https://docs.google.com/document/d/1fPOSUu7Dc_23pil1HGNTSpdFRhkMHGxe4o6jBghZZ1A/edit?usp=sharing

New juju-local-kvm package

The devel PPA has a juju-local-kvm package that satisfies the deps that
juju requires to deploy to kvm containers. Installation of this package
will ensure juju doesn't abort a bootstrap to request additional packages
to be installed on the host.

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