File 'metadata.yaml'

doc
21

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.

22

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.

23

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.

24

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

25

Hello there,

Missing the icon configuration in the official docs.

26

@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?

27

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

28

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?).

29
30

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

31

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.

32

Could this mention what the default is?

33

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

34

Now fixed, thanks :slight_smile:

1 Like
35

From juju 3.5.0 the containers stanzas now support controlling the uid/gid of pebble:

containers:
    <container name>:
        # (Optional) UID to run the pebble entry process for this container as.
        # Can be any value from 0-999 or any value from 10,000 (values from 1000-9999 are reserved for users).
        # Default is 0 (root). Added in Juju 3.5.0.
        uid: <unix UID>

        # (Optional) GID to run the pebble entry process for this container as.
        # Can be any value from 0-999 or any value from 10,000 (values from 1000-9999 are reserved for user's primary groups).
        # Default is 0 (root). Added in Juju 3.5.0.
        gid: <unix GID>
2 Likes
36

From juju 3.6.0 the top level field charm-user is added to control what user the charm is run under. This is only supported on kubernetes, on machines it has no effect as of 3.6.

It supports three values: root, sudoer and non-root.

  • charm-user: root runs the charm as the root user.
  • charm-user: sudoer runs the charm as a user that can use sudo to run commands as root.
  • charm-user: non-root runs the charm as a user that is not root and does not have access to sudo.
1 Like