Juju 2.3 beta2 is here!

Chris Lee chris.lee at canonical.com
Thu Nov 2 04:56:44 UTC 2017


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 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/20171102/fc903448/attachment.html>


More information about the Juju mailing list