Juju devel 1.21-alpha1 is released

Curtis Hovey-Canonical curtis at canonical.com
Wed Sep 17 20:04:47 UTC 2014

juju-core 1.21-alpha1

A new development release of Juju, juju-core 1.21-alpha1, is now available.

Getting Juju

juju-core 1.21-alpha1 is available for utopic and backported to earlier
series in the following PPA:


The devel packages in this archive use the devel simple-streams.
You must configure the 'tools-metadata-url' option in your
environments.yaml to use the matching juju tools.

    tools-metadata-url: https://streams.canonical.com/juju/devel/tools

This ensures a clean separation between the stable tools and the devel
tools. Production environments based on stable juju cannot accidentally
upgrade to a devel release even when the --version option is passed to
the 'upgrade-juju' command. The 'tools-metadata-url' option must be set
to clearly state the environment is for evaluating development versions.

Upgrading from stable releases to development releases is not
supported. You can upgrade test environments to development releases
to test new features and fixes, but it is not advised to upgrade
production environments to 1.21-alpha1. You can switch your testing
environment to use the devel streams like so:

    juju set-env

This change may take hours to propagate. You can upgrade when the devel url
is shown to be in the env.

     juju get-env tools-metadata-url

Notable Changes

* Harvest Modes

* Disabling apt-get update/upgrade for faster provisioning

* Using daily image streams for faster provisioning

* Add many machines

* Setting the MAAS network rules

* Performing autopsies on failed bootstraps

Harvest Modes

Juju keeps a model of what it thinks the environment looks like, and
based on that model, can harvest machines which it deems are no longer
required. This can help keep your costs low, and keep you out of web
consoles. Juju supports several harvesting modes to suit your needs.

that Juju knows about. Unknown instances will not be harvested. This
is the default mode.

Destroyed: Juju will harvest only machine instances that are dead, and

Unknown: Juju will harvest only instances that Juju doesn't know about.

All: Juju will terminate all instances – destroyed or unknown – that it
finds. This is a good option if you are only utilizing Juju for your

None: Juju won't harvest any machines. This is the most conservative
mode, and a good choice if you manage your machines utilizing a separate
process outside of Juju.

Juju's harvesting behaviour is set through the environments.yaml file.

    provisioner-harvest-mode: <MODE>

'provisioner-harvest-mode' replaces 'safe-mode'. Environments with
'safe-mode' set will be converted to 'provisioner-harvest-mode' when

Disabling apt-get update/upgrade for faster provisioning

When juju provisions a machine, its default behaviour is to update the
list of available packages and upgrade the existing packages to the
latest version. If your OS images are fresh or the services you deploy
don't require updated packages, you can disable updates and upgrades to
provision the machine faster.

Two configuration options are available to disable apt updates and
upgrades. When your OS images are fresh, you can set both
'enable-os-refresh-update', and 'enable-os-upgrade' to false. When you
know that some charms want the latest packages to to setup services, you
will want to keep 'enable-os-refresh-update' set to "true"

You can configure the options in environments.yaml for fast provision
like so

    enable-os-upgrade: false
    enable-os-refresh-update: false

Using daily image streams for faster provisioning

Juju prefers to use the well slow changing "released" images when
provisioning machines. The 'image-stream' option in environments.yaml
can be set to "daily" use more up-to-date images, thus shortening the
time it takes to perform apt-get update/upgrade. While this feature has
existed since 1.18.0, it was not applied consistently KVM containers.
KVM containers will now use "daily" when environments.yaml is set to:

    image-stream: daily

Add many machines

Juju's 'add-machine' command now accepts the '-n' option to add many
machines. For example, to add two machines:

    juju add-machine -n 2

The '-n' option can be combined with placement. You can add to lxc
containers to machine 1 thusly

     juju add-machine lxc:1 -n 2

Setting the MAAS network rules

The default network bridge is eth0. MAAS environments can specify a
different interface using the network-bridge options. For bridge can
be set to eth2 in environments.yaml like so:

    network-bridge: eth2

Juju and MAAS cannot both be in control of the network. When MAAS
is managing the bridge and bringing networks up and down, set the
'disable-network-management' option in environments.yaml to "true":

    disable-network-management: true

This tells Juju not to create a network bridge or bringing eth0
up and down during cloudinit. Juju will not make changes to the
network config when its agents start.

Performing autopsies on failed bootstraps

The juju 'bootstrap' command has a new option for testers and anyone
examining why a bootstrap failed. Use the '--keep-broken' option to
keep the machine up. You can then use ssh to gather logs and
investigate the cause of the failure.

Resolved issues

* Maas provider assumes machine uses dhcp for eth0
  Lp 1361374

* Relation-get with invalid relation name panics agent
  Lp 1365412

* We should remove direct db access for clients
  Lp 1253652

* Allow specifying a key when doing manual provisioning
  Lp 1270466

* Juju doesn't use maas' knowledge of system architecture when picking
  Lp 1303853

* Juju add-machine still assumes precise (maas)
  Lp 1315473

* Local provider is very slow to tranistion from agent-status: pending
  Lp 1322302

* Juju should wrap apt-get invocations with eatmydata when
  provisioning cloud instances
  Lp 1335822

* Juju 1.21-alpha1 local provider does not create all-machines.log
  Lp 1339715

* Cloudinit does not use ssh client
  Lp 1339976

* Provisioner-safe-mode is undocumented
  Lp 1342729

* Networker restarts every 3 seconds with the local provider (missing
  Lp 1343219

* Describe harvesting strategy rather than using "safe mode" name
  Lp 1345553

* Configstore: if the size of the serialised jenv decreases the .jenv
  file will be corrupt
  Lp 1348458

* Juju-core client panics with juju set empty string
  Lp 1348829

* Juju ignores environments.yaml on failed bootstrap if $provider.jenv
  Lp 1361680

* Saved addresses should omit link-local addresses
  Lp 1362453

* Add-machine containers should default to latest lts
  Lp 1363971

* Blobstore's hashing needs improvement
  Lp 1364750

* --keep-broken option still allows instance to be stopped
  Lp 1365772

* Removing a unit on an unclean machine should remove that machine
  Lp 1206532

* Juju log files should not be world readable
  Lp 1286518

* Juju uses hard-coded regions
  Lp 1319474

* Cmd/juju: deploy --to a non existent machine fails too late in the
  Lp 1212538

* Cmd/juju: add-machine should take a -n param
  Lp 1214209

* Missing @ syntax for reading config setting from file content
  Lp 1216967

* Container provisioner may choose bad tools
  Lp 1347984

* Juju set help is written but not shown
  Lp 1359187


We encourage everyone to subscribe the mailing list at
juju-dev at lists.canonical.com, or join us on #juju-dev on freenode.

Curtis Hovey
Canonical Cloud Development and Operations

More information about the Juju mailing list