juju stable 1.20.0 is released

Thu Jul 3 20:11:14 UTC 2014

Good stuff, well done team!

On Thu, Jul 3, 2014 at 12:11 PM, Curtis Hovey-Canonical <
curtis at canonical.com> wrote:

> 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:
>
>     https://launchpad.net/~juju/+archive/stable
>
>
> 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: 0.1.2.0/24
>         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:
>
> https://docs.google.com/document/d/1fPOSUu7Dc_23pil1HGNTSpdFRhkMHGxe4o6jBghZZ1A/edit?usp=sharing
>
>
> Finally
>
> We encourage everyone to subscribe the mailing list at
> juju-dev at lists.canonical.com, or join us on #juju-dev on freenode.
>
> PS. Juju just got 20% more amazing.
>
>
> --
> Curtis Hovey
> Canonical Cloud Development and Operations
> http://launchpad.net/~sinzui
>
> --
> Juju-dev mailing list
> Juju-dev at lists.ubuntu.com
> Modify settings or unsubscribe at:
> https://lists.ubuntu.com/mailman/listinfo/juju-dev
>

-- 
Alexis Bruemmer
Juju Core Manager, Canonical Ltd.
(503) 686-5018
alexis.bruemmer at canonical.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.ubuntu.com/archives/juju/attachments/20140703/5c27201f/attachment.html>