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)