Consolidate image strategy, wrap "utility-cluster" into components, use registry2 over containerd imports about zarf HOT 3 CLOSED

Sure if you want to use any other gitops engine, gitea would generically solve that. Adding flux is off the table but the utility service / gitops system should stay generic.

from zarf.

I think there's a good concept here, still getting a handle on what it all means. Here's my interpretation of what you're proposing:

1. We want to remove the ability to do local images (what used to be local.images: in zarf.yaml) since they rely on a special capability of k3s and we want to be more agnostic
2. Due to number 1, we need to depend on a private docker registry being present in each cluster if the package we want to deploy has images in it
3. due to number 2, we need to make the private docker registry part of the required stuff that we deploy when we do zarf init
4. When we do zarf package deploy, if it has images in it we will expect the private docker registry to be present. If the package doesn't have any images in it then it won't have that expectation.

Does that all sound right?

from zarf.

Change the wording of "utility cluster" to something else like "gitops" or similar since it will now only have gitea, this would really only show up in our docs + the zarf init wizard

What do you think about adding Flux as part of the gitops component? Is there any situation where you would want Gitea but not Flux?

from zarf.