I definitely like the idea of having a description field for how this charm interacts with that relation.
For the record, the description
field for the relation would be used to power the âIntegration descriptionâ on the WIP CharmHub Integrations page.
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
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
Ah interesting - so if we stick with those names, the store will natively understand them from metadata.yaml
?
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.
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
.
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.
Oops, thanks for spotting! Iâll fix that now!
Hello there,
Missing the icon
configuration in the official docs.
@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?
Turns out it was maintainer
vs. maintainers
. Should the documentation include maintainer
?
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
?).
Would an example metadata.yaml for subordinate charms be possible to include in the docs?
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.
Could this mention what the default is?
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
Now fixed, thanks
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>