-
Notifications
You must be signed in to change notification settings - Fork 166
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Expansion of package metadata fields #2970
Comments
We are actually already planning to get rid of several metadata fields in favor of annotations. See #2636. This change will occur when the new Zarf schema, v1beta1, is released. We actually do have some code to create annotations at the moment, but it's not intuitive to the user. Lines 91 to 113 in 93128e8
There is an easier way to get annotations than grabbing the zarf.yaml from the layer, you can use the manifest config instead. I will say I'd be in favor of changing the manifest config to be a Zarf package rather than having the zarf.yaml as a layer. That is mostly separate issue, but would make accessing the file easier I agree we should also add annotations to the index and manifests. We could do something similar to a regular container image see - busybox. |
Created #2976 to track the ask for annotations on indexes / manifests |
Is your feature request related to a problem? Please describe.
There is a variety of metadata we wish to capture and present in
uds-marketplace
. Presently, we are supplementing Zarf package metadata with YAML configs (source). You can also see a working list of metadata fields in this spreadsheet.We wish to move most or all of this data into the
ZarfPackageConfig
managed within individual package repos.Describe the solution you'd like
Much of the metadata we wish to capture could be populated on existing
ZarfPackageConfig.metadata
fields, but before we go do that we'd appreciate:Clarification of Existing Metadata
ZarfMetadata.description
: "Additional information about this package."ZarfMetadata.url
: "Link to package information when online."uds-package-postgres-operator
anduds-package-valkey
. Links to upstream GitHub project.ZarfMetadata.image
: "An image URL to embed in this package (Reserved for future use in Zarf UI)."icon
to avoid overloading the ambiguous termimage
ZarfMetadata.authors
: "Comma-separated list of package authors (including contact info)."ZarfMetadata.documentation
/ZarfMetadata.source
: "Link to package <documentation|source> when online."ZarfMetadata.vendor
: "Name of the distributing entity, organization or individual."authors
, consider enforcing strict compliance with RFC 5322 Address SpecificationAdditional Metadata Required by
uds-marketplace
title
: pretty (titlecase) version of the upstream software product nameicon
: could useZarfMetadata.image
if it were wired upvendor-url
: no obvious place for this currentlydescription
: long-form description of upstream software producttagline
: short-form descriptionlink
: additional links not captured by well-defined metadata fields (helm chart source, reference architecture, etc)contracting vehicle
: details TBDpricing model
: details TBDcategories
: a loosely standardized list of categoriesFIPS compliant image(s)
: whether the images included in the package are known to use FIPS validated cryptocontrol mapping
: NIST SP 800-53 control mappingsimpact level
: details TBDinfrastructure
: list providers the application depends on or supports (ex. if GCP or AWS specific APIs are required)Given that the existing fields seem to be derived from the OCI image spec's pre-defined annotation keys, perhaps we should consider dropping these metadata fields entirely and provide a more direct means of specifying image annotations:
Artifact Hub has a number of annotations they support, so perhaps this is the way to go for the evolving list of UDS-specific metadata we require.
Making Metadata Easier to Consume
Right now the only way to access this metadata from a package published in OCI is to:
index
->manifest
->.layers[]
.annotations["org.opencontainers.image.title"] == "zarf.yaml"
It would be great metadata were made available:
The text was updated successfully, but these errors were encountered: