That would be very helpful! The relations (provides, requires, and peer) and containers are the only fields that do not have a description field.
AFAIK, the assumes functionality is implemented, but currently behind a feature flag. There has been a short term fix though, which means that you can deploy “charm only” charms on Kubernetes by just not specifying a containers map.
@achilleasa will be able to confirm when the assumes stuff lands, and we should update this doc with the supported options when that happens.
Thanks, I’ll give it a try.
My impression was that not specifying a container would need to be paired with assumes juju >= 2.9.18.
If you are using a recent 2.9 release you can enable support for enforcing assumes sections in charm metadata as follows: juju controller-config 'features=[charm-assumes]'.
If you enable the flag, juju show-model will also report the features that are supported on the currently active model.
To disable: juju controller-config 'features=[]'.
Juju will parse and store assumes blocks but will not actively enforce them unless the flag is set. We are currently working on a doc page for describing the supported set of features charms can assume and will be launching the feature once the docs have been completed.
To try this out, add an assumes section (see this example) to the charm metadata.yaml like:
assumes:
- k8s-api
The above syntax is quite flexible (you can nest requirements in any-of/all-of blocks and also provide version constraints) and is described in detail here.
Just wanted to let you know that we have completed the doc-related tasks for the assumes feature and, unless something changes, it will be going live with Juju 2.9.23.
@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?
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
3 Likes
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?).