Juju 2.4.0 has been released

Tue Jul 3 11:10:35 UTC 2018

Thanks Vinodhin

I just installed juju from snap and wanted to test couple of deployments.

Should the controller version be 2.4.0 as well or are we keeping 2.3.7?

kowalczykb at hp1:~$ snap list
Name  Version    Rev   Tracking  Developer  Notes
core  16-2.33.1  4917  stable    canonical  core
juju  2.4.0      4587  stable    canonical  classic

kowalczykb at hp1:~$ juju status
Model    Controller  Cloud/Region         Version  SLA
default  super-bonkers        localhost/localhost  2.3.7    unsupported

App  Version  Status  Scale  Charm  Store  Rev  OS  Notes

Unit  Workload  Agent  Machine  Public address  Ports  Message

Machine  State  DNS  Inst id  Series  AZ  Message

Thanks
-- 
Kind Regards

Bogdan Kowalczyk
Technical Account Manager @ Canonical
Email: Bogdan.Kowalczyk at canonical.com

On 03/07/18 10:20, Vinodhini Balusamy wrote:
> *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.
> 
> 
> 