Charm evaluation checklist

Charm publication > Charm evaluation checklist

You’ve made your charm publication ready. You’ve also published it. What’s next? Time to make it evaluation ready! That is, publishing a charm on Charmhub is just the beginning. Now that you’ve made it available to the broader open source developer community, you should plan to evolve it together with this community, so that it best meets everyone’s needs and standards. But what are these needs and standards? Which ones take priority? This document lists a core set of target capabilities for every software operator.

These standards keep evolving. Revisit this doc to get the latest updates.

Contents:

The charm has sensible defaults

A user can deploy the charm with a sensible default configuration.

Objectives Tips, examples, further reading
The purpose is to provide a fast and reliable entry point for evaluation. Of course, optimised deployments will require configurations. Often applications require initial passwords to be set, which should be auto-generated and retrievable using an action or Juju Secrets once available.

Hostnames and load balancer addresses are examples that often cannot be set with a sensible default. But they should be covered in the documentation and indicated clearly in the status messages on deployment when not properly set.

The charm is compatible with the ecosystem

The charm can expose provides/requires interfaces for integration ready to be adopted by the ecosystem.

Objectives Tips, examples, further reading
Newly proposed relations have been reviewed and approved by experts to ensure:

• The relation is ready for adoption by other charmers from a development best practice point of view.

• No conflicts with existing relations of published charms.

• Relation naming and structuring are consistent with existing relations.

• Tests cover integration with the applications consuming the relations.

A Github project structures and defines the implementation of relations.

No new relation should conflict with the ones covered by the relation integration set published on Github.

Getting started with relations in Juju

Discussion about consistency

The charm upgrades the application safely

The charm supports upgrading the workload and the application. An upgrade task preserves data and settings of both.

Objectives Tips, examples, further reading
A best practice is to support upgrades sequentially, meaning that users of the charm can regularly apply upgrades in the sequence of released revisions. How to upgrade applications with Juju

The charm supports scaling up and down

If the application permits or supports it, the charm does not only scale up but also supports scaling down.
Objectives Tips, examples, further reading
Scale-up and scale-down can involve the number of deployment units and the allocated resources (such as storage or computing).

Scaling applications with Juju

Note that the cited links also point to how to deal with relations when instances are added or removed:

SDK Docs - Relations

SDK Docs - Peer Relation Example

The charm is integrated with observability

Engineers and administrators who operate an application at a production-grade level need to capture and interpret the application’s state.

Objectives Tips, examples, further reading
Integrating observability refers to providing:

• a metrics endpoint,

• alert rules,

• Grafana dashboards, and

• integration with a log sink (e.g. Loki).

Consider the Canonical Observability Stack (COS) for covering observability in charms. Several endpoints are available from the COS to integrate with charms:

• Provide metrics endpoints using the MetricsProviderEndpoint

• Provide alert rules to Prometheus

• Provide dashboards using the GrafanaDashboardProvider

• Require a logging endpoint using the LogProxyConsumer or LokiPushApiConsumer

More information is available on the Canonical Observability Stack homepage.

Consider the zinc charm implementation as an example for integrations with Prometheus, Grafana and Loki.


Last updated a month ago.