Chris Lee
2017-11-02 04:56:44 UTC
A new development release of Juju is here, 2.3-beta2.
## New and Improved
* Deploying bundles now supports --dry-run
With --dry-run, no changes are made to the model, but what would be done is
output. The new machine numbers and unit numbers take into account the
current model. The --dry-run flag can also be used to apply changes made to
a bundle since it had been deployed.
* Deploying bundles can now target existing machines
When deploying bundles, machines specified in the bundle are added to the
model as new machines. In order to use the existing machines in the model
rather than create new machines, the --use-existing-machines flag can be
used. To specify a particular machine, the --bundle-machine flag can be
used to specify a specific machine for a particular machine in the bundle.
These flags can be combined with the --bundle-machine flag taking
precidence. For example, if there was a bundle that specified machines 1,
2, and 3, and the model had machines 1, 2, 3 and 4, the following
deployment of the bundle would use machines 1 and 2 in the model for
machines 1 and 2 in the bundle and use machine 4 in the model for the
bundle machine 3.
juju deploy some-bundle --use-existing-machines --bundle-machine 3=4
* OpenStack Cinder storage provider now supports âvolume-typeâ
https://bugs.launchpad.net/juju/+bug/1719323
The âcinderâ storage provider now supports a âvolume-typeâ pool
configuration. You can create a pool using âjuju create-storage-poolâ,
specifying the name of an OpenStack Cinder volume type.
* Cross model relations now supports nagios in its own [controller:]model
The nagios and nrpe charms are updated to be cross model relations aware.
This means they work in either a single model or cross model scenario. For
now, the charms are available at cs:~wallyworld but will be published to
the store soon.
juju bootstrap aws
juju switch controller
juju deploy cs:~wallyworld/nagios
juju expose nagios
juju offer nagios:monitors
juju switch default
juju deploy ubuntu
juju deploy cs:~wallyworld/nrpe
juju add-relation ubuntu nrpe
juju add-relation nrpe:monitors controller.nagios
- get the public IP of nagios and load it in the browser
- username is nagiosadmin
- password can be found by this command on the nagios model:
juju ssh nagios/0 sudo cat /var/lib/juju/nagios.passwd
* open_port and close_port hook tools now support ICMP
The open_port and close_port hook tools now support opening firewall access
for ICMP. The syntax is:
open_port icmp
This was needed for the (new) nrpe charm when used in a cross model
scenario, so that the remote nagios application could access the nrpe
subordinate in another model.
The necessary charm helpers change has not yet landed upstream - it is for
now just contained in the cs:~wallyworld/nrpe charm. But the Juju support
is there so charms can shell out to call open_port directly if needed,
until charm helpers is updated.
* Cross model relations now supports prometheus in its own
[controller:]model
The prometheus and telegraf charms are updated to be cross model aware.
This means they work in either a single model or cross model scenario. For
now, the charms are available at cs:~rharding but will be published to the
store soon.
juju bootstrap google bigbrother
juju bootstrap aws monitorme
juju switch bigbrother
juju deploy cs:~rharding/prometheus-0
juju expose prometheus
juju offer prometheus:target offerprom
juju switch monitorme
juju deploy ubuntu
juju deploy cs:~rharding/telegraf-0
juju relate ubuntu:juju-info telegraf
juju consume bigbrother:/admin/default.offerprom promed
juju relate telegraf:prometheus-client promed:target
juju switch bigbrother
juju show-machine 0
- get the public IP of prometheus and load it in the browser <ip>:9090
- open the status->targets list and make sure you see the CMR with the
public IP address of the telegraf unit in AWS
* Cross model relations over private networks
The algorithm used to select the ingress address to advertise across a
cross model relation is tweaked to better support the case where both
applications are on a private subnet.
If the offered endpoint is bound to a space, select an ingress address in
that space.
If the offered endpoint is not bound to a space, attempt to select a public
address on the machine, and fallback to a cloud local address if necessary.
The deployer of the application being offered thus gets to decide how they
want the offer to be accessed when they deploy the application. Not all
scenarios are covered since they are not yet modelled, eg bind to a private
subnet but access over a (public) shadow address. But what is supported
should cover many of the use cases people encounter.
* Autoconfiguration of FAN networking for EC2 and GCE providers
When creating a model in a VPC environment on EC2 or on GCE FAN settings
(model-config fan-config and container-networking-method) will be
autoconfigured, and container networking will work out-of-the-box.
* Parallelization of the Machine Provisioner
Provisioning of machines is now faster! Groups of machines will now be
provisioned in parallel reducing deployment time, especially on large
bundles. Please give it a try and let us know what you think.
Benchmarks for time to deploy 16 machines on different clouds:
AWS:
juju 2.2.5 4m36s
juju 2.3-beta2 3m17s
LXD:
juju 2.2.5 3m57s
juju 2.3-beta2 2m57s
Google:
juju 2.2.5 5m21s
juju 2.3-beta2 2m10s
OpenStack:
juju 2.2.5 12m40s
juju 2.3-beta2 4m52s
## Known Issues
When deploying a cross model scenario from a script, where both the
offering and consuming models are being set up, it's possible that the
cross model relation is established before any public IP address has been
assigned to the machine hosting the offer. This causes the cloud local
address to be advertised for ingress instead. The workaround is to wait for
the offered application to be active before relating to the consuming
application.
## Fixes
For a list of all bugs fixed in this release, see
https://launchpad.net/juju/+milestone/2.3-beta2
Some important fixes include:
* Leadership is no longer affected by clock skews.
https://bugs.launchpad.net/juju/+bug/1706340
Previously, system clock jumps could cause the âlease managerâ worker to
fail, which could prevent other parts of Juju and/or charm leadership from
working correctly. The lease manager has been improved so that it is no
longer affected by clock jumps.
## 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
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.
## New and Improved
* Deploying bundles now supports --dry-run
With --dry-run, no changes are made to the model, but what would be done is
output. The new machine numbers and unit numbers take into account the
current model. The --dry-run flag can also be used to apply changes made to
a bundle since it had been deployed.
* Deploying bundles can now target existing machines
When deploying bundles, machines specified in the bundle are added to the
model as new machines. In order to use the existing machines in the model
rather than create new machines, the --use-existing-machines flag can be
used. To specify a particular machine, the --bundle-machine flag can be
used to specify a specific machine for a particular machine in the bundle.
These flags can be combined with the --bundle-machine flag taking
precidence. For example, if there was a bundle that specified machines 1,
2, and 3, and the model had machines 1, 2, 3 and 4, the following
deployment of the bundle would use machines 1 and 2 in the model for
machines 1 and 2 in the bundle and use machine 4 in the model for the
bundle machine 3.
juju deploy some-bundle --use-existing-machines --bundle-machine 3=4
* OpenStack Cinder storage provider now supports âvolume-typeâ
https://bugs.launchpad.net/juju/+bug/1719323
The âcinderâ storage provider now supports a âvolume-typeâ pool
configuration. You can create a pool using âjuju create-storage-poolâ,
specifying the name of an OpenStack Cinder volume type.
* Cross model relations now supports nagios in its own [controller:]model
The nagios and nrpe charms are updated to be cross model relations aware.
This means they work in either a single model or cross model scenario. For
now, the charms are available at cs:~wallyworld but will be published to
the store soon.
juju bootstrap aws
juju switch controller
juju deploy cs:~wallyworld/nagios
juju expose nagios
juju offer nagios:monitors
juju switch default
juju deploy ubuntu
juju deploy cs:~wallyworld/nrpe
juju add-relation ubuntu nrpe
juju add-relation nrpe:monitors controller.nagios
- get the public IP of nagios and load it in the browser
- username is nagiosadmin
- password can be found by this command on the nagios model:
juju ssh nagios/0 sudo cat /var/lib/juju/nagios.passwd
* open_port and close_port hook tools now support ICMP
The open_port and close_port hook tools now support opening firewall access
for ICMP. The syntax is:
open_port icmp
This was needed for the (new) nrpe charm when used in a cross model
scenario, so that the remote nagios application could access the nrpe
subordinate in another model.
The necessary charm helpers change has not yet landed upstream - it is for
now just contained in the cs:~wallyworld/nrpe charm. But the Juju support
is there so charms can shell out to call open_port directly if needed,
until charm helpers is updated.
* Cross model relations now supports prometheus in its own
[controller:]model
The prometheus and telegraf charms are updated to be cross model aware.
This means they work in either a single model or cross model scenario. For
now, the charms are available at cs:~rharding but will be published to the
store soon.
juju bootstrap google bigbrother
juju bootstrap aws monitorme
juju switch bigbrother
juju deploy cs:~rharding/prometheus-0
juju expose prometheus
juju offer prometheus:target offerprom
juju switch monitorme
juju deploy ubuntu
juju deploy cs:~rharding/telegraf-0
juju relate ubuntu:juju-info telegraf
juju consume bigbrother:/admin/default.offerprom promed
juju relate telegraf:prometheus-client promed:target
juju switch bigbrother
juju show-machine 0
- get the public IP of prometheus and load it in the browser <ip>:9090
- open the status->targets list and make sure you see the CMR with the
public IP address of the telegraf unit in AWS
* Cross model relations over private networks
The algorithm used to select the ingress address to advertise across a
cross model relation is tweaked to better support the case where both
applications are on a private subnet.
If the offered endpoint is bound to a space, select an ingress address in
that space.
If the offered endpoint is not bound to a space, attempt to select a public
address on the machine, and fallback to a cloud local address if necessary.
The deployer of the application being offered thus gets to decide how they
want the offer to be accessed when they deploy the application. Not all
scenarios are covered since they are not yet modelled, eg bind to a private
subnet but access over a (public) shadow address. But what is supported
should cover many of the use cases people encounter.
* Autoconfiguration of FAN networking for EC2 and GCE providers
When creating a model in a VPC environment on EC2 or on GCE FAN settings
(model-config fan-config and container-networking-method) will be
autoconfigured, and container networking will work out-of-the-box.
* Parallelization of the Machine Provisioner
Provisioning of machines is now faster! Groups of machines will now be
provisioned in parallel reducing deployment time, especially on large
bundles. Please give it a try and let us know what you think.
Benchmarks for time to deploy 16 machines on different clouds:
AWS:
juju 2.2.5 4m36s
juju 2.3-beta2 3m17s
LXD:
juju 2.2.5 3m57s
juju 2.3-beta2 2m57s
Google:
juju 2.2.5 5m21s
juju 2.3-beta2 2m10s
OpenStack:
juju 2.2.5 12m40s
juju 2.3-beta2 4m52s
## Known Issues
When deploying a cross model scenario from a script, where both the
offering and consuming models are being set up, it's possible that the
cross model relation is established before any public IP address has been
assigned to the machine hosting the offer. This causes the cloud local
address to be advertised for ingress instead. The workaround is to wait for
the offered application to be active before relating to the consuming
application.
## Fixes
For a list of all bugs fixed in this release, see
https://launchpad.net/juju/+milestone/2.3-beta2
Some important fixes include:
* Leadership is no longer affected by clock skews.
https://bugs.launchpad.net/juju/+bug/1706340
Previously, system clock jumps could cause the âlease managerâ worker to
fail, which could prevent other parts of Juju and/or charm leadership from
working correctly. The lease manager has been improved so that it is no
longer affected by clock jumps.
## 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
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.