Problem
Phase 2's discovery hardcodes the ingestor ServiceAccount name to `"ingestor"` (the chart default). Customers who set `ingestionAuthz.serviceAccountName` to a non-default name in the parent client chart silently get the wrong SA targeted — TokenRequest hits a 404 on the renamed SA.
v0.1 ships a workaround: `--ingestor-sa` flag on `cluster info` (and the forthcoming `dataset push`) lets customers explicitly override. That's brittle — every customer-talking command has to expose + plumb the flag, and renaming customers have to remember to pass it.
Fix
The parent client chart writes the SA name into a ConfigMap (`-ingestion-authz` or similar) along with the rest of the authz policy. Read that ConfigMap during `DiscoverParentRelease`, parse the YAML, extract `serviceAccountName`. Single source of truth.
Implementation sketch:
```go
// In internal/cluster/discover.go, after the deployment lookup:
cm, err := cs.CoreV1().ConfigMaps(namespace).Get(ctx, "-ingestion-authz", metav1.GetOptions{})
if err == nil {
var policy struct {
ServiceAccountName string `yaml:"serviceAccountName"`
}
if data, ok := cm.Data["policy.yaml"]; ok {
_ = yaml.Unmarshal([]byte(data), &policy)
if policy.ServiceAccountName != "" {
release.IngestorSAName = policy.ServiceAccountName
}
}
}
```
Adjust based on the actual ConfigMap's name + data-key layout (verify against the parent chart's templates).
Acceptance criteria
- A cluster running the parent chart with `ingestionAuthz.serviceAccountName: foo-ingestor` is discovered correctly: `cluster info` prints `ingestor SA: /foo-ingestor` without any flag override
- `--ingestor-sa` flag is dropped from `cluster info` (and any other commands that grew it for the workaround)
- Existing test that confirms the default "ingestor" still passes
- A new test seeds a fake ingestionAuthz ConfigMap with a renamed SA and asserts discovery reflects it
Found by
Bugbot review of PR #2 caught a contradiction between the discovery code's comment ("read SA name from env") and reality (only INGESTOR_IMAGE_DIGEST was read, SA name was hardcoded). The immediate fix was to admit the limitation + add a workaround flag; this ticket tracks the proper discovery.
Problem
Phase 2's discovery hardcodes the ingestor ServiceAccount name to `"ingestor"` (the chart default). Customers who set `ingestionAuthz.serviceAccountName` to a non-default name in the parent client chart silently get the wrong SA targeted — TokenRequest hits a 404 on the renamed SA.
v0.1 ships a workaround: `--ingestor-sa` flag on `cluster info` (and the forthcoming `dataset push`) lets customers explicitly override. That's brittle — every customer-talking command has to expose + plumb the flag, and renaming customers have to remember to pass it.
Fix
The parent client chart writes the SA name into a ConfigMap (`-ingestion-authz` or similar) along with the rest of the authz policy. Read that ConfigMap during `DiscoverParentRelease`, parse the YAML, extract `serviceAccountName`. Single source of truth.
Implementation sketch:
```go
// In internal/cluster/discover.go, after the deployment lookup:
cm, err := cs.CoreV1().ConfigMaps(namespace).Get(ctx, "-ingestion-authz", metav1.GetOptions{})
if err == nil {
var policy struct {
ServiceAccountName string `yaml:"serviceAccountName"`
}
if data, ok := cm.Data["policy.yaml"]; ok {
_ = yaml.Unmarshal([]byte(data), &policy)
if policy.ServiceAccountName != "" {
release.IngestorSAName = policy.ServiceAccountName
}
}
}
```
Adjust based on the actual ConfigMap's name + data-key layout (verify against the parent chart's templates).
Acceptance criteria
Found by
Bugbot review of PR #2 caught a contradiction between the discovery code's comment ("read SA name from env") and reality (only INGESTOR_IMAGE_DIGEST was read, SA name was hardcoded). The immediate fix was to admit the limitation + add a workaround flag; this ticket tracks the proper discovery.