juju-core 1.24-beta1
Milestone information
- Project:
- juju-core
- Series:
- 1.24
- Version:
- 1.24-beta1
- 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:
- 1 Andrew Wilkins, 2 Eric Snow, 3 Horacio Durán, 5 Ian Booth, 1 Menno Finlay-Smits, 1 Nate Finch, 1 Wayne Witzel III
- Blueprints:
- No blueprints are targeted to this milestone.
- Bugs:
- 14 Fix Released
Download files for this release
Release notes
# juju-core 1.24-beta1
A new development release of Juju, juju-core 1.24-beta1, is now available.
This release replaces version 1.24-alpha1.
## Getting Juju
juju-core 1.24-beta1 is available for vivid and backported to earlier
series in the following PPA:
https:/
Windows and OS X users will find installers at:
https:/
Development releases use the "devel" simple-streams. You must configure
the `agent-stream` option in your environments.yaml to use the matching
juju agents.
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.24-beta1.
## Notable Changes
* VMWare (vSphere) Provider
* Storage (experimental) MAAS Provider Support
* Storage (experimental) Unit Placement
### VMWare (vSphere) Provider
Juju now supports VMWare's vSphere ("Software-Defined Data Center")
installations as a targetable cloud. It uses the vSphere API to interact
with the vCenter server. The vSphere provider uses the OVA images
provided by Ubuntu's official repository. API authentication
credentials, as well as other config options, must be added to your
environments.yaml file before running 'juju bootstrap'. The different
options are described below.
The basic config options in your environments.yaml will look like this:
my-vsphere:
type: vsphere
host: <192.168.1.10>
user: <some-user>
password: <some-password>
datacenter: <datacenter-name>
The values in angle brackets need to be replaced with your vsphere
information. 'host' must contain the IP address or DNS name of vSphere
API endpoint. 'user' and 'password' are fields that must contain your
vSphere user credentials. 'datacenter' field must contain the name of
your vSphere virtual datacenter. 'external-network' is an optional
field. If set, it must contain name of the network that will be used to
obtain public IP addresses for each virtual machine provisioned by juju.
An IP pool must be configured in this network and all available public
IP addresses must be added to this pool. For more information on IP
pools, see official documentation:
NOTE that using the vSphere provider requires an existing vSphere
installation. Juju does not set up vSphere for you. The OVA images we
use support VMWare's Hardware Version 8 (or newer). This should not be a
problem for nearly all vSphere installations.
### Storage (experimental) MAAS Provider Support
The MAAS provider now supports storage. Storage directives are used to
select machines which have the requisite number and size of volumes
available on the machine (usually physical volumes such as SSD or
magnetic drives).
Storage pools may be created to select volumes with specified tags.
juju storage create pool maas-ssd maas tags=ssd
The above creates a pool called "maas-ssd" and when used, will select
volumes tagged in MAAS with the "ssd" tag. Tags may be a comma separated
list.
Then to deploy a charm:
juju deploy mycharm --storage data=maas-ssd,50G
The above deploys a charm to a MAAS machine with the data store mounted
on a volume at least 50GiB in size with the tag "ssd".
It is also possible to specify the size of the root-disk using the root
disk constraint. This works the same way as for the AWS provider
juju deploy mysql --constraints root-disk=50G
Storage directives and root disk constraints may be combined.
juju deploy mysql --constraints root-disk=50G --storage data=maas-ssd,500G
NOTE: the root disk support has only just landed in MAAS trunk.
the Juju/MAAS storage support has been smoke tested using the NEC
MAAS test lab. It needs much more extensive testing!
NOTE: when using MAAS which does not support storage, if MAAS storage is
requested, an error is returned and the node is cleaned up.
The storage feature is experimental: it has some known caveats, and has
not yet been battle hardened. Instructions on use and caveats are
documented at https:/
### Storage (experimental) Unit Placement
It is now possible to deploy units with storage to existing machines.
This applies when using storage that is dynamically created, such as
EBS/Cinder volumes, loop devices, TMPFS, rootfs. It can't be used with
machine volumes on MAAS, but can be used to deploy charms to an existing
MAAS machine if a dynamic storage source is specified. eg
juju deploy charm --to 2 --storage data=loop,2G
An Openstack deployment example:
juju deploy charm --to 2 --storage data=cinder,2G
## Resolved issues
* Broken db field ordering when upgrading to juju compiled with go
1.3+
Lp 1451674
* Log files are lost when agents are restarted under systemd
Lp 1452113
* Worker/uniter: charm does not install properly if storage isn't
provisioned before uniter starts
Lp 1452207
* Jujud does not restart after upgrade-juju on systemd hosts
Lp 1452511
* Maas provider chokes on unexpected device labels
Lp 1452725
* Juju 1.23-beta4 introduces ssh key bug when used w/ dhx
Lp 1444861
* Retry-provisioning launches instances for containers; cannot retry
containers at all
Lp 1428439
* Debug-hooks exit 1 , doesn't mark hook as failed
Lp 1415176
* Default storage constraints are not quite correct
Lp 1452535
* Maas: implement root-disk constraint
Lp 1212689
Finally
We encourage everyone to subscribe the mailing list at
juju-dev@
Changelog
This release does not have a changelog.
