Nicholas Skaggs
2018-04-19 15:57:45 UTC
A new development release of Juju is here, 2.4-beta1. Those wishing to
utilize bionic for controllers should target and plan to use the 2.4
series of juju.
## New and Improved
* Model owner changes
The concept of model owner is becoming obsolete. Model owner is just
another model user with administrative access. We are working to remove
any special access that the model owner has, and move to having the
models in a namespace rather than grouped by owner.
* Charm goal state
Charm goal state allows charms to discover relevant information about
their deployment. 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
status
Charms use a new goal-state hook command to query the information about
their deployment. This hook command will print only yaml or json output
(default yaml):
$ goal-state --format yaml
The 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 unitstatus values are the workload status of the (sibling) peer
units. We also use a unit status value of dyingwhen the unit's life
becomes dying. Thus unit status is one of:
*
allocating
*
active
*
waiting
*
blocked
*
error
*
dying
The relationstatus 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)
*
error
By 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.
* Controllers and remove-machine updates
*
It is now possible to `juju remove-machine` a controller machine. As
long as there is another controller, we will gracefully shut down
the existing machine, and remove it from the HA set (of mongo, raft,
and juju API servers).
*
It is also possible to `juju remove-machine --force` for those
conditions where the machine is not available to be gracefully
removed. Currently this is not guaranteed to remove the machine from
the Mongo replicaset, so it should be used only as a last resort.
*
There is also a known issue that trying to `juju remove-machine` the
machine that is currently the Mongo primary will not cleanup
properly. This should be addressed in the next 2.4 release.
*
In future 2.4 releases, we will also be updating `juju enable-ha` to
remove its logic around demoting machines. Instead, `juju enable-ha`
will only be a way to ensure that you have the correct number of
controller machines being started/intended to participate in HA.
This will also fix issues around launching 2 new machines (going to
5) while machines 2 and 3 are still starting.
* Controller configuration options for spaces
Two new controller configuration settings have been introduced. These are:
*
juju-mgmt-space
*
juju-ha-space
juju-mgmt-spaceis 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 addressesresults. Juju client
communication with controllers is unaffected by this value.
Juju-ha-spaceis 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 mustbe set where member machines in a 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 can not be satisfied.
* Cloud credential changes
Cloud 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 locallyon a
user’s client machine as well as the cloud credentials stored remotelyon
a bootstrapped Juju controller. The distinction has not been made clear
previously and this release addresses these ambiguities.
$ juju show-model ...
Basic cloud credential information such as its name and owner have been
added to the command output.
$ juju show-credential ...
This is a new command that shows a logged on user their remotely stored
cloud credentials along with models that use them.
See command help for more information.
## Fixes
For a list of all bugs fixed in this release, see
https://launchpad.net/juju/+milestone/2.4-beta1
Some important fixes include:
* juju resolve fix / improvement
add support for --all https://bugs.launchpad.net/bugs/1755141
--no-retry behaviour is inverted https://bugs.launchpad.net/bugs/1762979
* support for st1 and sc1 volume types on AWS
https://bugs.launchpad.net/bugs/1753593
* support for new AWS instance types
https://bugs.launchpad.net/bugs/1754735
## How can I get it?
The best way to get your hands on this release of Juju is to install it
as a snap package (see https://snapcraft.io/for more info on snaps).
snap install juju --classic --beta
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 ***@lists.ubuntu.com.
## More information
To learn more about juju please visit https://jujucharms.com.
utilize bionic for controllers should target and plan to use the 2.4
series of juju.
## New and Improved
* Model owner changes
The concept of model owner is becoming obsolete. Model owner is just
another model user with administrative access. We are working to remove
any special access that the model owner has, and move to having the
models in a namespace rather than grouped by owner.
* Charm goal state
Charm goal state allows charms to discover relevant information about
their deployment. 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
status
Charms use a new goal-state hook command to query the information about
their deployment. This hook command will print only yaml or json output
(default yaml):
$ goal-state --format yaml
The 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 unitstatus values are the workload status of the (sibling) peer
units. We also use a unit status value of dyingwhen the unit's life
becomes dying. Thus unit status is one of:
*
allocating
*
active
*
waiting
*
blocked
*
error
*
dying
The relationstatus 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)
*
error
By 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.
* Controllers and remove-machine updates
*
It is now possible to `juju remove-machine` a controller machine. As
long as there is another controller, we will gracefully shut down
the existing machine, and remove it from the HA set (of mongo, raft,
and juju API servers).
*
It is also possible to `juju remove-machine --force` for those
conditions where the machine is not available to be gracefully
removed. Currently this is not guaranteed to remove the machine from
the Mongo replicaset, so it should be used only as a last resort.
*
There is also a known issue that trying to `juju remove-machine` the
machine that is currently the Mongo primary will not cleanup
properly. This should be addressed in the next 2.4 release.
*
In future 2.4 releases, we will also be updating `juju enable-ha` to
remove its logic around demoting machines. Instead, `juju enable-ha`
will only be a way to ensure that you have the correct number of
controller machines being started/intended to participate in HA.
This will also fix issues around launching 2 new machines (going to
5) while machines 2 and 3 are still starting.
* Controller configuration options for spaces
Two new controller configuration settings have been introduced. These are:
*
juju-mgmt-space
*
juju-ha-space
juju-mgmt-spaceis 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 addressesresults. Juju client
communication with controllers is unaffected by this value.
Juju-ha-spaceis 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 mustbe set where member machines in a 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 can not be satisfied.
* Cloud credential changes
Cloud 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 locallyon a
user’s client machine as well as the cloud credentials stored remotelyon
a bootstrapped Juju controller. The distinction has not been made clear
previously and this release addresses these ambiguities.
$ juju show-model ...
Basic cloud credential information such as its name and owner have been
added to the command output.
$ juju show-credential ...
This is a new command that shows a logged on user their remotely stored
cloud credentials along with models that use them.
See command help for more information.
## Fixes
For a list of all bugs fixed in this release, see
https://launchpad.net/juju/+milestone/2.4-beta1
Some important fixes include:
* juju resolve fix / improvement
add support for --all https://bugs.launchpad.net/bugs/1755141
--no-retry behaviour is inverted https://bugs.launchpad.net/bugs/1762979
* support for st1 and sc1 volume types on AWS
https://bugs.launchpad.net/bugs/1753593
* support for new AWS instance types
https://bugs.launchpad.net/bugs/1754735
## How can I get it?
The best way to get your hands on this release of Juju is to install it
as a snap package (see https://snapcraft.io/for more info on snaps).
snap install juju --classic --beta
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 ***@lists.ubuntu.com.
## More information
To learn more about juju please visit https://jujucharms.com.
--
Juju-dev mailing list
Juju-***@lists.ubuntu.com
Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/
Juju-dev mailing list
Juju-***@lists.ubuntu.com
Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/