obj.provider (linode): allow multiple buckets per consumer (Loki chunks/ruler/admin)
Nobody has claimed this yet.
- Dominant language
- Go Template
- Stars
- 2.3k
- Forks
- 186
- Avg merge
- 3d 11h
- Merged PRs (30d)
- 66
Description
### Summary
`obj.provider` assumes **one bucket per consumer**. `obj.provider.linode.buckets`
maps a single bucket name to each app (`loki`, `harbor`, `cnpg`,
`gitea`, `kubeflow-pipelines`, …), but some consumers legitimately need **more than
one bucket**. Loki is the concrete case: our deployment uses **three separate
buckets** — chunks / ruler / admin — so the single-bucket map can't express the
layout, and we fall back to per-app `_rawValues` for Loki even when everything else
about `obj.provider` fits.
Request: let a consumer declare **more than one bucket** (a bucket-per-purpose map),
not just one bucket per app.
### Background
This was originally raised as a second, independent blocker in #3400 (the credential
side of that issue has since moved on: `secretAccessKey` now sources from
`obj-secrets`, and the remaining `accessKeyId` asymmetry is tracked in #3459). The
bucket-layout limitation is orthogonal to credential ownership and survives both, so
it's split out here.
### Current behavior (apl-core v6.0.0)
```yaml
obj:
provider:
linode:
region: us-ord-1
buckets: # one bucket per consumer
loki: loki
harbor: harbor
cnpg: cnpg
```
Loki's S3 wiring gets a single bucket, but a real Loki deployment separates
storage by purpose (chunks, ruler, admin) into distinct buckets — which the
current map has no way to name.
### Proposed solution
Allow a consumer's entry to be either a single bucket (today's behavior, unchanged)
or a **map of purpose → bucket**:
```yaml
obj:
provider:
linode:
buckets:
harbor: harbor # scalar: unchanged
cnpg: cnpg
loki: # map: bucket per purpose
chunks: loki-chunks
ruler: loki-ruler
admin: loki-admin
```
The per-app templating that consumes `buckets.loki` (`values/loki/*.gotmpl`) would
map each purpose onto Loki's `storage_config` / `schemaConfig` bucket fields. Scalar
entries keep working exactly as they do now (fully backward compatible).
### Why it matters
Without multi-bucket support, any operator whose Loki (or other consumer) uses a
purpose-split bucket layout must abandon `obj.provider` for that app and re-hand-roll
its object-storage config via `_rawValues`, losing the abstraction's benefit for that
consumer even when the credential side is fully handled.
### Environment
- apl-core `v6.0.0` (managed App Platform)
- Provider: `linode`; consumer: Loki (chunks / ruler / admin)
Contributor guide
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
Research direction
Start by tracing how obj.provider.linode.buckets is consumed, then inspect the per-app templates under values/loki/*.gotmpl. Confirm how the existing scalar bucket reaches Loki's storage_config and schemaConfig, and preserve that path while supporting purpose maps. Done means Loki can receive separate chunks, ruler, and admin buckets without breaking scalar entries for other consumers.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- kubernetes, yaml
- Domain
- infrastructure
- Issue type
- Feature
- Difficulty
- 4/5
- Estimated time
- 3-5 days
- Activity status
- Quiet
- Clarity
- Mostly clear
- Newbie friendliness
- 52/100