Using idpbuilder in lieu of our quick-start script

[kirederik]

In #112, @cmoulliard suggested we could use idpbuilder to spin up the quick-start environment for Kratix.

@abangser added

As @kirederik shared, our quick-start has been under development from before the idp-builder was ready to go so this is a matter of investing in a migration at this point.

I have done some quick research and while Kratix runs easily on top of the current idp builder, there are a number of things we need to consider before moving to use idp builder as a dependency for our project:

1. The github warning WORK IN PROGRESS: This tool is in a pre-release stage and is under active development. is concerning. Do you have a sense of when you may release a stable v1?
2. We depend heavily on a multi-cluster setup. I believe this has been discussed, but I did not find a corresponding issue in your repo. If we move to idp builder now, we will likely be managing the clusters with different setups which is not ideal for our maintenance.
3. Based on our customers, we need to be able to equally use MinIO in lieu of Gitea as a state store, and Flux in lieu of ArgoCD for GitOps. Again, I know that more flexibility in the packages provided is in the works, but I believe this is not yet fully designed/implemented. We can likely work around this by just double installing, but this is a consideration before switching.
   I don't believe any of these are long term blockers, but hopefully they provide a bit of transparency as to why it may not be an immediate switch. We are actively thinking about this and will keep you posted and of course continue to excitedly follow the idp builder project!

and

@jessesanford it would be great to hear how you might use Kratix on an IDP Builder built cluster as I believe there are no blockers here. As I mentioned in the above message to Charles, use in the project for our local testing may need a bit more research/investment, but for use by others we just need to provide an Argo App that could be an additional package for you. I have tested it by manually installing Kratix with the following commands and it appeared healthy:

version=$(curl -Ls -o /dev/null -w %{url_effective} https://github.com/cnoe-io/idpbuilder/releases/latest)\nversion=${version##*/}\ncurl -L -o ./idpbuilder.tar.gz "https://github.com/cnoe-io/idpbuilder/releases/download/${version}/idpbuilder-$(uname | awk '{print tolower($0)}')-$(uname -m | sed 's/x86_64/amd64/').tar.gz"\ntar xzf idpbuilder.tar.gz\n\n./idpbuilder version\n# example output\n# idpbuilder 0.3.0 go1.21.5 linux/amd64
./idpbuilder create
kubectl apply --filename https://github.com/cert-manager/cert-manager/releases/download/v1.12.0/cert-manager.yaml
kubectl apply --filename https://github.com/syntasso/kratix/releases/latest/download/install-all-in-one.yaml
kubectl apply --filename https://github.com/syntasso/kratix/releases/latest/download/config-all-in-one.yaml

Let me know if this unblocks what you are up to, or if you are looking to move further, for example adding Kratix as an example additional package and of course we can collaborate to help with whatever you need!

@cmoulliard

You can use your own kind config file when you create a cluster using the following idpbuilder command - https://github.com/cnoe-io/idpbuilder/tree/main?tab=readme-ov-file#example-commands

./idpbuilder create --build-name local --kind-config ./my-kind.yaml

Creating this discussion thread to continue the conversation