Zarf dependence on existing StorageClass

[brandtkeller]

Is your feature request related to a problem? Please describe.

Zarf is unable to init against a cluster that does not contain a storageclass by default. RKE2 is a given example that will require deployment of resources to support a storageclass before zarf init will execute successfully.

Fundamentally, zarf should support a pattern (either logically or documented) that allows for the storageclass to be brought with the init package for the registry to use. Assuming the existence of one puts a burden on the true airgap deployment scenario.

Describe the solution you'd like

Given an empty cluster without any storage infrastructure, when zarf init is executed then zarf should allow a storageclass component to be included and used by the registry (Allowing for enhanced deployments of the registry such as HA)

Describe alternatives you've considered

Creation of a custom init package that performs the following:

• Deploy the zarf-injector
• Deploy the zarf-seed-registry w/o persistence
• Deploy the zarf-registry w/o persistence
• Deploy the zarf-agent
• Deploy a given storageclass and any required resources
• Re-deploy the zarf-registry with persistence
• Seed the registry, agent and storageclass images

Tested the above and currently incurring issues around image push auth. Either due to persistence or credential mis-match perhaps?

Additional context

May be related to #375

[joelcomp1]

So I have this working locally on a fork using a similar above construct . I added a step to a custom init package that after zarf-seed-registry w/o persistence installs the rancher local path provisioner (if your not using k3s already) and then after thats up re-install zarf-registry with persistence. I ran into this problem all the time on RKE2 as we use Longhorn but that doesn't help us for initial Airgap install. Let me know and I can post / put a pull request in.

[Noxsios]

Linking #1998 as this deals with similar StorageClass shenanigans