Juju 2.4.0 has been released

Tue Jul 3 09:20:38 UTC 2018

*Juju team is proud to release version 2.4. This release greatly improves
running and operating production infrastructure at scale. Improvements to
`juju status` output, easier maintenance of proper HA, and guiding Juju to
the correct management network all aid in keeping your infrastructure
running smoothly.  * Bionic supportJuju 2.4 fully supports running
controllers and workloads on Ubuntu 18.04 LTS (Bionic), including
leveraging netplan for network management. * LXD enhancementsLXD
functionality has been updated to support the latest LXD 3.0. Juju supports
LXD installed as a Snap and defaults to Snap-installed LXD by default if it
is present. A basic model of LXD clustering is now supported with the
following conditions: - The juju bootstrap of the localhost cloud must be
performed on a cluster member.- Bridge networking on clustered machines
must be set up to allow egress traffic to the controller container(s).*
Status UX cleanup - ‘Relations’ section in status output has been cleaned
up:- When filtering by application name, only direct relations are shown;-
In tabular format, ‘relations’ section is no longer visible by default (bug
# 1633972 <https://bugs.launchpad.net/juju/+bug/1633972>). Use
‘--relations’ option to see the section.- Clarified empty status output:
whether it is due to a model being empty or because a provided filter did
not match anything on the model (bugs 1255786
<https://bugs.launchpad.net/juju-core/+bug/1255786>, 1696245
<https://bugs.launchpad.net/juju/+bug/1696245> and 1594883
<https://bugs.launchpad.net/juju/+bug/1594883>).- Addition of a timestamp
to the status output (bug 1765404
<https://bugs.launchpad.net/juju/+bug/1765404>)- Reordering the status
model table to improve consistency between model updates. - Status now
shows application endpoint binding information (in YAML and JSON formats).
For each endpoint, the space to which it is bound is listed.* Controller
configuration options for network spacesTwo new controller configuration
settings have been introduced (see
https://docs.jujucharms.com/2.4/en/controllers-config
<https://docs.jujucharms.com/2.4/en/controllers-config>). These are: -
juju-mgmt-space- juju-ha-spacejuju-mgmt-space is the name of the network
space used by agents to communicate with controllers. Setting a value for
this item limits the IP addresses of controller API endpoints in agent
config, to those in the space. If the value is misconfigured so as to
expose no addresses to agents, then a fallback to all available addresses
results. Juju client communication with controllers is unaffected by this
value.Juju-ha-space is the name of the network space used for MongoDB
replica-set communication in high availability (HA) setups. This replaces
the previously auto-detected space used for such communication. When
enabling HA, this value must be set where member machines in the HA set
have more than one IP address available for MongoDB use, otherwise an error
will be reported. Existing HA replica sets with multiple available
addresses will report a warning instead of an error provided the members
and addresses remain unchanged.Using either of these options during
bootstrap or enable-ha effectively adds constraints to machine
provisioning. The commands will fail with an error if such constraints
cannot be satisfied.* Rework of 'juju enable-ha'In Juju 2.4 you can no
longer use 'juju enable-ha' to demote controllers. Instead you can now use
the usual 'juju remove-machine X' command, targeting a controller machine.
This will gracefully remove the machine as a controller and from the
database replica set. This method does allow you to end up with an even
number of controllers, which is not a recommended configuration. After
removing a controller it is recommended to run 'juju enable-ha' to bring
back proper redundancy. 'juju remove-machine --force' is also available,
for when the machine is gone and not available to run its own teardown and
cleanup. See https://docs.jujucharms.com/2.4/en/controllers-ha
<https://docs.jujucharms.com/2.4/en/controllers-ha>.* New charming tool:
Charm Goal StateCharm goal state allows charms to discover relevant
information about their deployment that might affect their behavior. For
instance, a charm may choose to wait to set up configuration because it
knows there will be enough units to build an HA cluster vs first setting
itself up as a standalone deployment and then rerunning all the
configuration to join a cluster after it sees later units. The key pieces
of information a charm needs to discover are: - what other peer units have
been deployed and their status- what remote units exist on the other end of
each endpoint, and their statusCharms use a new hook command, goal-state,
to query for information about their deployment. This hook command will
print only yaml or json output (default yaml):goal-state --format yamlThe
output will be a subset of that produced by the `juju status` command.
There will be output for sibling (peer) units and relation state per
unit.The unit status values are the workload status of the (sibling) peer
units. We also use a unit status value of dying when the unit's life
becomes dying. Thus unit status is one of: - allocating- active- waiting-
blocked- error- dyingThe relation status values are determined per unit and
depend on whether the unit has entered or left scope. The possible values
are: - joining (relation created but unit not yet entered scope)- joined
(unit has entered scope and relation is active)- broken (unit has left, or
is preparing to leave scope)- suspended (parent cross model relation is
suspended)- errorBy reporting error state, the charm has a chance to
determine that goal state may not be reached due to some external cause. As
with status, we will report the time since the status changed to allow the
charm to empirically guess that a peer may have become stuck if it has not
yet reached active state.* Model owner changesThe concept of a model
'owner' is becoming obsolete. Models now support multiple users with admin
access. None of those users is special.* Cloud credential changesCloud
credentials are used by models to authenticate communications with the
underlying provider as well as to perform authorised operations on this
provider. Juju has always dealt with both cloud credentials stored locally
on a user’s client machine as well as the cloud credentials stored remotely
on a bootstrapped Juju controller. The distinction has not been made clear
previously and this release addresses these ambiguities.Basic cloud
credential information such as its name and owner have been added to the
show-model command output. The new section looks like:mymodel:  <snip>  …
existing model output...  <snip>  credential:    name: default    owner:
admin    cloud: awsA new command has been added, show-credential, that
provides a logged on user their remotely stored cloud credentials along
with models that use them. juju show-credential ...See command help for
more information.* New Proxy config settingsNew model proxy config values
for new proxy behaviour. Using the existing model config for juju proxy
remain unchanged, and any existing model or controller should not notice
any changes at all. There are now four new model config properties are: -
juju-http-proxy, juju-https-proxy, juju-ftp-proxy, juju-no-proxyThese proxy
values are used by the model for downloading charms, but are not set as the
normal proxy environment variables for charm hook contexts, nor written as
default systemd config values.The juju-no-proxy can and should contain
CIDRs for subnets. The controller machines are not added automatically to
the juju-no-proxy value, so the internal network that is used should be in
the juju-no-proxy value if there are other proxies set.The new proxy values
are passed in to the charm hook contexts, but as the following environment
variables: JUJU_CHARM_HTTP_PROXY, JUJU_CHARM_HTTPS_PROXY,
JUJU_CHARM_FTP_PROXY, and JUJU_CHARM_NO_PROXY. The charm helpers library
will be gaining the ability to use proxies for certain activities. This is
new behaviour and still being developed.The rationale behind this change is
to better support proxies in situations where there are larger subnets, or
multiple subnets that should not be proxied. The traditional no_proxy
values cannot have CIDR values as they are not understood by many tools.*
HA controller improvementsUpgrading across release streams (devel,
released, etc) is improved as the juju-upgrade command now takes an
--agent-stream argument.* Backup Restore behavior changesMultiple backups
saved on a controller can now be removed at one time while keeping the
latest backup with `juju remove-backup --keep-latest`.More detailed help
for backup/restore is available including instructions on how to restore a
backup in an HA configuration. `juju restore-backup` provides the updated
instructions.## Important Fixes - `network-get` CIDR reporting fix:
https://bugs.launchpad.net/juju/+bug/1772887
<https://bugs.launchpad.net/juju/+bug/1772887>.- Change in behavior in
status output: ‘Relations’ section is not visible by default in tabular
format (bug # 1633972 <https://bugs.launchpad.net/juju/+bug/1633972>). Use
‘--relations’ option to see the section.- fixes for when /var, /etc, /tmp
are on different partitionshttps://bugs.launchpad.net/bugs/1634390
<https://bugs.launchpad.net/bugs/1634390>https://bugs.launchpad.net/bugs/1751291
<https://bugs.launchpad.net/bugs/1751291> - networking related fixes,
eghttps://bugs.launchpad.net/bugs/1733266
<https://bugs.launchpad.net/bugs/1733266>https://bugs.launchpad.net/bugs/1764735
<https://bugs.launchpad.net/bugs/1764735>https://bugs.launchpad.net/bugs/1771120
<https://bugs.launchpad.net/bugs/1771120> - juju resolve fix /
improvementadd support for --all https://bugs.launchpad.net/bugs/1755141
<https://bugs.launchpad.net/bugs/1755141>--no-retry behaviour is inverted
https://bugs.launchpad.net/bugs/1762979
<https://bugs.launchpad.net/bugs/1762979> - support for st1 and sc1 volume
types on AWShttps://bugs.launchpad.net/bugs/1753593
<https://bugs.launchpad.net/bugs/1753593> - support for new AWS instance
typeshttps://bugs.launchpad.net/bugs/1754735
<https://bugs.launchpad.net/bugs/1754735>*
The best way to get your hands on this release of Juju is to install it as a
snap package
              snap install juju --classic

Other packages are available for a variety of platforms. Please see the
online
documentation at https://jujucharms.com/docs/stable/reference-install. Those
subscribed to a snap channel should be automatically upgraded. If you’re
using
the ppa/homebrew, you should see an upgrade available.

## Feedback Appreciated!

We encourage everyone to let us know how you're using Juju. Send us a
message on Twitter using #jujucharms, join us at #juju on freenode, and
subscribe to the mailing list at juju at lists.ubuntu.com.

## More information

To learn more about Juju please visit https://jujucharms.com.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.ubuntu.com/archives/juju/attachments/20180703/edfb4592/attachment.html>