juju-core 1.19.4
This is an unstable micro release.
Milestone information
- Project:
- juju-core
- Series:
- 1.20
- Version:
- 1.19.4
- Released:
- Registrant:
- Curtis Hovey
- Release registered:
- Active:
- No. Drivers cannot target bugs and blueprints to this milestone.
Activities
- Assigned to you:
- No blueprints or bugs assigned to you.
- Assignees:
- 17 Andrew Wilkins, 3 Curtis Hovey, 3 Dave Cheney, 1 Dimiter Naydenov, 1 Domas Monkus, 1 Eric Snow, 1 Horacio Durán, 10 Ian Booth, 1 Jimmie Butler, 3 John A Meinel, 1 Jorge Niedbalski, 1 Matthew Williams, 1 Menno Finlay-Smits, 3 Michael Foord, 1 Tim Penhey, 4 Wayne Witzel III
- Blueprints:
- No blueprints are targeted to this milestone.
- Bugs:
- 54 Fix Released
Download files for this release
Release notes
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:/
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:/
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
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-
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=
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:/
Finally
We encourage everyone to subscribe the mailing list at
juju-dev@
Changelog
This release does not have a changelog.
