# juju 2.0-beta4
A new development release of Juju, juju 2.0-beta4, is now available.
This release replaces version 2.0-beta3.
## Getting Juju
Juju 2.0-beta4 is available for Xenial and backported to earlier
series in the following PPA:
https://launchpad.net/~juju/+archive/devel
Windows, Centos, and OS X users will find installers at:
https://launchpad.net/juju-core/+milestone/2.0-beta4
Upgrading to this development releases is not supported.
## The complete release notes available on the Web
The release notes for Juju 2.0-beta4 are very long. They are too large
to post to a list. The complete release notes are published at
https://jujucharms.com/docs/devel/temp-release-notes
## Getting started with Juju 2.0
Juju 2.0 allows you to get started creating models without modifying any
definition files. Just provide your credentials and go! (Note: to
fully understand the new bootstrap experience please see the "New
Bootstrap and Cloud Management Experience" section below)
* LXD provider (requires lxd 2.0.0~rc9 or later):
The LXD provider requires no credentials, so you can create a
controller by just specifying its name:
juju bootstrap <controller name> lxd
Note that the lxdbr0 bridge needs to be properly configured for the lxd
provider to work, for details see:
http://insights.ubuntu.com/2016/04/07/lxd-networking-lxdbr0-explained/
* Public Clouds:
Known public clouds can be listed with juju list-clouds:
juju list-clouds
CLOUD TYPE REGIONS
aws ec2 us-east-1, us-west-1, us-west-2, ...
aws-china ec2 cn-north-1
aws-gov ec2 us-gov-west-1
azure azure japanwest, centralindia, eastus2, ...
azure-china azure chinaeast, chinanorth
cloudsigma cloudsigma mia, sjc, wdc, zrh, hnl
google gce us-east1, us-central1, ...
joyent joyent us-east-1, us-east-2, us-east-3, …
lxd lxd
maas maas
manual manual
rackspace rackspace LON, SYD, HKG, DFW, ORD, IAD
Add your credentials using either:
juju add-credential <cloud>
or
juju add-credential <cloud> -f creds.yaml
or
juju autoload-credentials
When specifying just the cloud, juju add-credential will allow a new
credential to be added interactively. You will be prompted type the
required credential attributes. Example:
juju add-credential maas
credential name: hmaas
replace existing credential? [y/N]: y
auth-type: oauth1
maas-oauth:
credentials added for cloud maas
The new credentials.yaml file at: ~/.local/share/juju/credentials.yaml
The autoload tool will search for existing credentials for AWS,
OpenStack/Rackspace, and Google clouds. You will then be prompted for
which ones you'd like to save.
If you have an existing credential.yaml file, you can also import a
named credential, eg for MAAS
cat credentials.yaml
credentials:
maas:
my-credentials:
auth-type: oauth1
maas-oauth: <mass-oauth-key>
or, for AWS
cat credentials.yaml
credentials:
aws:
default-credential: my-credentials
my-credentials:
auth-type: access-key
access-key: <key>
secret-key: <secret>
Bootstrap using your default credentials:
juju bootstrap <controller name> <cloud>[/region]
Examples:
juju bootstrap aws-controller aws
juju bootstrap mass-controller maas/192.168.0.1
In the MAAS example above, you specify the host address of the MAAS
controller. So to use Juju on MAAS out of the box, you set up a
credentials file (either interactively, or based on the example above)
and then bootstrap. This avoids the need for any cloud configuration.
But it's also possible to set up a named MAAS cloud definition as
explained later.
More details on the new bootstrap experience, including defining private
clouds can be found in the New Bootstrap and Cloud Management Experience
section.
## What's New in Beta4
* Mongo 3.2 is now used when bootstrapping on Xenial hosts
* address-allocation feature flag no longer supported in MAAS provider
* prefer-ipv6 setting is now ignored in all providers
* MAAS 1.9+ provisioned LXD containers now have a bridge per NIC
* Accurate address selection based on spaces (in MAAS)
* extra-bindings support for charms metadata
* network-get hook tool arguments changed
* Juju GUI in the Controller
* Juju Now Respects CharmStore Channels
### Mongo 3.2 Support
Juju will now use Mongo 3.2 for its database, with the new Wired Tiger
storage engine enabled. This is initially only when bootstrapping on
Xenial. Trusty and Wily will be supported soon.
### address-allocation feature flag no longer supported in MAAS provider
In earlier releases, it was possible to get Juju to use static IP
addresses for containers from the same subnet as their host machine,
using the following development feature flag:
JUJU_DEV_FEATURE_FLAGS=address-allocation juju bootstrap ...
This flag is no longer supported and will not be accepted.
### Accurate Address Selection Based on Network Spaces (in MAAS)
MAAS 1.9+ offers native support for Network Spaces, which Juju will
discover and import. This means Juju knows which space any machine
address comes from and can select addresses based on their space. An
example for this improved support is the used by the 'network-get' hook
tool. Earlier versions of Juju (and even this one on providers other
than MAAS) use a simpler address selection based on scope and
lexicographic order.
### network-get Hook Tool Arguments Changed
The new 'network-get' hook tool introduced in 2.0-alpha3 slightly
changed:
Before: network-get -r <relation-id> --primary-address
Now: network-get <binding-name> --primary-address
Instead of taking an (implicit) -r argument with relation ID, the first
expected argument is now a binding name. This can be a name listed
inside the "extra-bindings" section of the charm metadata.yaml, or a
name of a relation (from the "provides", "requires", or "peers"
sections). The output is the same otherwise - a single address returned.
### extra-bindings Support for Charms Metadata
Many charms use a simple model where a relationship with another charm
also indicates there is a network connection between units of those
services. We have utilized this fact to add a network model that allows
system operators to control where those TCP connections are made by
binding the service relation endpoints onto a network space.
However, some charms specifically use relation endpoints as simply a way
to pass configuration around, and the relations don't map directly to
services that are running in that charm and/or networking configuration.
These charms want to be able to express that they have more networking
configuration that an operator wants to control without having yet-
another interface that will never be related to another service.
Juju solves the aforementioned issues by introducing an optional new
section in the charm metadata,yaml. The new section is called "extra-
bindings". Similarly to the peers/provides/requires sections, extra-
bindings contains a list of names, which can be used with 'juju deploy
--bind' like relation names. Unlike relations, you don't have to define
hooks or anything more complex to allow the users of the charm to bind
those names to Juju spaces.
Example: ceph charm's metadata.yaml would look like:
name: ceph
summary: Highly scalable distributed storage
maintainer: OpenStack Charmers <openstack-charm...@lists.ubuntu.com>
description: |
Ceph is a distributed storage and network file system designed to provide
excellent performance, reliability, and scalability.
tags:
- openstack
- storage
- file-servers
- misc
peers:
mon:
interface: ceph
extra-bindings:
cluster:
public:
provides:
nrpe-external-master:
interface: nrpe-external-master
scope: container
…
storage:
osd-devices:
type: block
multiple:
range: 0-
osd-journal:
type: block
multiple:
range: 0-1
As a user then you can deploy this charm and tell Juju to provide
distinct addresses for it on one or more spaces:
juju deploy ~/path/to/charm/ceph --bind 'cluster=admin-api
public=public-api internal-api'
Units of the ceph service will be deployed on machines which have access
to the "admin-api", "public-api", and "internal-api" spaces in MAAS, a
different network interface and address for each binding.
Then, e.g. in a hook of the same charm, running 'network-get cluster
--primary-address' will only return the correct address - the one coming
from the "admin-api" space.
### Juju GUI in the Controller
Juju GUI is now automatically included in every Juju controller after
bootstrapping, thus eliminating the need to additionally deploy the Juju
GUI charm.
In order to open the Juju GUI in the default browser the following
command should be used.
juju gui
The GUI connects to the model that is currently active. You are greeted
with the login window, where you will have to provide the credentials to
access the model. If you want to output your credentials in the
terminal for easier copy/paste into login window, run the GUI with the
'--show-credentials' option.
juju gui --show-credentials
### juju upgrade-gui
The upgrade-gui command downloads the latest published GUI from the
streams and replaces the one on the controller. To verify which versions
of the GUI are available before the upgrade, try:
juju upgrade-gui --list
If you want to upgrade (or downgrade) to a specific version of the GUI,
provide the revision as a parameter to the upgrade-gui command, where
the revision listed by the `juju upgrade-gui --list`. For example:
juju upgrade-gui 2.1.1
If you’d like to try a version of the GUI that has not been published in
the streams and is not listed yet, you are able to provide the blob
either from a charm or from the manually built GUI. Example:
juju upgrade-gui /path/to/release.tar.bz2
In order to upgrade the GUI, you need proper access rights to
the controller. When an administrator upgrades the GUI, the users will
have to reload the open sessions in the browser.
If you don not want to install the GUI into the controller, bootstrap
your controller with the '--no-gui option.
### Juju Now Respects CharmStore Channels
For more information on the new support for channels in the Charm Store
and how they work, please see our
[documentation](https://jujucharms.com/docs/devel/authors-charm-store
#entities-explained) on the subject.
Support for channels has been brought into Juju via command options on the
relevant sub-commands:
juju deploy
Juju upgrade-charm
## Known issues
* juju lxd bridge detection fallback is not reliable
Lp 1570573
* Juju 2.0 no longer supports KVM for local provider
Lp 1547665
* Cannot deploy a dense openstack bundle with native deploy
Lp 1555808
* Cannot add LXD containers in 2.0beta4 on trusty
Lp 1568895
* Address Allocation feature flag still enabled for MAAS provider
in Juju 2.0
Lp 1568925
* Newly created LXD container has zero network devices
Lp 1564395
* LXD containers /etc/network/interfaces as generated by Juju gets
overwritten by LXD container start
Lp 1566801
* juju restore-backup does not complete properly
Lp 1569467
* Credentials files containing Joyent credentials must be updated to
work with beta3 (See "Joyent Provider No Longer Uses Manta Storage")
## Resolved issues
* Certificate error when visiting the embedded juju gui
Lp 1555083
* The client.watchall api command never responds when the model has
no machines
Lp 1560201
* Juju does not fall back to cloud-images if --bootstrap-series not
supplied
Lp 1560625
* Error cannot find network interface "lxcbr0": route ip+net: no
such network interface
Lp 1566589
* Juju cannot bootstrap on xenial without juju-mongodb3.2 package
Lp 1566628
* Agents stuck in "waiting for agent initialization to finish" with
lxd provider
Lp 1567683
* Juju should fallback to juju-mongodb after first failure to find
juju-mongodb3.2
Lp 1568312
* Fallback for mongo packages doesn't include wily
Lp 1568390
* Region names for rackspace should accept caps and lowercase
Lp 1569024
* Jujud fails to start with "could not find a suitable binary for
"0.0/mmapv1""
Lp 1569097
* Enable-ha with placement fails due to invalid jobmanagenetworking
Lp 1569196
* Failed to bootstrap because exec: "mongod": executable file not
found in $path
Lp 1569408
* Proxyupdater api facade does not set notifywatcherid in the result
Lp 1569725
* Provider/azure: creating subnet fails if the environment name is
too long
Lp 1524077
* Add xenial to supported series
Lp 1533262
* Ec2: destroy-controller blows the rate limit trying to delete
security group - can leave instances around
Lp 1537620
* --bootstrap-series can cause "no matching tools available" error
Lp 1538735
* Kill-controller fails on missing volume
Lp 1543223
* Concurent map access in joyent
Lp 1554251
* Help text for juju destroy-controller needs improving
Lp 1555248
* The addcharmwithauthorization api endpoint needs to respect
channels.
Lp 1560511
* Charm channels must be used on the controller.
Lp 1560520
* Charm store macaroons must be used on the controller.
Lp 1560531
* Juju 2 beta3 can't bootstrap to lcy02
Lp 1563576
* Destroy-controller blocks when you've not removed an empty default
model
Lp 1563615
* "juju upgrade-juju --upload-tools" fails after "juju login"
Lp 1563762
* Kvm containers don't use correct parent interface device
Lp 1563853
* Juju2: charms fail with series mismatch when deployed to
containers in bundle
Lp 1564057
* Juju ssh doesn't work with multiple models
Lp 1566237
* Fallback to installing mongo 2.4 if no 3.2 doesn't work
Lp 1567182
* "juju destroy-controller" can leak hosted models
Lp 1567228
* Juju-run does not work on windows hosts
Lp 1426729
* Help text for juju destroy-model needs improving
Lp 1553272
* Help text for juju remove-service needs improving
Lp 1554687
* Help text for juju list-models needs improving
Lp 1556249
* Help text for juju show-cloud needs improving
Lp 1560595
* Help text for juju status needs improving
Lp 1560665
* Help text for juju list-clouds needs improving
Lp 1560667
* Update-clouds message improvement when fully up to date
Lp 1563843
* Region names should be case-insensitive but displayed as lowercase
Lp 1563845
* Help text for juju set-model-config needs improving
Lp 1563923
* Help text for juju get-model-config needs improving
Lp 1563924
* Help text for juju get-model-constraints needs improving
Lp 1563927
* Help text for juju set-model-constraints needs improving
Lp 1563928
* Help text for juju unset-model-config needs improving
Lp 1563938
* Help text for juju update-clouds needs improving
Lp 1563958
* All: mutex's copied by value
Lp 1563628
Finally
We encourage everyone to subscribe the mailing list at
j...@lists.ubuntu.com, or join us on #juju on freenode.
--
Curtis Hovey
Canonical Cloud Development and Operations
http://launchpad.net/~sinzui
--
Juju-dev mailing list
Juju-dev@lists.ubuntu.com
Modify settings or unsubscribe at:
https://lists.ubuntu.com/mailman/listinfo/juju-dev
