Juju documentation

Charm Quality Rating

People demand quality out of their tools, and the Charm Store is no different. So what does a good charm look like? These are some guidelines on what we think an ideal charm provides users. So we rate charms by the following criteria, and give them a score, up to 39.

Note: This is an ideal list of what we'd like charms to be. No charm today comes close to getting all of these points; it's a target we set for ourselves so we can determine how we can improve individual charms. It also gives contributors a general idea of where they can spend their time to fix something.

Reliable

9 Possible points

  • Deploy on every provider and pass provider tests
    • +1 AWS
    • +1 HP Cloud
    • +1 OpenStack
    • +1 LXC
    • +1 MAAS
    • +1 Check for integrity from upstream source
    • +1 Fail gracefully if upstream source goes missing
    • +1 Contain a suite of tests with the charm that pass
    • +1 Passes tests from Jenkins on jujucharms.com

Secure

4 possible points

  • +1 Contain a well tested AppArmor profile
  • +1 Conform to security policies of the charm store
    • Tight access control
  • +1 Doesn't run as root
  • +1 Per instance or service access control

Flexible

2 possible points

  • +1 Contain opinionated tuning options
    • Examples (depends on the service): "safe", "default", "fast", "real fast, not so safe"
    • Don't expose every configuration, pick that reflect real world usage
    • Make it so I don't have to read the book.
  • +1 Use existing interfaces with other charms
    • Highly relatable.

Handle Data

3 possible points

  • Integrate data storage best practices
    • +1 Backups based on service usage
  • Handle the service's user data
    • +1 Version control
    • +1 Automated snapshots and backup

Scaleable

5 possible points

  • +1 Responds to add-unit based on the service's needs
    • Configuration should not require additional steps to scale horizontally
  • +1 Be tested with a real workload, not just a synthetic benchmark
  • Encapsulate scalability best practices
    • +1 From upstream and existing devops for that service
    • +1 Community peer reviewed
    • +1 Have a configure option for most performant configuration if not the default

Easy to Deploy

7 possible points

  • Well documented README with examples of use
    • +1 for a typical workload
    • +1 for workloads at scale
    • +1 Recommend best-practice relationships
  • Allow installation of the service from ...
    • +1 Pure upstream source
    • +1 Your local source
    • +1 PPA (if available)
    • +1 The Ubuntu repository

Responsive to DevOps Needs

4 possible points

  • +1 Allow for easy upgrade via juju upgrade-charm
  • +1 Allow upgrading the service itself.
  • Proper maintainership
    • +1 Responsive to user bug reports and concerns
    • +1 Maintainable, easy to read and modify

Upstream Friendly

4 possible points

  • Follow upstream best practices
    • +1 Provide an option for a barebones "pure upstream" configuration
  • Should go lock-step with deployment recommendations
    • +1 Provide tip-of-trunk testing if feasible
  • Be cognizant of their release schedule
    • +1 Fresh charm on release day!
    • +1 Endeavour to be upstream's recommended way to deploy that service in the cloud (website mention or something)