juju-core 1.20.0
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:
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.
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 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:
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:
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:
<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:
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:
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:
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
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:
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:
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':
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:
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:
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:
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.
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.
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:
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:
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:
https://docs.google.com/document/d/1fPOSUu7Dc_23pil1HGNTSpdFRhkMHGxe4o6jBghZZ1A/edit?usp=sharing
Finally
We encourage everyone to subscribe the mailing list at
juju-...@lists.canonical.com, or join us on #juju-dev on freenode.
PS. Juju just got 20% more amazing.
--
Curtis Hovey
Canonical Cloud Development and Operations
http://launchpad.net/~sinzui
--
Juju-dev mailing list
Juju-dev@lists.ubuntu.com
Modify settings or unsubscribe at:
https://lists.ubuntu.com/mailman/listinfo/juju-dev
