linode / linode/apl-core

server.additionalApplications is silently dropped, blocking GitOps bootstrap

Open
#3,396 2 comments 0 reactions 0 assignees View on GitHub
bug community on hold
Dominant language
Go Template
Stars
2.3k
Forks
186
Avg merge
3d 11h
Merged PRs (30d)
66

Description

**Describe the bug:**
Setting Argo CD Applications via `apps.argocd._rawValues.server.additionalApplications` is silently ignored — the values are accepted and merged into the argo-cd chart, but no `Application` is ever created, with no error or warning.

This matters because it is **the only install-time mechanism for apl to seed an Argo CD Application**. We use it for the single most important bootstrap step: have apl seed *one* root "app-of-apps" `Application` that points Argo CD at our GitOps repo. That one Application is what makes Argo CD start reconciling the entire platform from Git (foundation NetworkPolicies, AppProjects, the ESO `ClusterSecretStore`, and all per-component Applications). Without it, apl finishes its helmfile, Argo CD is running — and then **sits idle**: it has no idea our GitOps tree exists, so ESO CRDs, foundation NetworkPolicies, AppProjects, etc. never appear.

Root cause: apl-core bundles **argo-cd chart `9.5.21`** (`charts/argocd`, appVersion `v3.4.3`), and that chart major **removed** `server.additionalApplications`/`server.additionalProjects` (its README: "moved to `argocd-apps`"). apl-core does **not** bundle or deploy the replacement `argocd-apps` chart, and nothing in `values/argocd/*.gotmpl` re-implements it. So there is currently **no working values path to declare additional Argo CD Applications/Projects through apl** — the `_rawValues` passthrough merges the key faithfully, but the destination chart no longer reads it.

**To Reproduce**
Steps to reproduce the behavior:
1. Install apl via the `apl` chart (apl-operator), letting its helmfile install argo-cd (chart `9.5.21`).
2. In your values, set an Application under the documented passthrough, e.g.:
```yaml
apps:
argocd:
_rawValues:
server:
additionalApplications:
- name: guestbook
namespace: argocd
project: default
source: { repoURL: https://github.com/argoproj/argocd-example-apps, path: guestbook, targetRevision: HEAD }
destination: { server: https://kubernetes.default.svc, namespace: guestbook }
```
3. Let apl-operator run the helmfile to completion.
4. `kubectl -n argocd get applications` → the `guestbook` Application is **absent**. The rendered argo-cd values contain `server.additionalApplications`, but no resource is produced and no error is surfaced.

**Expected behavior:**
A supported, install-time, values-native way for apl to seed Argo CD `Application`/`AppProject` resources — so an integrator can point Argo CD at their own GitOps repo with a single root Application, declared entirely in apl values. Concretely, either: (a) `apps.argocd._rawValues.server.additionalApplications` keeps creating the declared Applications/Projects (back-compat), or (b) apl bundles/deploys `argocd-apps` and exposes an equivalent key. Whichever path, an unsupported/removed key must not be **silently accepted** — it should be honored or rejected, not a no-op.

The install-time requirement is essential: at bootstrap, Argo CD does not yet exist to reconcile an `Application` CR applied from outside, so the seed Application has to be rendered **by the argo-cd chart itself**, present the moment Argo CD starts. `server.additionalApplications` was exactly that; nothing else in apl currently fills the gap.

**Screenshots:** N/A (CLI/declarative — see the empty `kubectl get applications` output in step 4).

**Cluster(s):**

- Cloud: Linode / Akamai (LKE-E)
- Cluster: platform support-services (reproducible on any fresh cluster)

**Versions:** (seen in console's `/settings`)

- Core Version: __
- Console Version: N/A
- API version: N/A
- Bundled sub-chart (root cause): argo-cd `9.5.21`, appVersion `v3.4.3` (`charts/argocd/Chart.yaml`)

**Desktop:** N/A (not a UI/browser issue)

**Smartphone:** N/A

**Additional context:**

*Why we need `apps.argocd._rawValues.server.additionalApplications` specifically:*

- **It closes the GitOps bootstrap gap.** apl installs Argo CD but offers no values-native way to tell that Argo CD about the integrator's own repo. One seeded app-of-apps `Application` is the entire handoff: from it, Argo CD reconciles the whole platform tree (foundation NetworkPolicies, AppProjects, ESO `ClusterSecretStore`, per-component Applications) from Git. One value bootstraps everything else.
- **It's the only mechanism that works *at install time*.** The seed Application must exist before/at the moment Argo CD starts — there's no running Argo CD yet to reconcile a CR applied afterward. `server.additionalApplications` is rendered by the argo-cd chart during its own install, so there's no external actor and no ordering race. Removing it leaves no in-chart path.
- **The alternative is exactly what a GitOps platform should eliminate.** Without it, we must push the root `Application` + `AppProject` + Argo CD repository-credential `Secret`s imperatively from outside the cluster (Terraform/CI holding a kubeconfig and PATs, with a CRD-wait that races apl-operator's helmfile installing argo-cd). That re-introduces out-of-band, kubeconfig-holding bootstrap on top of a platform whose whole value proposition is in-cluster GitOps reconciliation.

*Root-cause evidence in apl-core `main`:* `helmfile.d/snippets/common.gotmpl:7` + `helmfile.d/snippets/templates.gotmpl:2-6` (the `_rawValues` passthrough works and targets `../charts/argocd`); `charts/argocd/Chart.yaml` (argo-cd `9.5.21`); `charts/argocd/README.md:650-658` (the removal/migration note); no `charts/argocd-apps` and no `argocd-apps` release in `helmfile.d/`; `grep additionalApplications charts/argocd/templates/` returns nothing.

Contributor guide

Open the contributing guide

Research direction

Read helmfile.d/snippets/common.gotmpl and helmfile.d/snippets/templates.gotmpl to trace the _rawValues passthrough, then inspect charts/argocd/Chart.yaml, charts/argocd/README.md:650-658, and charts/argocd/templates/. Compare this with the absence of charts/argocd-apps and an argocd-apps release in helmfile.d/. Done means a supported install-time values path creates the requested Application/AppProject resources or rejects the removed key instead of silently ignoring it.

Written by the indexing model from the issue text.

Assessment

Tech stack
kubernetes
Domain
devops, infrastructure
Issue type
Bug
Difficulty
5/5
Estimated time
Over a week
Activity status
Quiet
Clarity
Mostly clear
Newbie friendliness
38/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.