The only file that must be present in a charm is
metadata.yaml, in the root
directory. A metadata file must be a valid yaml dictionary, containing at least
the following fields:
nameis the charm name, which is used to form the charm URL.
- It can only contain
-; must start with
a-z; must not end with a
-; and may only end with digits if the digits are not directly preceded by a space. Stick with names like
foo-bar-bazand you needn't pay further attention to the restrictions.
- It can only contain
summaryis a one-line description of the charm.
descriptionis a long-form description of the charm and its features. It will also appear in the juju GUI.
tagsis a descriptive tag that is used to sort the charm in the store.
Here's a valid metadata file:
name: mongodb summary: An open-source document database, and the leading NoSQL database description: | MongoDB is a high-performance, open source, schema-free document- oriented data store that's easy to deploy, manage and use. It's network accessible, written in C++ and offers the following features: - Collection oriented storage - easy storage of object-style data - Full index support, including on inner objects - Query profiling - Replication and fail-over support - Efficient storage of binary data including large objects (e.g. videos) - Auto-sharding for cloud-level scalability (Q209) High performance, scalability, and reasonable depth of functionality are the goals for the project.
With only those fields, a metadata file is valid, but not very useful. Charms for use in the Charm Store should always set the following fields as well, for categorization and display in the GUI:
maintaineris the name and email address for the main point of contact for the development and maintenance of the charm. Or, at least, it should be: in frequent practice, it's just a name. Please update your charms as you get the opportunity.
tagsis a list containing one or more of the following:
In almost all cases, only one tag will be appropriate. The categories help keep the Charm Store organised.
subordinateshould be set to true if the charm is a subordinate. If omitted, the charm will be presumed not to be subordinate.
peersdefine the various relations the charm will participate in.
- if the charm is subordinate, it must contain at least one
requiresrelation with container scope.
Other field names should be considered to be reserved; please don't use any not listed above to avoid issues with future versions of Juju.