juju-core 1.21-alpha2

juju-core 1.21-alpha2

A new development release of Juju, juju-core 1.21-alpha2, is now
available. This release replaces 1.21-alpha1.

Getting Juju

juju-core 1.21-alpha2 is available for utopic and backported to earlier
series in the following PPA:

    https://launchpad.net/~juju/+archive/devel

Upgrading from stable releases to devel 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-alpha2.

The devel packages in this archive use the devel simple-streams.
You must configure the 'agent-metadata-url' option in your
environments.yaml to use the matching juju tools.

    agent-metadata-url: https://streams.canonical.com/juju/devel/tools

'tools-metadata-url' was renamed to 'agent-metadata-url'.

Notable Changes

* Provider storage is no longer mandatory (for new providers)
* AWS now defaults to using images with SSD storage
* The juju ensure-availability command now supports placement directive
* Automatic placement using MAAS zones
* Various apt improvements
* Improved use of availability zones on Openstack
* The api-info command shows the settings used to connect to juju
* state-server Multiple users are now supported.

Provider storage is no longer mandatory (for new providers)

Storage associated with a particular cloud (S3 for AWS, Swift for
Openstack etc) was a mandatory requirement when developing a provider to
allow Juju to deploy workloads to any particular cloud platform. This
requirement is no longer necessary. Although existing providers still
use cloud storage (to some extent), new providers can be written without
needing to provide a storage implementation.

Upgrading existing environments will take longer than normal because
the state-server will migrate data from the old storage location. During
this time status will report that the upgrade will be retried over many
minutes:

    Upgrade to 1.21-alpha2 failed (will retry): migrate tools into
    environment storage: cannot find tools in provider storage: no tools
    available

AWS now defaults to using images with SSD storage

When deploying workloads onto AWS, images with SSD volumes are now
preferred. If no such image are available, an image using EBS storage
will be used as a fallback.

The juju ensure-availability command now supports placement directive

Just as 'juju bootstrap' supports the ability to specify a particular
node using '--to' placement directives, so too can
'juju ensure-availability' specify a comma separate list of machine to
use for any newly required state servers.
For example:

    juju ensure-availability -n 3 --to name1,name2

Automatic placement using MAAS zones

The MAAS provider is now on par with AWS and Openstack providers in
supporting automatic placement using zones.

Various apt improvements

You can now configure 'apt-mirror' in environments.yaml to specify the
mirror used by all the machines provisioned in the environment.

    apt-mirror: http://my.archive.ubuntu.com

On precise, the cloud tools archive is now pinned before calling apt
upgrade to ensure its packages are a lower priority than the default
precise archives. Charms developed on precise will see the same packages
when deployed into a juju provisioned machine. If your precise charm
requires packages from the cloud tool's archive, you can use the
'target-release' option to specify the archive to select.

    apt-get --target-release precise-updates/cloud-tools my-package

The local-provider skips apt updates and upgrades by default for faster
provisioning. 1.21-alpha1 introduced the ability to disable apt upgrades
and updates for faster provisioning. The default for local provider
were both false. This release introduces a default of true for apt
update operations for local provider. If you wish to enable updates and
upgrades in your local development, update your environments.yaml.

        enable-os-upgrade: true
        enable-os-refresh-update: true

Improved use of availability zones on Openstack

The Openstack provider now attempts to start instances in all available
zones until it finds one that succeeds, rather than trying just the
first zone and failing. This aligns Openstack behavior with what was
already done for AWS.

The api-info command shows the settings used to connect to juju
state-server.

The 'juju api-info' command shows the settings used to connect to the
juju state-server's API. You can see the settings for all the fields
(except for password) like so:

    juju api-info

If you want to see the password being used, you need to either use the
'--password' option

    juju api-info --password

Or specify the password field as the only field to show

    juju api-info password

You can learn the value of any field by including it in the command
line. For example, to learn the name of user created during bootstrap,
type

    juju api-info user

Multiple-user Support

Juju now supports multiple people connecting to the environment with
their own identity and credentials.

When an environment is bootstrapped the “admin” user is created (this
will change with 1.22 to reflect the name of the logged in user).

Even though we have multiple users, we do not yet support fine grain
permissions. These will come in time, and do depend on this work. The
only permission checked at this stage is that it is only the state
server administrator user that was created during bootstrap that is
able to create or disable other users. Any user is now able to change
their own password.

The user commands are grouped under the 'juju user' command:

    juju user
    usage: juju user <command> ...
    purpose: manage user accounts and access control

    "juju user" is used to manage the user accounts and access control
    in the Juju environment.

    commands:
        add - adds a user
        change-password - changes the password of the current user
        disable - disable a user to stop the user logging in
        enable - reenables a disabled user to allow the user
                          to log in
        help - show help on a command or other topic
        info - shows information on a user
        list - shows all users

You can add a user like this:

    juju user add test "Test User"

    To generate a random strong password, use the --generate option.
    password:
    type password again:
    user "Test User (test)" added
    environment file written to /home/tim/some-dir/test.jenv

The generated environment file still needs to be copied into the user's
$JUJU_HOME/environments directory in order to be used. Future versions
of Juju will make this more simple. The name of the environments file
is the name that the user needs to use to talk to the environment, so
the user will probably want to rename it too.

Juju will ask for a password to be typed in. If you'd prefer a strong
random password, you can use the '--generate' option. You can also
control the location and name of the environments file that is created.

You can see which users have been created using the ‘juju user list'
command:

    juju user list
    NAME DISPLAY NAME DATE CREATED LAST CONNECTION
    admin admin 23 minutes ago just now
    test Test User 5 minutes ago never connected
    thumper Tim 5 seconds ago never connected

The output of this command can also be in YAML or JSON using the usual
'--format' options.

Any user that is created will be able to access the environment. To
stop this, you can disable the user.

    juju user disable test
    User "test" disabled

    juju api-info user -e local-test
    test

    juju user info -e local-test
    WARNING discarding API open error: environment "local-test" not
    found
    ERROR invalid entity name or password

Unfortunately the warning there is due to legacy environment support
that is checked as a fallback when the initial connection failed due to
the user being disabled.

Disabled users are not shown by default with the listing:

    juju user list
    NAME DISPLAY NAME DATE CREATED LAST CONNECTION
    admin admin 30 minutes ago just now
    thumper Tim 6 minutes ago never connected

but they can be included with the '--all' option:

    juju user list --all
    NAME DISPLAY NAME DATE CREATED LAST CONNECTION
    admin admin 32 minutes ago just now
    test Test User 13 minutes ago 2 minutes ago (disabled)
    thumper Tim 8 minutes ago never connected

Disabled users can be enabled again using the enable command:

    juju user enable test
    User "test" enabled

    juju user info -e local-test
    user-name: test
    display-name: Test User
    date-created: 14 minutes ago
    last-connection: just now

Resolved issues

* Bootstrap on maas fails trying to access cloud-images.ubuntu.com
  Lp 1365135

* Cloud-archive on precise not pinned when juju calls apt-get upgrade
  Lp 1370781

* Status panics if environment not running
  Lp 1372264

* Method client.addmachinesv2 is not implemented
  Lp 1373424

* Rsyslog worker continuously restarts due to x509 error following
  upgrade
  Lp 1375507

* Allow open-port to expose several ports
  Lp 1216644

* Launchpad.net/juju-core/juju tests sometimes fail mgo tip
  Lp 1252859

* Not okforstorage error when deploying local charm
  Lp 1308146

* Modify firewaller to watch openedports collection
  Lp 1337813

* Modify api to handle port ranges
  Lp 1337817

* Failed add-machine ssh: leaves behind garbage in state
  Lp 1356886

* Azure fails with juju bootstrap --upload-tools --upload-series
  Lp 1357511

* Support maas zones for automatic az placement
  Lp 1360605

* Containers not starting on machine
  Lp 1362360

* juju should support an apt alternate mirror for private clouds
  Lp 1364200

* "juju ssh" doesn't work during tools upgrade
  Lp 1367009

* Sshstorage fails in non-english locale
  Lp 1367695

* Bootstrap failed: unexpected error type *errors.errorstring
  Lp 1367896

* Juju 1.18 and 1.20 cannot parse simplestreams containing version
  "1.21-alpha1"
  Lp 1367987

* Ensure-availability command doesn't support placement directives
  Lp 1370332

* 1.21-alpha1 bootstrap local fails with nil pointer dereference
  Lp 1372511

* Api logins fail with "invalid entity name or password" before db
  migrations have run
  Lp 1372752

* Juju needs to support the maas api's not_tags constraint
  Lp 1373385

* Error message when trying to deploy to node 0 on lxc needs to be
  more user friendly
  Lp 1378792

* Juju does not consider whether it has permission to an availability
  zone
  Lp 1380557

* Use ssd image types on amazon ec2
  Lp 1381009

* 1.21 alpha dumps a stack trace when ec2 credentials are missing
  Lp 1381233

* Configuration item tools-stream deprecated in favour of agent-stream
  Lp 1383070

* Azure bootstrap fails when 'location' and 'storage-account-name' are
  not in the same region
  Lp 1236136

* Juju run doesn't work with subordinate units
  Lp 1286613

* Need to reset user passwords (+ui)
  Lp 1288750

* Bootstrap without a jenv destroys an existing environment
  Lp 1336843

* Api-endpoints has inconsistent purpose documentation
  Lp 1380521

Finally

We encourage everyone to subscribe the mailing list at
juju-dev@lists.canonical.com, or join us on #juju-dev on freenode.