juju-core 1.21-alpha1
Retracted because it conflicts with juju 1.16.x and 1.18.x rules for bootstrap and upgrade.
Milestone information
- Project:
- juju-core
- Series:
- 1.21
- Version:
- 1.21-alpha1
- 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 Adam Collard, 30 Andrew Wilkins, 2 Bodie Solomon, 1 Casey Marshall, 2 Curtis Hovey, 12 Dave Cheney, 4 Dimiter Naydenov, 1 Domas Monkus, 1 Eric Snow, 5 Frank Mueller, 3 Horacio Durán, 27 Ian Booth, 3 Jesse Meek, 1 John A Meinel, 4 John Weldon, 2 Jorge Niedbalski, 13 Katherine Cox-Buday, 2 Matthew Williams, 5 Menno Finlay-Smits, 2 Michael Foord, 1 Nate Finch, 1 Roger Peppe, 6 Tim Penhey, 1 Wayne Witzel III
- Blueprints:
- No blueprints are targeted to this milestone.
- Bugs:
- 138 Fix Released
Download files for this release
Release notes
juju-core 1.21-alpha1
A new development release of Juju, juju-core 1.21-alpha1, is now available.
Getting Juju
juju-core 1.21-alpha1 is available for utopic and backported to earlier
series in the following PPA:
https:/
The devel packages in this archive use the devel simple-streams.
You must configure the 'tools-
environments.yaml to use the matching juju tools.
tools-
This ensures a clean separation between the stable tools and the devel
tools. Production environments based on stable juju cannot accidentally
upgrade to a devel release even when the --version option is passed to
the 'upgrade-juju' command. The 'tools-
to clearly state the environment is for evaluating development versions.
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.21-alpha1. You can switch your testing
environment to use the devel streams like so:
juju set-env tools-metadata-url=https:/
This change may take hours to propagate. You can upgrade when the devel url
is shown to be in the env.
juju get-env tools-metadata-url
Notable Changes
* Harvest Modes
* Disabling apt-get update/upgrade for faster provisioning
* Using daily image streams for faster provisioning
* Add many machines
* Setting the MAAS network rules
* Performing autopsies on failed bootstraps
Harvest Modes
Juju keeps a model of what it thinks the environment looks like, and
based on that model, can harvest machines which it deems are no longer
required. This can help keep your costs low, and keep you out of web
consoles. Juju supports several harvesting modes to suit your needs.
that Juju knows about. Unknown instances will not be harvested. This
is the default mode.
Destroyed: Juju will harvest only machine instances that are dead, and
Unknown: Juju will harvest only instances that Juju doesn't know about.
All: Juju will terminate all instances – destroyed or unknown – that it
finds. This is a good option if you are only utilizing Juju for your
environment.
None: Juju won't harvest any machines. This is the most conservative
mode, and a good choice if you manage your machines utilizing a separate
process outside of Juju.
Juju's harvesting behaviour is set through the environments.yaml file.
provisioner
'provisioner-
'safe-mode' set will be converted to 'provisioner-
upgraded.
Disabling apt-get update/upgrade for faster provisioning
When juju provisions a machine, its default behaviour is to update the
list of available packages and upgrade the existing packages to the
latest version. If your OS images are fresh or the services you deploy
don't require updated packages, you can disable updates and upgrades to
provision the machine faster.
Two configuration options are available to disable apt updates and
upgrades. When your OS images are fresh, you can set both
'enable-
know that some charms want the latest packages to to setup services, you
will want to keep 'enable-
You can configure the options in environments.yaml for fast provision
like so
enable-
enable-
Using daily image streams for faster provisioning
Juju prefers to use the well slow changing "released" images when
provisioning machines. The 'image-stream' option in environments.yaml
can be set to "daily" use more up-to-date images, thus shortening the
time it takes to perform apt-get update/upgrade. While this feature has
existed since 1.18.0, it was not applied consistently KVM containers.
KVM containers will now use "daily" when environments.yaml is set to:
image-stream: daily
Add many machines
Juju's 'add-machine' command now accepts the '-n' option to add many
machines. For example, to add two machines:
juju add-machine -n 2
The '-n' option can be combined with placement. You can add to lxc
containers to machine 1 thusly
juju add-machine lxc:1 -n 2
Setting the MAAS network rules
The default network bridge is eth0. MAAS environments can specify a
different interface using the network-bridge options. For bridge can
be set to eth2 in environments.yaml like so:
network-bridge: eth2
Juju and MAAS cannot both be in control of the network. When MAAS
is managing the bridge and bringing networks up and down, set the
'disable-
disable-
This tells Juju not to create a network bridge or bringing eth0
up and down during cloudinit. Juju will not make changes to the
network config when its agents start.
Performing autopsies on failed bootstraps
The juju 'bootstrap' command has a new option for testers and anyone
examining why a bootstrap failed. Use the '--keep-broken' option to
keep the machine up. You can then use ssh to gather logs and
investigate the cause of the failure.
Resolved issues
* Maas provider assumes machine uses dhcp for eth0
Lp 1361374
* Relation-get with invalid relation name panics agent
Lp 1365412
* We should remove direct db access for clients
Lp 1253652
* Allow specifying a key when doing manual provisioning
Lp 1270466
* Juju doesn't use maas' knowledge of system architecture when picking
tools
Lp 1303853
* Juju add-machine still assumes precise (maas)
Lp 1315473
* Local provider is very slow to tranistion from agent-status: pending
Lp 1322302
* Juju should wrap apt-get invocations with eatmydata when
provisioning cloud instances
Lp 1335822
* Juju 1.21-alpha1 local provider does not create all-machines.log
Lp 1339715
* Cloudinit does not use ssh client
Lp 1339976
* Provisioner-
Lp 1342729
* Networker restarts every 3 seconds with the local provider (missing
/etc/
Lp 1343219
* Describe harvesting strategy rather than using "safe mode" name
Lp 1345553
* Configstore: if the size of the serialised jenv decreases the .jenv
file will be corrupt
Lp 1348458
* Juju-core client panics with juju set empty string
Lp 1348829
* Juju ignores environments.yaml on failed bootstrap if $provider.jenv
exists
Lp 1361680
* Saved addresses should omit link-local addresses
Lp 1362453
* Add-machine containers should default to latest lts
Lp 1363971
* Blobstore's hashing needs improvement
Lp 1364750
* --keep-broken option still allows instance to be stopped
Lp 1365772
* Removing a unit on an unclean machine should remove that machine
Lp 1206532
* Juju log files should not be world readable
Lp 1286518
* Juju uses hard-coded regions
Lp 1319474
* Cmd/juju: deploy --to a non existent machine fails too late in the
process
Lp 1212538
* Cmd/juju: add-machine should take a -n param
Lp 1214209
* Missing @ syntax for reading config setting from file content
Lp 1216967
* Container provisioner may choose bad tools
Lp 1347984
* Juju set help is written but not shown
Lp 1359187
Finally
We encourage everyone to subscribe the mailing list at
juju-dev@
Changelog
This release does not have a changelog.
