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 [email protected]. ## More information To learn more about juju please visit https://jujucharms.com.
-- Juju mailing list [email protected] Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/juju
