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.

Sign up for GitHub

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

Jump to bottom

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

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

Changes from 1 commit
Commits
Show all changes
2 commits
Select commit Hold shift + click to select a range
411a540
ADR for require no maintenance to keep bootstrapping cli up to date
waleedhammam Dec 14, 2023
d11bace
extend with options
waleedhammam Dec 14, 2023
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
86 changes: 86 additions & 0 deletions docs/adrs/0026-require-no-maintenance-to-keep-bootstrapping-cli-up-to-date.md
View file
Open in desktop
Original file line number Diff line number Diff line change
@@ -0,0 +1,86 @@
# 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 •
edited
Loading

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

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.

## Consequences

### Pros

- Values will always be up to date

### Cons

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