-
Notifications
You must be signed in to change notification settings - Fork 162
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
Support Importing OCI Components #1060
Comments
What is the difference between how How should we specify the key for signing OCI components? |
Some ideas after talking with @jeff-mccoy OCI LayersThe current implementation of how Zarf packages get uploaded via an OCI object is using When importing a component, zarf pulls the component definition from the imported zarf package and does some adjustment to the definition to make it work in the package (e.g. adjusting paths based on where the current zarf.yaml lives). Slim Zarf PackageOne idea was to have a slim zarf package that just contains the metadata for the component definition, but was not packaged with artifacts, just files and manifests. When importing this component from an OCI object like this, the consumer of the component would have pointers to all the data needed to build its package without the time/complexity of pulling a (potentially multiple GB) artifact repo Cons of this approach:
Leverage OCI Layers more effectivelyOCI Layers have a lot of power. There are efficiencies gained by leveraging layers in storing container images by allowing the same changesets to be shipped independent of the entire image itself. There could be comparable efficiencies within zarf packages by leveraging layers, but the implementation of how best to do this is unknown without more exploration:
|
Something that may make sense to mesh well with also hosting the images on the same registry would be:
This would enable component reuse (assuming new manifests/values weren't injected on a compose) and should enable images to exist as actual pull-able images and as parts of a larger zarf package. The big thing there would be what parts of composed components get overwritten/added to that could make sense to be their own layers - for example datainjections would likely never be overwritten by a downstream component and could take up GBs of space. repos are similar too since they can be GBs in size as well, and again I haven't seen an example of that field changing through composability. Charts may be another "data" piece as well. |
Also for reference the current Zarf tarball breakdown looks like this:
|
Thinking more about some use cases, and I think we'll also need to support pulling from private OCI registries as well. When pulling images from private registries, Zarf leverages the docker credentials file. That could be a comparable paradigm here where the environment used for building the artifact would need to log in with docker to the OCI registry to pull the zarf package |
As another note if we want the BB compose to work we will also need it to be added to |
## Description When using a zarf.yaml to extend an existing bigbang definition like: ```yaml components: - name: cocowow required: true import: path: ../defense-unicorns-distro name: bigbang extensions: bigbang: version: "###ZARF_PKG_VAR_BIGBANG_VERSION###" valuesFiles: # look at imports and then merging here for composition - ../values/authservice.yaml - ../values/keycloak.yaml ``` Zarf ignores the provided values files in this zarf.yaml ## Related Issue Relates to #1060 ## Type of change - [x] Bug fix (non-breaking change which fixes an issue) - [ ] New feature (non-breaking change which adds functionality) - [ ] Other (security config, docs update, etc) ## Checklist before merging - [ ] Test, docs, adr added or updated as needed - [ ] [Contributor Guide Steps](https://github.com/defenseunicorns/zarf/blob/main/CONTRIBUTING.md#developer-workflow) followed --------- Signed-off-by: Tom Runyon <tom@defenseunicorns.com> Co-authored-by: Wayne Starr <Racer159@users.noreply.github.com>
Moving back to milestone v0.26.0 (m3) to allow more time to refactor. |
Is your feature request related to a problem? Please describe.
As a Zarf package developer I would like to be able to import centrally located zartifacts from an OCI registry.
Describe the solution you'd like
Ability to specify an OCI address in the import:
Would perform the same import as though that zarf.yaml for the artifact was local.
The text was updated successfully, but these errors were encountered: