Reviewing a Juju Charm is a process that can easily be broken down into the following parts:
- Identifying what to review
- Setting up a branch of the charm
- Charm Information Review
- Charm Deployment, Configuration and Testing
- Gathering / Submitting Your Results
When determining what charm (or merge request for a charm) you should review, prioritize whichever you think best achieves the goal of helping people enjoy getting things done in Juju. That might be the newest ones, neglected patches, easy patches, or those from new contributors. Take a look at the Review Queue to best determine what needs to be done!
Let's get started with setting up a branch of the charm. The process below highlights how you would branch a charm that is for Ubuntu 12.04 (Precise), but the branching process is essentially the same for other series such as Ubuntu 14.04 (Trusty).
mkdir /tmp/precise cd /tmp/precise
Above we created a temporary directory for Precise. If you are reviewing a
charm for Ubuntu 14.04, you'd replace
If the charm is already available in the Juju Charm Store, do the following command to get the charm:
charm get charm-name
If you are reviewing a merge request for an existing charm, in order to get the merge proposal applied to the current charm store version, do:
bzr merge lp:~the-username/charms/precise/charm-name/trunk
If the charm is not already available in the Juju Charm Store, do the following command to get the charm:
bzr branch lp:~the-username/charms/precise/charm-name/trunk charm-name
Like when creating the temporary directory, the
precise part can be
replaced with the series relating to the charm that is being reviewed.
Now that we have set up / branched the charm and are in the charm's directory, we need to run the following command:
The proof command validates that charm conforms with the Charm Store Policy. It programmatically ensures that the charm structure, layout and files conform to policy. The tool will output particular information with a level of severity.
If you come across errors or warnings (starting with
these are typically major issues and will result in a broken charm as well as
breaking Charm Store Policy. We also recommend you
check for the presence of copyright information as well as the charm's icon and
ensure it follows icon specification.
If the charm proof results in errors or warnings and you still feel that this charm is likely to be deployable, continue on with the review. Just be sure to note that the charm, as it stands, breaks Charm Store Policy and will not be accepted in its current form.
Understanding the purpose of the charm is crucial for both those that are reviewing as well as for those that may want to deploy the charm. We recommend the charm's README have the following information:
- What is the service?
- What configuration options does it provide as well as suggested usage noting defaults.
- What files does it retrieve from the Internet
- Instructions on how to deploy the service and scale it out.
- How the charm should be used in relation to configuration options and relations.
- Support including contact and upstream project information.
Make note of sections of the README that need improvement or are missing.
Take a look at the charm's config.yaml file, using the Charm Configuration document for reference. We also recommend you cross-reference it with the README to make sure the options in the README are defined in the config.yaml and vise-versa.
Inspect the charm's metadata.yaml file and use the Charm metadata document as reference.
Reviewing a charm's code is an optional step for community reviewers. If you feel comfortable reviewing the charm's code, here are some things to watch out for in the charms code:
- Not allowing users to set any applicable passwords with config-set.
- When downloading files from the Internet, not cross-referencing with hashes (ex: md5). Note this isn't necessary if the charm is using a version control system like git, since they typically have built-in file verification.
- Not using
set -euxin Bash scripts, which helps detect failed execution, thereby allowing Juju to more accurately detect a failed hook.
If a charm has tests (you can determine if it does by checking for a "tests" folder), run the command below and verify the charm that way:
juju test -v --set-e
If a charm does not have tests, you will need to manually deploy it.
We are going to cover some basic elements to deploying the charm you are reviewing. For a more in-depth look at deploying charms, go to the Charms Deploying page.
While using the README as a reference, deploy the charm using the command below on your local environment.
juju deploy --repository=../../ local:precise/charm-name
Alternatively, you can set JUJU_REPOSITORY and deploy like the following:
export JUJU_REPOSITORY=/tmp juju deploy local:precise/charm-name
If the local deployment is successful, continue to the configuration section.
Reference the config.yaml as well as the README to determine what configuration options are available for the charm. Test out changing the charm configuration by doing something like the following:
juju set charm-name key=value
If the configuration of the charm successfully changes and the charm's README makes note of possible relations with other charms, test adding and removing the relations multiple times. Doing so will test for idempotency, ensuring a hook can be called repeatedly and making sure the departed and broken hooks are fired correctly.
juju add-relation charm-name other-charm-name juju remove-relation charm-name other-charm-name
Let's quickly verify that the charm is correctly running by using SSH to jump into the machine the charm is running on.
juju ssh charm-name/0
ps to show if the charm's process is running. Some
services status would also be available with
sudo service name status
sudo service apache2 status).
If the charm's configuration options are written to the service's configuration files, check that file for the values you set earlier. Check the hooks to see which ones are written to configuration files (if applicable at all).
Gather the information that you have obtained from the charm review, such as whether the charm proof passes or has issues, if the README is understandable and thorough, if it successfully deploys, configuration and relations work, etc.
Post that information to the bug report or merge request, starting off with a "Thanks" no matter the outcome of the review. If you are a community member and/or contributor, you can leave your general approval or disapproval based on your findings. Normally people use "+1 LGTM" to indicate approval. Of course, in moments of disapproval, we suggest posting information as to why you disapprove.
If you are a ~charmer or wishing to become a ~charmer, make sure you are applying the Reviewers Guidelines.
First off, thank you for your review of the charm. Your review helps improve the Juju community as a whole and we appreciate your time and effort. If you've found that you are ready to be part of the ~charmers group and want the responsibilities of a member of the ~charmers team, we recommend you seek out how to apply for membership to the team via #juju on IRC (Freenode) and on the Juju mailing list.