juju 1.22.0 is proposed for release

2015-03-12 Thread Curtis Hovey-Canonical
# juju-core 1.22.0

A new proposed stable release of Juju, juju-core 1.22.0, is now available.
This release may replace 1.21.3 on Thursday March 19, 2015.


## Getting Juju

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

https://launchpad.net/~juju/+archive/proposed

The proposed packages in this archive use the proposed simple-streams.
You must configure the 'agent-stream' option in your
environments.yaml to use the matching juju agents.

agent-stream: proposed


## Notable Changes

  * Blocking changes to the environment
  * LXC image caching and the cached-images command
  * Juju state backup improvements
  * Static internal route for Joyent instances
  * The instance availability zone is exposed to charms
  * Relaxed checked for container scoped relations
  * New annotations client includes charms and bulk calls
  * Upgrade robustness
  * Multi-environment infrastructure


### Blocking changes to the environment

The 'block' and 'unblock' commands control which changes can be made to
a running environment. Use the 'block' command to lockdown the
environment to prevent accidental changes. Three levels of restrictions
can be applied, 'destroy-environment', 'remove-object', and
'all-changes'.

The 'destroy-environment' level blocks just the 'destroy-environment'
command. You can prevent an environment from being destroyed like this:

juju block destroy-environment

The 'remove-object' level blocks the 'destroy-environment',
'remove-machine', 'remove-relation', 'remove-service', and 'remove-unit'
commands from being run. You can prevent the machines, services, units
and relations from being removed thusly:

juju block remove-object

The 'all-changes' level blocks commands that add, alter, or remove
things in the running environment. These commands are blocked:
'add-machine', 'add-relation', 'add-unit', 'authorised-keys add',
'authorised-keys delete', 'authorised-keys import', 'deploy',
'destroy-environment', 'ensure-availability', 'expose', 'resolved',
'remove-machine', 'remove-relation', 'remove-service', 'remove-unit',
'retry-provisioning', 'run', 'set', 'set-constraints', 'set-env',
'unexpose', 'unset', 'unset-env', 'upgrade-charm', 'upgrade-juju',
'user add', 'user change-password', 'user disable', and 'user enable'
You can lockdown the environment to prevent all changes like this:

juju block all-changes

When a command is blocked, and you are certain you need to alter the
environment, you can remove the block using the 'unblock' command. For
example, to permit the remove-relation command blocked by the
'remove-object' level, run:

juju unblock remove-object

You can restore the block after you complete your changes.

Note that some commands have a '--force' option bypasses the
restrictions set by 'block'. Only use the '--force' option *after* the
command was run without it to ensure you are aware of the restrictions
set on the environment by the 'block' command.

For more information run 'juju help block' and 'juju help unblock'.


### LXC image caching and the cached-images command

From Juju 1.22 onwards, LXC images are cached in the Juju environment
when they are retrieved to instantiate a new LXC container. This applies
to the local provider and all other cloud providers. This caching is
done independently of whether image cloning is enabled.

Note: Due to current upgrade limitations, image caching is currently not
available for machines upgraded to 1.22. Only machines deployed with
1.22 will cache the images.

In Juju 1.22, lxc-create is configured to fetch images from the Juju
state server. If no image is available, the state server will fetch the
image from http://cloud-images.ubuntu.com and then cache it. This means
that the retrieval of images from the external site is only done once
per *environment*, not once per new machine which is the default
behaviour of lxc. The next time lxc-create needs to fetch an image, it
comes directly from the Juju environment cache.

The 'cached-images' command can list and delete cached LXC images stored
in the Juju environment. The 'list' and 'delete' subcommands support
'--arch' and '--series' options to filter the result.

To see all cached images, run:

juju cached-images list

Or to see just the amd64 trusty images run:

juju cached-images list --series trusty --arch amd64

To delete the amd64 trusty cached images run:

  juju cache-images delete --series trusty --arch amd64

Future development work will allow Juju to automatically download new
LXC images when they becomes available, but for now, the only way update
a cached image is to remove the old one from the Juju environment. Juju
will also support KVM image caching in the future.

See 'juju cached-images list --help' and 'juju cached-images delete
--help' for more details.


### Juju state backup improvements

The backup CLI plugin is replaced by the native 'backups' command. The
command can create, manage, and 

juju 1.22.0 is proposed for release

2015-03-12 Thread Curtis Hovey-Canonical
# juju-core 1.22.0

A new proposed stable release of Juju, juju-core 1.22.0, is now available.
This release may replace 1.21.3 on Thursday March 19, 2015.


## Getting Juju

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

https://launchpad.net/~juju/+archive/proposed

The proposed packages in this archive use the proposed simple-streams.
You must configure the 'agent-stream' option in your
environments.yaml to use the matching juju agents.

agent-stream: proposed


## Notable Changes

  * Blocking changes to the environment
  * LXC image caching and the cached-images command
  * Juju state backup improvements
  * Static internal route for Joyent instances
  * The instance availability zone is exposed to charms
  * Relaxed checked for container scoped relations
  * New annotations client includes charms and bulk calls
  * Upgrade robustness
  * Multi-environment infrastructure


### Blocking changes to the environment

The 'block' and 'unblock' commands control which changes can be made to
a running environment. Use the 'block' command to lockdown the
environment to prevent accidental changes. Three levels of restrictions
can be applied, 'destroy-environment', 'remove-object', and
'all-changes'.

The 'destroy-environment' level blocks just the 'destroy-environment'
command. You can prevent an environment from being destroyed like this:

juju block destroy-environment

The 'remove-object' level blocks the 'destroy-environment',
'remove-machine', 'remove-relation', 'remove-service', and 'remove-unit'
commands from being run. You can prevent the machines, services, units
and relations from being removed thusly:

juju block remove-object

The 'all-changes' level blocks commands that add, alter, or remove
things in the running environment. These commands are blocked:
'add-machine', 'add-relation', 'add-unit', 'authorised-keys add',
'authorised-keys delete', 'authorised-keys import', 'deploy',
'destroy-environment', 'ensure-availability', 'expose', 'resolved',
'remove-machine', 'remove-relation', 'remove-service', 'remove-unit',
'retry-provisioning', 'run', 'set', 'set-constraints', 'set-env',
'unexpose', 'unset', 'unset-env', 'upgrade-charm', 'upgrade-juju',
'user add', 'user change-password', 'user disable', and 'user enable'
You can lockdown the environment to prevent all changes like this:

juju block all-changes

When a command is blocked, and you are certain you need to alter the
environment, you can remove the block using the 'unblock' command. For
example, to permit the remove-relation command blocked by the
'remove-object' level, run:

juju unblock remove-object

You can restore the block after you complete your changes.

Note that some commands have a '--force' option bypasses the
restrictions set by 'block'. Only use the '--force' option *after* the
command was run without it to ensure you are aware of the restrictions
set on the environment by the 'block' command.

For more information run 'juju help block' and 'juju help unblock'.


### LXC image caching and the cached-images command

From Juju 1.22 onwards, LXC images are cached in the Juju environment
when they are retrieved to instantiate a new LXC container. This applies
to the local provider and all other cloud providers. This caching is
done independently of whether image cloning is enabled.

Note: Due to current upgrade limitations, image caching is currently not
available for machines upgraded to 1.22. Only machines deployed with
1.22 will cache the images.

In Juju 1.22, lxc-create is configured to fetch images from the Juju
state server. If no image is available, the state server will fetch the
image from http://cloud-images.ubuntu.com and then cache it. This means
that the retrieval of images from the external site is only done once
per *environment*, not once per new machine which is the default
behaviour of lxc. The next time lxc-create needs to fetch an image, it
comes directly from the Juju environment cache.

The 'cached-images' command can list and delete cached LXC images stored
in the Juju environment. The 'list' and 'delete' subcommands support
'--arch' and '--series' options to filter the result.

To see all cached images, run:

juju cached-images list

Or to see just the amd64 trusty images run:

juju cached-images list --series trusty --arch amd64

To delete the amd64 trusty cached images run:

  juju cache-images delete --series trusty --arch amd64

Future development work will allow Juju to automatically download new
LXC images when they becomes available, but for now, the only way update
a cached image is to remove the old one from the Juju environment. Juju
will also support KVM image caching in the future.

See 'juju cached-images list --help' and 'juju cached-images delete
--help' for more details.


### Juju state backup improvements

The backup CLI plugin is replaced by the native 'backups' command. The
command can create, manage, and