juju-core 1.15.1 is released

Sat Oct 5 05:48:04 UTC 2013

juju-core 1.15.1

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

Getting Juju

juju-core 1.15.1 is available from the Juju development PPA
https://launchpad.net/~juju/+archive/devel

New and Notable

* bootstrap now matches on major and minor version numbers when
  locating tools

* public-bucket-url is deprecated, use tools-url and/or
  image-metadata-url instead

* users running from source no longer need to manually specify
  --upload-tools in order to have tools available for bootstrapping

* tools retrieval is now handled using simplestreams metadata, similar
  to how image id lookup works

* tools no longer have to be located in a publicly readable cloud
  storage instance; they can be served by any HTTP server eg apache

* new constraint: tags. This constraint is currently only supported by
  MaaS environments, and allows you to specify nodes by tags applied to
  them in MaaS.  Example: juju deploy mysql --constraints tags=foo,bar
  will deploy mysql to a node that is tagged with both the “foo” tag and
  the "bar" tag.

* the “null” provider is now available, for creating environments with
  existing machines.

* admin-secret is now chosen automatically if omitted from the
  configuration of a new environment.

* control-bucket is now chosen automatically if omitted from the
  configuration for new ec2 and openstack environments.

* Logging has changed. You can specify an environment variable
  "JUJU_LOGGING_CONFIG", or you can specify --log-config on the command
  line. To show the log on the command line, now use --show-log.  The
  --debug has been kept to be short-hand for "--log-config=<root>=DEBUG
  --show-log", and --verbose has been deprecated with its current meaning.

Resolved issues

* "juju add-machine ssh:..." no longer fails when an IP address is
  specified instead of a hostname. LP #1225825

* Bootstrap nodes will now only run one copy of Mongodb, this will
  result in lower resource utilisation and faster startup of the bootstrap
  node. Closes LP #1210407

* EC2 accounts in default VPC mode now work with juju. LP #1221868
  Configuration changes

* tools-url is a new configuration option used to specify the location
  where the tools tarballs may be found. If specified, this overrides the
  default tools repository.

* image-metadata-url is a new configuration option used to specify the
  location where image metadata may be found. This is only normally
  required for private Openstack deployments.

* public-bucket-url is deprecated - use tools-url to specify where tools
  are located (if not handled automatically by your cloud provider).

Known issues

* The JUJU_ENV environment variable is not being passed down to
  plugins. LP #1216254.

Testing on Canonistack and HP Cloud

Starting with this release, there is no longer any requirement to use a
public-bucket-url configuration attribute when bootstrapping Canonistack
or HP Cloud environments. The public-bucket-url attribute is deprecated
and you are advised to remove it from your environment configuration.

Bootstrapping and tools

When Juju bootstraps an environment, it searches for a tools tarball
matching the version of the Juju client used to run the bootstrap. Prior
to this release, any tools with the same major version number as the
Juju client were considered a match. Starting with this release, both
the major and minor version numbers must match. This is to prevent any
subtle and hard to find bugs due to version mismatch from manifesting
themselves.

For users of Juju on EC2, HP Cloud, Azure, and Canonistack, where the
tools are maintained by Canonical  in the cloud itself, and MASS, with
access to the web to download the tools, there will be no noticeable
change. For private cloud setups, more care will be needed to ensure all
the required tools tarballs are available.

Configuring tools

A focus of this release is to make bootstrapping a Juju environment work
better out of the box, eliminating the need for manual configuration
steps. To this end, the following improvements are delivered:

1. HP Cloud and Canonistack users no longer need any special
   configuration over and above what goes into any generic Openstack setup
   for Juju.

2. Users who compile and run Juju from source can bootstrap without
   manually having to tell Juju to upload a custom tools tarball. The
   upload-tools bootstrap option is still available to force a tools
   upgrade, but it is no longer required just to bootstrap the first time
   or when starting again after an environment has been destroyed.

Users who wish to run Juju in HP Cloud from scratch can now just follow
the same steps as used for EC2:

1. run juju init
2. source a credentials file containing username, password, region etc,
   or edit the newly created ~/.juju/environments.yaml file to add
   username, password, region[a] etc to the hpcloud environment block
3. run juju bootstrap -e hpcloud

HP Cloud users can run juju switch hpcloud to make the default
environment hpcloud and remove the need to use the -e parameter with
each Juju command.

Private Openstack deployments

Tools can now be served by any http server, or from a shared mounted
directory accessible from the cloud, removing the requirement to place
the tools in a cloud storage instance. Using a cloud storage instance is
still possible of course, but this option may be more desirable for
users who wish to set up a private cloud without outgoing web access.
The steps are as follows:

1. Copy the tools tarballs for a given Juju version to a directory
   named like: <some path>/tools/releases
2. run juju sync-tools --all --source=<some path> --destination=<some path>
3. Configure your http server to serve to contents of
   <some path> under http://<your url>
4. Add tools-url: http://<your url> to your environments.yaml file.

An alternative to using http is to copy the tools directory itself, from
<some path>, to a shared drive which is accessible to client machines
and cloud instances via a common mounted directory. In that case, add an
entry like this to your environments.yaml:
tools-url: file://mounted_dir

Users who still wish to place the tools in a cloud instance should copy
the tools directory itself to a publicly readable storage instance. Then
add the tools-url entry to environments.yml:
tools-url: https://<path to storage instance>/tools

A final alternative for locating tools is to copy the entire tools
directory created above to the cloud’s control bucket, as specified in
the environments.yaml file. No tools-url configuration is required, but
note that these tools will only be visible to that one particular Juju
environment.

Configuring image metadata

Just as private Openstack deployments need to configure where tools are
located, so too does the location of the image metadata need to be
specified. This is not applicable for supported openstack clouds like HP
Cloud and Canonistack, only private deployments.  Prior to this release,
the public-bucket-url was used to point to the location of the metadata.
Now, configure the image-metadata-url as follows: image-metadata-url:
<old-public-bucket-url>/juju-dist

Note that the image metadata no longer has to be kept in a cloud storage
instance. The above example simply assumes the metadata will be kept in
the same location as prior to this release. But as with tools, the image
metadata may be server from any http url or even a directory using
file://<dir name>. The same caveats apply.

Finally

As an unstable release we do not make guarantees about clean upgrade
paths of running environments from one 1.13.x version to another.
However, live-upgrades should work now, and will be a supported feature
of stable releases.

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
On behalf of the Juju team
https://launchpad.net/juju-core

-- 
Curtis Hovey
Canonical Cloud Development and Operations
http://launchpad.net/~sinzui