juju-core 1.16.0
Milestone information
- Project:
- juju-core
- Series:
- 1.16
- Version:
- 1.16.0
- Released:
- Registrant:
- Curtis Hovey
- Release registered:
- Active:
- No. Drivers cannot target bugs and blueprints to this milestone.
Activities
- Assigned to you:
- No blueprints or bugs assigned to you.
- Assignees:
- 2 Andrew Wilkins, 1 Frank Mueller, 6 Ian Booth, 1 John A Meinel, 3 Martin Packman, 1 Nate Finch, 1 William Reade
- Blueprints:
- No blueprints are targeted to this milestone.
- Bugs:
- 2 Invalid, 15 Fix Released
Download files for this release
Release notes
juju-core 1.16.0
A new stable release of Juju, juju-core 1.16.0, is now available.
Getting Juju
juju-core 1.16.0 is available in Saucy and backported to earlier series
in the following PPA
https:/
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-
* 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_
line. To show the log on the command line, now use --show-log. The
--debug has been kept to be short-hand for "--log-
--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
* The unset command is now available from the command line. LP #1237929
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).
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/
username, password, region 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/
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-
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
We encourage everyone to subscribe the mailing list at
juju-dev@
Changelog
This release does not have a changelog.
