We just had a session on improving what used to be called the Charm Quality Guidelines, which really are charm features, so we went bullet by bullet and reworded a bunch of them to make sense, and consolidated the sections, here's what we came up with:
Proposed Bullets: Data Handling: Handles the service's user data Provides backup mechanism Provides a restore mechanism Provides encryption Secure: Contains a well tested AppArmor profile Doesn't run as root Per instance or service access control Defaults to secure communication Reliable: Fails gracefully if upstream source goes missing Contains a suite of integration tests with the charm that pass Configuration options have safe defaults Scaleable: Responds to add-unit based on the service's needs Responds to remove-unit based on the service's needs Reuses existing charms for supporting services Upstream Friendly Follow deployment recommendations from upstream best practices Provide up to date versions of the upstream release Flexible Exposes version of service as a config option to allow easy upgrades Adheres to the coding guidelines of the language your charm is written in Exposed configurations are subsets of opinionated deployments Allow installation from pure upstream source Allow installation from your local source Allow installation from PPA (if available) Allow installation from the Ubuntu repository Easy to Deploy (these will move to policy soon, so consider this a temporary category) README with examples of use for a typical workload README with examples of use for workloads at scale README with examples of use recommend best-practice relationships -- Jorge Castro Canonical Ltd. http://juju.ubuntu.com/ - Automate your Cloud Infrastructure -- Juju mailing list [email protected] Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/juju
