<div dir="ltr">Good stuff, well done team!</div><div class="gmail_extra"> <div class="gmail_quote">On Thu, Jul 3, 2014 at 12:11 PM, Curtis Hovey-Canonical <<a href="mailto:curtis@canonical.com" target="_blank">curtis@canonical.com</a>> wrote: <blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">juju-core 1.20.0 A new stable release of Juju, juju-core 1.20.0, is now available. Getting Juju juju-core 1.20.0 is available for utopic and backported to earlier series in the following PPA: <a href="https://launchpad.net/~juju/+archive/stable" target="_blank">https://launchpad.net/~juju/+archive/stable</a> New and Notable * High Availability * Availability Zone Placement * Azure Availability Sets * Juju debug-log Command Supports Filtering and Works with LXC * Constraints Support instance-type * The lxc-use-clone Option Makes LXC Faster for Non-Local Providers * Support for Multiple NICs with the Same MAC * MaaS Network Constraints and Deploy Argument * MAAS Provider Supports Placement and add-machine * Server-Side API Versioning Resolved issues * Juju client is not using the floating ip to connect to the state server Lp 1308767 * Juju help promotes the 'wrong' versions of commands Lp 1299120 * Juju backup command fails against trusty bootstrap node Lp 1305780 * The root-disk constraint is broken on ec2 Lp 1324729 * Bootstrapping juju from within a juju deployed unit fails Lp 1285256 * Images are not found if endpoint and region are inherited from the top level in simplestreams metadata Lp 1329805 * Missing @ syntax for reading config setting from file content Lp 1216967 * Deploy --config assumes relative path if it starts with a tilde (~) Lp 1271819 * local charm deployment fails with symlinks Lp 1330919 * Git usage can trigger disk space/memory issues for charms with blobs Lp 1232304 * Juju upgrade-charm fails because of git Lp 1297559 * .pyc files caused upgrade-charm to fail with merge conflicts Lp 1191028 * Juju debug-hooks should display a start message Lp 1270856 * Can't determine which relation is in error from status Lp 1194481 * Dying units departure is reported late Lp 1192433 * Juju upgrade-juju needs a dry run mode Lp 1272544 * Restarting API server with lots of agents gets hung Lp 1290843 * Juju destroy-environment >=256 nodes fails Lp 1316272 * Azure destroy-environment does not complete Lp 1324910 * Azure bootstrap dies with xml schema validation error Lp 1259947 * Azure provider stat output does not show machine hardware info Lp 1215177 * Bootstrapping azure causes memory to fill Lp 1250007 * Juju destroy-environment on openstack should remove sec groups Lp 1227574 * Floating IPs are not recycled in OpenStack Havana Lp 1247500 * LXC cloning should be default behaviour Lp 1318485 * Nasty worrying output using local provider Lp 1304132 * Intermittent error destroying local provider environments Lp 1307290 * Default bootstrap timeout is too low for MAAS environments Lp 1314665 * MAAS provider cannot provision named instance Lp 1237709 * Manual provisioning requires target hostname to be directly resolvable Lp 1300264 * Manual provider specify bash as shell for ubuntu user Lp 1303195 High Availability The juju state-server (bootstrap node) can be placed into high availability mode. Juju will automatically recover when one or more the state-servers fail. You can use the 'ensure-availability' command to create the additional state-servers: juju ensure-availability The 'ensure-availability' command creates 3 state servers by default, but you may use the '-n' option to specify a larger number. The number of state servers must be odd. The command supports the 'series' and 'constraints' options like the 'bootstrap' command. You can learn more details by running 'juju ensure-availability --help' Availability Zone Placement Juju supports explicit placement of machines to availability zones (AZs), and implicitly spreads units across the available zones. When bootstrapping or adding a machine, you can specify the availability zone explicitly as a placement directive. e.g. juju bootstrap --to zone=us-east-1b juju add-machine zone=us-east-1c If you don't specify a zone explicitly, Juju will automatically and uniformly distribute units across the available zones within the region. Assuming the charm and the charm's service are well written, you can rest assured that IaaS downtime will not affect your application. Commands you already use will ensure your services are always available. e.g. juju deploy -n 10 <service> When adding machines without an AZ explicitly specified, or when adding units to a service, the ec2 and openstack providers will now automatically spread instances across all available AZs in the region. The spread is based on density of instance "distribution groups". State servers compose a distribution group: when running 'juju ensure-availability', state servers will be spread across AZs. Each deployed service (e.g. mysql, redis, whatever) composes a separate distribution group; the AZ spread of one service does not affect the AZ spread of another service. Amazon's EC2 and OpenStack Havana-based clouds and newer are supported. This includes HP Cloud. Older versions of OpenStack are not supported. Azure availability sets Azure environments can be configured to use availability sets. This feature ensures services are distributed for high availability; as long as at least two units are deployed, Azure guarantees 99.95% availability of the service overall. Exposed ports will be automatically load balanced across all units within the service. New Azure environments will have support for availability sets by default. To revert to the previous behaviour, the 'availability-sets-enabled' option must be set in environments.yaml like so: availability-sets-enabled: false Placement is disabled when 'availability-sets-enabled' is true. The option cannot be disabled after the environment is bootstrapped. Juju debug-log Command Supports Filtering and Works with LXC The 'debug-log' command shows the consolidate logs of all juju agents running on all machines in the environment. The command operates like 'tail -f' to stream the logs to the your terminal. The feature now support local-provider LXC environments. Several options are available to select which log lines to display. The 'lines' and 'limit' options allow you to select the starting log line and how many additional lines to display. The default behaviour is to show the last 10 lines of the log. The 'lines' option selects the starting line from the end of the log. The 'limit' option restricts the number of lines to show. For example, you can see just 20 lines from last 100 lines of the log like this: juju debug-log --lines 100 --limit 20 There are many ways to filter the juju log to see just the pertinent information. A juju log line is written in this format: <entity> <timestamp> <log-level> <module>:<line-no> <message> The 'include' and 'exclude' options select the entity that logged the message. An entity is a juju machine or unit agent. The entity names are similar to the names shown by 'juju status'. You can exclude all the log messages from the bootstrap machine that hosts the state-server like this: juju debug-log --exclude machine-0 The options can be used multiple times to select the log messages. This example selects all the message from a unit and its machine as reported by status: juju debug-log --include unit-mysql-0 --include machine-1 The 'level' option restricts messages to the specified log-level or greater. The levels from lowest to highest are TRACE, DEBUG, INFO, WARNING, and ERROR. The WARNING and ERROR messages from the log can seen thusly: juju debug-log --level WARNING The 'include-module' and 'exclude-module' are used to select the kind of message displayed. The module name is dotted. You can specify all or some of a module name to include or exclude messages from the log. This example progressively excludes more content from the logs juju debug-log --exclude-module juju.state.apiserver juju debug-log --exclude-module juju.state juju debug-log --exclude-module juju The 'include-module' and 'exclude-module' options can be used multiple times to select the modules you are interested in. For example, you can see the juju.cmd and juju.worker messages like this: juju debug-log --include-module juju.cmd --include-module juju.worker The 'debug-log' command output can be piped to grep to filter the message like this: juju debug-log --lines 500 | grep amd64 You can learn more by running 'juju debug-log --help' and 'juju help logging' Constraints Support instance-type You can specify 'instance-type' with the 'constraints' option to select a specific image defined by the cloud provider. The 'instance-type' constraint can be used with Azure, EC2, HP Cloud, and all OpenStack-based clouds. For example, when creating an EC2 environment, you can specify 'm1.small': juju bootstrap --constraints instance-type=m1.small Constraints are validated by all providers to ensure values conflicts and unsupported options are rejected. Previously, juju would reconcile such problems and select an image, possibly one that didn't meet the needs of the service. The lxc-use-clone Option Makes LXC Faster for Non-Local Providers When 'lxc-use-clone' is set to true, the LXC provisioner will be configured to use cloning regardless of provider type. This option cannot be changed once it is set. You can set the option to true in environments.yaml like this: lxc-use-clone: true This speeds up LXC provisioning when using placement with any provider. For example, deploying mysql to a new LXC container on machine 0 will start faster: juju deploy --to lxc:0 mysql Support for Multiple NICs with the Same MAC Juju now supports multiple physical and virtual network interfaces with the same MAC address on the same machine. Juju takes care of this automatically, there is nothing you need to do. Caution, network settings are not upgraded from 1.18.x to 1.20.x. If you used juju 1.18.x to deploy an environment with specified networks, you must redeploy your environment instead of upgrading to 1.20.0. The output of 'juju status' will include information about networks when there is more than one. The networks will be presented in this manner: machines: ... services: ... networks: net1: provider-id: foo cidr: <a href="http://0.1.2.0/24" target="_blank">0.1.2.0/24</a> vlan-tag: 42 MaaS Network Constraints and Deploy Argument You can specify which networks to include or exclude as a constraint to the deploy command. The constraint is used to select a machine to deploy the service's units too. The value of 'networks' is a comma-delimited list of juju network names (provided by MaaS). Excluded networks are prefixed with a "^". For example, this command specify the service requires the "logging" and "storage" networks and conflicts with the "db" and "dmz" networks. juju deploy mongodb --constraints networks=logging,storage,^db,^dmz The network constraint does not enable the network for the service. It only defines what machine to pick. Use the 'deploy' command's 'networks' option to specify service-specific network requirements. The 'networks' option takes a comma-delimited list of juju-specific network names. Juju will enable the networks on the machines that host service units. Juju networking support is still experimental and under development, currently only supported with the MaaS provider. juju deploy mongodb --networks=logging,storage The 'exclude-network' option was removed from the deploy command as it is superseded by the constraint option. There are plans to add support for network constraint and argument with Amazon EC2, Azure, and OpenStack Havana-based clouds like HP Cloud in the future. MAAS Provider Supports Placement and add-machine You can specify which MAAS host to place the juju state-server on with the 'to' option. To bootstrap on a host named 'fnord', run this: juju bootstrap --to fnord The MAAS provider support the add-machine command now. You can provision an existing host in the MAAS-based Juju environment. For example, you can add running machine named fnord like this: juju add-machine fnord Server Side API Versioning The Juju API server now has support for a Version field in requests that are made. For this release, there are no RPC calls that require anything other than 'version=0' which is the default when no Version is supplied. This should have limited impact on existing CLI or API users, since it allows us to maintain exact compatibility with existing requests. New features and APIs should be exposed under versioned requests. For details on the internals (for people writing API clients), see: <a href="https://docs.google.com/document/d/1fPOSUu7Dc_23pil1HGNTSpdFRhkMHGxe4o6jBghZZ1A/edit?usp=sharing" target="_blank">https://docs.google.com/document/d/1fPOSUu7Dc_23pil1HGNTSpdFRhkMHGxe4o6jBghZZ1A/edit?usp=sharing</a> Finally We encourage everyone to subscribe the mailing list at <a href="mailto:juju-dev@lists.canonical.com">juju-dev@lists.canonical.com</a>, or join us on #juju-dev on freenode. PS. Juju just got 20% more amazing. -- Curtis Hovey Canonical Cloud Development and Operations <a href="http://launchpad.net/~sinzui" target="_blank">http://launchpad.net/~sinzui</a> -- Juju-dev mailing list <a href="mailto:Juju-dev@lists.ubuntu.com">Juju-dev@lists.ubuntu.com</a> Modify settings or unsubscribe at: <a href="https://lists.ubuntu.com/mailman/listinfo/juju-dev" target="_blank">https://lists.ubuntu.com/mailman/listinfo/juju-dev</a> </blockquote></div> <div> </div>-- <div dir="ltr">Alexis Bruemmer<div>Juju Core Manager, Canonical Ltd.</div><div>(503) 686-5018</div><div><a href="mailto:alexis.bruemmer@canonical.com" target="_blank">alexis.bruemmer@canonical.com</a></div> </div> </div>