Juju devel 1.21-alpha1 is released
curtis at canonical.com
Wed Sep 17 20:04:47 UTC 2014
A new development release of Juju, juju-core 1.21-alpha1, is now available.
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.
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:
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
* 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
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' 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
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:
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:
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":
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.
* Maas provider assumes machine uses dhcp for eth0
* Relation-get with invalid relation name panics agent
* We should remove direct db access for clients
* Allow specifying a key when doing manual provisioning
* Juju doesn't use maas' knowledge of system architecture when picking
* Juju add-machine still assumes precise (maas)
* Local provider is very slow to tranistion from agent-status: pending
* Juju should wrap apt-get invocations with eatmydata when
provisioning cloud instances
* Juju 1.21-alpha1 local provider does not create all-machines.log
* Cloudinit does not use ssh client
* Provisioner-safe-mode is undocumented
* Networker restarts every 3 seconds with the local provider (missing
* Describe harvesting strategy rather than using "safe mode" name
* Configstore: if the size of the serialised jenv decreases the .jenv
file will be corrupt
* Juju-core client panics with juju set empty string
* Juju ignores environments.yaml on failed bootstrap if $provider.jenv
* Saved addresses should omit link-local addresses
* Add-machine containers should default to latest lts
* Blobstore's hashing needs improvement
* --keep-broken option still allows instance to be stopped
* Removing a unit on an unclean machine should remove that machine
* Juju log files should not be world readable
* Juju uses hard-coded regions
* Cmd/juju: deploy --to a non existent machine fails too late in the
* Cmd/juju: add-machine should take a -n param
* Missing @ syntax for reading config setting from file content
* Container provisioner may choose bad tools
* Juju set help is written but not shown
We encourage everyone to subscribe the mailing list at
juju-dev at lists.canonical.com, or join us on #juju-dev on freenode.
Canonical Cloud Development and Operations
More information about the Juju