Consolidate image strategy, wrap "utility-cluster" into components, use registry2 over containerd imports

[jeff-mccoy]

Okay so I have a really bad idea.... this will be a follow-on to #64, would like to get it complete before we cut this release with breaking changes. This would also help #16 and #17.

Now that we've streamlined much of this config and since @RothAndrew added the containerd mirroring a few weeks ago, I think we can actually really make this better. Basically I'm proposing we:

• Drop the use of containerd imports entirely, they aren't fun and are needlessly different than how we push to the utility cluster registry. This means there would only be one time of "image" in the zarf yaml and it would go to the registry
• Move the docker registry out of the "utility cluster" and make it a required agent for every deployment of zarf (appliance mode or otherwise). The overhead is minuscule and it simplifies a lot of what we do. The Big Bang and Utility Cluster examples use this concept already.
• Drop the "utilityCluster" key completely in the zarf config and allow those to be components as well since there will only be one type of image and repos can just be part of the component definitions
• 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
• Appliance mode zarf packages wouldn't see any changes to their actual yaml files

What that could look like for the Big Bang example:

[RothAndrew]

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?

[RothAndrew]

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?

[jeff-mccoy]

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.