Replies: 2 comments 2 replies
-
It's not clear if the desire for this feature is:
From my current experience using and deploying zarf, the latter has come up several times while developing a package for BigBang. If you really want to focus on the first one, I'll move the rest of this comment into its own issue for conversation. For instance, if I were to be playing around with values files as I debug adding a feature, this is the workflow I've been using:
Before using zarf, i would literally just run something like this: helm upgrade -i bigbang --create-namespace oci://registry.dso.mil/platform-one/big-bang/bigbang/bigbang --version 1.54.0 \
-n bigbang \
-f bigbang/credentials.yaml \
-f bigbang/loki.yaml \
-f bigbang/ingress-certs.yaml \
-f bigbang/kyverno.yaml So here's a situation where it takes 5:30 to update an environment to debug, when I really just needed to run a I think there might be situations where we can get some better profiling data from zarf to see where the time is spent in both the
|
Beta Was this translation helpful? Give feedback.
-
With the recent OCI feature, I think pushing to OCI and deploying from OCI will already reuse docker image/layers and zarf components between updated packages. This means I'm not quite sure what all goes on during
If the user can somehow intelligently mirror a docker registry into their airgap you also have incremental data transfer across the airgap today: only changed images and zarf components will be transferred. |
Beta Was this translation helpful? Give feedback.
-
Overview
There has been desire in the community to produce differential packages for Zarf updates to ease Day 2 operations and development cycle times. This discussion is to talk about the potential user flow / implementation for this feature. Notionally this could look like the following.
Flow
Given the below future Zarf package configuration (and associated local manifests - see
examples/flux-test
in the Zarf repo):You could then run the following:
zarf package create . --differential oci://ghcr.io/defenseunicorns/podinfo-flux:6.3.2
This would pull the
zarf.yaml
layer from the specified OCI-published version and compare each component's ociimport
s first, then it would compose the package and compare therepo
s, andimage
s and would remove any that were tagged same (while keeping allchart
s,file
s,manifest
s,actions
and other keys - if animage
or arepo
did not have a tag (or sha) it would be retained (i.e. if a full git repo or branch was specified)).Once finished with that filtering, Zarf would proceed with package create as normal and would create differential Zarf package tarball with a name such as:
This could also be published to
oci
with:Which would also tag this as a differential package:
If we were to inspect the package we would see that it has a new build key to mark it as
differential
, has the flux key omitted, and has adifferentialMissing
key of all omittedrequired
components to display a warning onzarf package deploy
if a component is not yet in cluster.Notes
Beta Was this translation helpful? Give feedback.
All reactions