Call for Testing: Preparing for the upcoming 2.7.0 Release

Juju 2.7.0 is due to be released in early November. It includes several features that have been in development for several months. You are very welcome to help with testing.

Schedule

The schedule is subject to change.

Date Event
October 22, 2019 2.7-beta1 finalised for review by Canonical’s internal QA team
October 25, 2019 2.7-beta1 released
October 31, 2019 2.7-rc1 finalised for review by Canonical’s internal QA team
November 1, 2019 2.7-rc1 released
November 7, 2019 2.7.0 released

How to test

Beta testers should be experienced Juju users with a pre-release version of Juju installed.

Installing pre-released versions of Juju

We recommend using snap. If you need to install Juju via a snap, it’s a single command:

snap install juju --classic

Once the Juju snap is installed, you can use the snap refresh command to track exactly what you want.

Stage Channel to Track Command
pre-beta edge snap refresh juju --channel=edge
beta beta snap refresh juju --channel=beta
release candidate candidate snap refresh juju --channel=candidate

Asking questions

If you are unsure whether something is attended behaviour, you are welcome to add a question here in Discourse under the #development category.

Another option is IRC. The Juju team is available in #juju on irc.freenode.net.

Filing bugs

If you’ve encountered an issue, please file a bug in Launchpad: https://bugs.launchpad.net/juju/+filebug

What to test

Your workload (that works today)

The most important use cases are real world use cases. If you have a workload that works now under Juju 2.6, please try creating a

Step 1: ensure that you’ve installed the Juju version that we want to test

Execute the juju version command:

juju version

Should not report 2.6.9 or below. Depending on the phase of the testing cycle you should see 2.7-beta1 or 2.7-rc1.

Step 2: Deploy your workload

juju bootstrap <cloud>
juju deploy ./private-bundle.yaml

Step 3: Report any regressions

If something no longer works, then you have found a serious bug. Please file a bug report (instructions above).

Credential and cloud management

Changes have been made to several commands to improve the user experience. You’re invited to experiment with the new experience by using these commands:

  • add-cloud
  • update-cloud
  • remove-cloud
  • show-cloud
  • list-clouds
  • add-credential
  • update-credential
  • remove-credential
  • show-credential
  • list-credentials
  • list-regions
  • autoload-credentials

Networking

The juju bind has been added for manipulating existing endpoint bindings.

Actions

Cross-model relations

Cross-model relations (CMR) are now considered stable and feature complete. We envisage two primary use cases:

  • setting shared services Vault and Keystone across models
  • deploying databases to traditional infrastructure and application software to Kubernetes

Bundles also support CMR:

Example CMR workflow
$ export JUJU_DEV_FEATURE_FLAGS=bundle-cmr
$ juju bootstrap lxd test --no-gui

# Deploy a bundle with an offer
$ juju add-user bar
$ juju deploy ./testcharms/charm-repo/bundle/apache2-with-offers
Resolving charm: cs:apache2-26
Executing changes:
- upload charm cs:apache2-26 for series bionic
- deploy application apache2 on bionic using cs:apache2-26
- create offer my-offer using apache2:apache-website,website-cache
- grant user admin admin access to offer my-offer
- grant user bar consume access to offer my-offer
- create offer my-other-offer using apache2:apache-website
Deploy of bundle completed.

# Verify that export-bundle generates a multi-doc bundle
$ juju export-bundle
series: bionic
applications:
  apache2:
    charm: cs:apache2-26
--- # overlay.yaml
applications:
  apache2:
    offers:
      my-offer:
        endpoints:
        - apache-website
        - website-cache
        acl:
          admin: admin
          bar: consume
      my-other-offer:
        endpoints:
        - apache-website
        acl:
          admin: admin

# Deploy another bundle with overlays
$ juju add-model test1

$ less testcharms/charm-repo/bundle/multi-doc-overlays/bundle.yaml
series: trusty
applications:
  apache2:
    charm: cs:apache2-26
    num_units: 1
--- # overlay 1
applications:
  apache2:
    offers:
      my-offer:
        endpoints:
        - apache-website
        acl:
          admin: admin
--- # overlay 2
applications:
  wordpress:
    charm: cs:trusty/wordpress-5
    num_units: 1

$ echo -n 'my-include' > example.txt
$ cat > overlay.yaml << EOT
applications:
  wordpress:
    annotations:
      raw: include-file://example.txt
      enc: include-base64://example.txt
EOT

$ juju deploy ./testcharms/charm-repo/bundle/multi-doc-overlays --overlay overlay.yaml
Resolving charm: cs:apache2-26
Resolving charm: cs:trusty/wordpress-5
Executing changes:
- upload charm cs:apache2-26 for series trusty
- deploy application apache2 on trusty using cs:apache2-26
- upload charm cs:trusty/wordpress-5 for series trusty
- deploy application wordpress on trusty using cs:trusty/wordpress-5
- set annotations for wordpress
- create offer my-offer using apache2:apache-website
- grant user admin admin access to offer my-offer
- add unit apache2/0 to new machine 0
- add unit wordpress/0 to new machine 1
Deploy of bundle completed.

$ juju export-bundle
series: trusty
applications:
  apache2:
    charm: cs:apache2-26
    num_units: 1
    to:
    - "0"
  wordpress:
    charm: cs:trusty/wordpress-5
    num_units: 1
    to:
    - "1"
    annotations:
      enc: bXktaW5jbHVkZQ==
      raw: my-include
machines:
  "0": {}
  "1": {}
--- # overlay.yaml
applications:
  apache2:
    offers:
      my-offer:
        endpoints:
        - apache-website
        acl:
          admin: admin

Further Reading

1 Like