File 'metadata.yaml'

[jnsgruk (Jon Seager)]

@michele-mancioppi

I think we should have a description field for a relation, that would explain the intent behind the relation, e.g., “enabling scrape of the /metrics endpoint by technology like Prometheus that supports the OpenMetrics format”. This information would be extremely valuable for a contributor approaching a charm codebase, as well as CharmHub, when we start displaying with which other charms does this one interoperate.

@niemeyer @jameinel this doesn’t seem like a bad idea to me. Adding a description field to the spec won’t require any work Juju/OF end, but could be used by Charmhub for displaying some context around the relations a given charm supports?

[jameinel (John A Meinel)]

I definitely like the idea of having a description field for how this charm interacts with that relation.

[michele-mancioppi]

For the record, the description field for the relation would be used to power the “Integration description” on the WIP CharmHub Integrations page.

[jnsgruk (Jon Seager)]

There have been some recent discussions about making some additional metadata fields available for links associated with a given charm, as part of a wider discussion about improving charm documentation.

The main purpose of this, would be to provide simple way for charm authors to point to the upstream website, issue tracker and source code for the charm. Support for this is currently mixed: charm authors can use the publisher page to set a homepage and contact link, but not an issue tracker - and some older (imported) charms have bought their issue tracker along with them from the older charm store.

The snapcraft folks actually already tackled this problem (spec).

We already have the maintainers field, which is analogous to snapcraft’s contact field. My proposition is that we add the fields website, issues and source-code to this spec. This would then enable the store and charmhub folk to read this data and use it to display relevant links on the various charm pages on Charmhub consistently across all charms if it is present?

/cc @jameinel @roadmr @jkfran @gomboli @danieleprocida @hollyhall

[roadmr (Daniel Manrique)]

The in-progress work for snaps will also benefit Charmhub, and the following URL fields will be available :

“donations” “contact” “issues” “website” “source”

I believe this covers the ones you proposed.

• Daniel

[jnsgruk (Jon Seager)]

Ah interesting - so if we stick with those names, the store will natively understand them from metadata.yaml?

[mcjaeger (Michael Jaeger)]

Please take into account, that when displaying bundles like a charm on charmhub.io, it would be consistent, if these fields would be supported as well for these.

Right now the metadata.yaml does not appear to be part of the bundle and as consequence, info given there would not work for bundles.

[sed-i (Leon)]

@jnsgruk

      # (Optional) Minimum size of requested storage in forms G, GiB, GB. Size 
      # multipliers are M, G, T, P, E, Z or Y.

Might be worthwhile also clarifying if Juju takes binary, decimal or legacy binary notation (ref).

Also might be worthwhile mentioning that minimum-size is in fact statefulset.spec.volumeClaimTemplates[].spec.resources.requests.storage.

[swalladge (Samuel Walladge)]

@jnsgruk

peer:
    super-replicas:
        interface: super-replicas

Is it peer or peers? There’s peer in the spec here, but charms in the wild seem to use peers. eg. in charm-vault.

[jnsgruk (Jon Seager)]

Oops, thanks for spotting! I’ll fix that now!

[paulomachado]

Hello there,

Missing the icon configuration in the official docs.

[hloeung (Haw Loeung)]

@mcjaeger reached out to me to update the ubuntu-repository-cache charm to use the latest charm metadata reference.

I changed the maintainer to:

maintainer:
  - Ubuntu Repository Cache Charmers, Canonical <ubuntu-repository-cache-charmers@lists.launchpad.net> 

But now charmcraft pack fails as follows to build the charm:

2022-07-25 14:29:23.302 :: E: Maintainer field must not be a list

Not sure if the charm metadata reference doc should be updated or a bug filed against charmcraft?

[hloeung (Haw Loeung)]

Turns out it was maintainer vs. maintainers. Should the documentation include maintainer?

[barryprice]

I think each field recognised by the tooling should be defined in the spec, perhaps with a note if it’s deprecated (which I assume maintainer is, in favour of maintainers?).

[erik-lonroth (Erik Lönroth)]

Would an example metadata.yaml for subordinate charms be possible to include in the docs?

[nuccitheboss (Jason Nucciarone)]

@jnsgruk

The charm deploys iff the model runs agent binaries with the specified Juju version(s).

@jnsgruk

The charm deploys iff the underlying substrate for the model is Kubernetes.

Is the iff in the above sentences short-hand for if and only if? It might be better to fully write out if and only if rather than iff since not everyone reading through this documentation may have a strong mathematical background. IFF can mean different things to different people based on their background. For example, there is an identification system named IFF, and there is a prominent US company that goes by IFF. I only see “iff” used in the sections quoted above in this documentation page.

[mthaddon (Tom Haddon)]

@jnsgruk

# (Optional) True if the charm is meant to be deployed as a subordinate to a 
# principal charm
subordinate: true | false

Could this mention what the default is?

[tphan025 (Trung Thanh Phan)]

@jnsgruk

peer

# (Optional) Mutual relations between units/peers of this charm
peer:
    # Each key represents the name of the relation as known by this charm
    <relation name>:

        # (Required) The interface schema that this relation conforms to
        interface: <interface name>

        # (Optional) Maximum number of supported connections to this relation
        # endpoint. This field is an integer
        limit: <n>

        # (Optional) Defines if the relation is required. Informational only.
        optional: true | false

        # (Optional) The scope of the relation. Defaults to "global"
        scope: global | container

Hi, as someone mentioned above, this should be “peers” and not peer. The charm won’t generate the corresponding events if this key is not correct.

Thanks, Thanh

[jnsgruk (Jon Seager)]

@tphan025

Hi, as someone mentioned above, this should be “peers” and not peer. The charm won’t generate the corresponding events if this key is not correct.

Now fixed, thanks