Install of supporting tools also setups minikube

[mlieberman85]

00-setup-minikube.sh installs the support tools like jq along with installing minikube and setting it up. This means if someone has an external cluster they still need to set up a local minikube if using the install scripts.

[sudo-bmitch]

Are you looking to separate the other prerequisites out in a separate script, or make the minikube setup only happen when kubectl cannot connect to a manager node?

[mlieberman85]

Ideally, I would love to figure out some way to do this like some other projects. e.g.

1. Dev tools install (installs minikube but doesn't set it up)
2. Dev FRSCA install (i.e. minikube)
3. Non-local FRSCA install

I separate 2 and 3 here because as we are developing out FRSCA there's inevitably options we're keeping simple for a Dev install but probably want to allow lots of options to tweak on a non-local install.

[sudo-bmitch]

Restructuring the scripts could look like:

1. Install prereqs (we document these, useful for CI and quickstarts, but most will skip)
2. Create dev k8s cluster (using minikube, skipped by anyone with their own cluster in the cloud)
3. Deploy enterprise assumptions (registry, Git, Spire, Vault)
4. Deploy FRSCA (admission controller, tekton, chains, tasks, pipelines, and integration with external tooling)

If 3 is skipped, we'll need a way to inject a lot of configuration into 4, or leave that up to an exercise for the user. But I do like the idea of separating out those assumptions to make it clear what organizations should provide outside of the FRSCA cluster.

[mlieberman85]

Yep. Might be worthwhile to talk through some of this in #frsca slack room and maybe a call. I think there are some quick things we can do now while figuring out some of the other things. e.g. create a container or flatpak or something for the dev tools like cosign. Installing to folks' /usr/local/bin is potentially bad if folks already have tools. Would love something like a chroot or something.