search

cnoe-io / idpbuilder

Spin up a complete internal developer platform with only Docker required as a dependency.
https://cloud-native.slack.com/archives/C05TN9WFN5S
Apache License 2.0
183 stars 57 forks source link

Provide a way to customize core packages #126

Open nabuskey opened 10 months ago

nabuskey commented 10 months ago

Currently, there is no way to customize core packages other than editing the fiels in in-cluster git repositories. Even if you make changes to these files, they are overwritten if you run the idpbuilder again. We need to provide a way to customize these packages from CLI.

Currently we solve the chicken and egg problem by installing ArgoCD and Gitea without GitOps. This means we have two ways to provide this functionality.

  1. Install the core package manifests without GitOps by replacing the manifests that gets installed when we bootstrap. This means we have to ask the end user to provide manifests, not helm chart values or kustomizations, at runtime because we don't want to bring in helm or kustomization dependencies.
  2. Install the core package manifests with GitOps. This means we will install core packages with what we have in the binary no matter what. Once they are available, we will update these packages through GitOps. This could potentially cause some issues. For example, if the Gitea pod needs to be restarted, we will lose data (this itself probably needs to be solved).
cmoulliard commented 9 months ago

There are some issues no matter which approach we adopt unfortunately.

Nevertheless, the big advantage of the current approach where resources deployed are embedded is that an idpbuilder release "validates" the core packages as they are tested even partially.

If now, we allow the user to install their own core packages using a local folder, git repository, ftp server, etc, then we should mention that our idpbuilder tool cannot guarantee in this case that what they will deploy is 100% compatible with the release x.y.z of idpbuiler.

Remark: We should offer nevertheless the option to allow a under to install their own customized gitea and argocd at their own risk at the condition also that we document which are resources are needed, version supported, etc

If the idpbuilder contributors decide to adopt the second approach (= Install the core package manifests with GitOps), then we should in this case continue to embed them (and document where resources could be consulted) to support the offline mode where users don't have access to internet but only to internal git, ftp, etc servers within their company.