Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

ADR for require no maintenance to keep bootstrapping cli up to date #142

Draft
wants to merge 2 commits into
base: main
Choose a base branch
from
Draft
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
Original file line number Diff line number Diff line change
@@ -0,0 +1,102 @@
# 26. require no maintenance to keep bootstrapping cli up to date

Date: 2023-12-13

## Status

Provisional

## Context

Currently, CLI bootstrapping creates and manages WGE values [here](https://github.com/weaveworks/weave-gitops-enterprise/blob/d27d52cf1053d194a40e7652a570d810db552613/pkg/bootstrap/steps/install_wge.go#L49-L124). This means any update / breaking change happens to WGE values
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

as suggested during standup, i think it is worth considering other options. for example here there is a couple

a) refactoring the install wge step to the shape of terraform where we dont manage values. Something like consuming a helmrelease manifest as stated here. To generate and publish that manifest could be done as part of the release process (we have to do it as part of weaveworks/weave-gitops-enterprise#2213 )

b) how flux does it where flux v2.1.0 can only bootstrap flux for v2.1.0 so in this case refactoring install wge to just install the version that the cli belongs to. for example gitops-ee v0.38 only install v0.38, etc ...
see artifacts in https://github.com/fluxcd/flux2/releases/tag/v2.2.0 and https://github.com/fluxcd/flux2/blob/00c6ac81b9938e80a79c5b625b06cfb4f220c3db/pkg/manifestgen/install/manifests.go#L37

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

for tf form like, we can use OCI repository to have WGE chart, this could be added to the release process
like this one
release workflow

Copy link
Contributor

@enekofb enekofb Dec 18, 2023

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

you mean like publishing a oci repo with the different controller manifests, right? It sounds interesting over pull the indenpedent manifests. i also think that could also provide a more flexible / maintainable approach to install over existing helm dependency one

will lead to degraded bootstrapping process for users and maintaining it will require extra cost. Values should be kept up to date accordingly when they change in the WGE.

## Decision

### Options

#### option a) Fetching the values file from the corresponding version

example response for fetching the chart from [wge charts url](https://charts.dev.wkp.weave.works/releases/charts-v3)

```yaml
apiVersion: v1
entries:
mccp:
- apiVersion: v2
appVersion: 1.16.0
created: "2023-12-11T13:29:39.19014457Z"
dependencies:
- condition: cluster-controller.enabled
name: cluster-controller
repository: file://../cluster-controller
version: 1.0.0
- condition: templates-controller.enabled
name: templates-controller
repository: file://../templates-controller
version: 0.3.0
.
.
.
.
description: A Helm chart for Kubernetes
digest: 8d7bab57fd4a1e87112ff950c3b9f65d26df968006d7968af3d5abec843faa79
name: mccp
type: application
urls:
- https://s3.us-east-1.amazonaws.com/weaveworks-wkp/releases/charts-v3/mccp-0.38.1.tgz
version: 0.38.1
```

Example url for `v0.38.1` version: `https://s3.us-east-1.amazonaws.com/weaveworks-wkp/releases/charts-v3/mccp-0.38.1.tgz`

By downloading and uncompressing this file you will have the values file corresponding to the downloaded version

Example for `v0.38.1` `mccp/values.yaml`

```yaml
# Default values for mccp.
# This is a YAML-formatted file.
# Declare variables to be passed into your templates.

imagePullSecrets: []
nameOverride: ""
fullnameOverride: ""

images:
clustersService: docker.io/weaveworks/weave-gitops-enterprise-clusters-service:v0.38.1
uiServer: docker.io/weaveworks/weave-gitops-enterprise-ui-server:v0.38.1
.
.
.
.
.
.
```

After that, This values file will be converted to `map[string]interface{}` then update the specific values from installation like `oidc` values.

**Pros**

- Values will always be up to date

**Cons**

- Lost the structured values files
- Extra overhead for downloading / uncompressing the chart file



#### option B) Refactoring the `install wge` step to the shape of [terraform](https://github.com/weaveworks/weave-gitops-enterprise/blob/7a26044174a046fbf25e7f005b895f8a0a5400dc/pkg/bootstrap/steps/terraform.go)

where we dont manage values. Something like consuming a helmrelease manifest as stated [here](https://docs.gitops.weave.works/docs/enterprise/getting-started/install-enterprise/#configure-helm-chart-and-commit).
To generate and publish that manifest could be done as part of the release process (we have to do it as part of https://github.com/weaveworks/weave-gitops-enterprise/issues/2213)

#### option C) How flux does it where flux v2.1.0 can only bootstrap flux for v2.1.0

so in this case refactoring install wge to just install the version that the cli belongs to. for example gitops-ee v0.38 only install v0.38, etc ...
see artifacts in https://github.com/fluxcd/flux2/releases/tag/v2.2.0 and https://github.com/fluxcd/flux2/blob/00c6ac81b9938e80a79c5b625b06cfb4f220c3db/pkg/manifestgen/install/manifests.go#L37