fix(common-services): add connector.log retention to curator

[gnanirahulnutakki]

Problem

connector.log is shipped to Elasticsearch by the fid-exporter sidecar — the fid chart defines the source in charts/fid/values.yaml:

connector:
  path: "/opt/radiantone/vds/logs/sync_agents/*/connector.log"
  index: connector.log

…but curator.logs in this chart has no entry for it. Every other prefix the exporter produces is pruned at 7 days; connector.log is the one exception, so its daily indices accumulate indefinitely.

It is also the highest-volume index in the stack — one document per connector event, across every sync agent — so it becomes the dominant consumer of Elasticsearch disk within a few months.

Evidence

Measured on the BSWH clusters (before a manual cleanup):

Cluster	connector.log indices	Size	Oldest index	Share of all index data
bswh-use1	90	55.8 GB	2026-05-13	78%
bswh-use2	348	167.6 GB	2025-08-28	85%

On bswh-use2 that is ~12 months of unpruned data. Curator was running nightly and healthy the whole time — it simply had no action matching this prefix, so every run logged Skipping action "delete_indices" due to empty list for the prefixes that had already aged out and never touched connector.log.

Change

One entry added to curator.logs. It inherits the chart's existing defaults (action: delete_indices, unit: days, unit_count: 7, direction: older), so it behaves exactly like the other 24 prefixes.

Verification

Rendered templates/elasticcurator/configmap.yaml before and after and diffed the result:

• actions: 24 → 25
• prefix set delta: added connector.log, removed none
• retention across all 25 actions: uniformly unit_count: 7
• action_file.yml parses as valid YAML in both renders

The only other diff is the positional renumbering of actions after index 11, which is inherent to range $index in the template — curator treats these as opaque action IDs executed in order, so the renumbering is behaviourally inert.

Rollout note

This is a values-only change with no chart version bump, to avoid colliding with the in-flight common-services/2.0.3 release (#63). It needs to be picked up by the next published chart version.

Consuming tenants pin the dependency explicitly, so they will each need a bump before this reaches a cluster — e.g. radiantlogic-saas/bswh-use1 is on common-services 2.0.1 and radiantlogic-saas/bswh-use2 on 2.0.0, both in app/charts/common-services/Chart.yaml.

Curator runs once per cluster in the -svc namespace, so this single change covers every -svc namespace that consumes the chart. The fid chart ships its own curator, but it defaults to enabled: false and is not deployed on these clusters, so no corresponding change is needed there.

[gnanirahulnutakki]

Superseded by #65, which folds this change into the in-flight common-services 2.0.3 release (#63) instead of landing it on master.

Closing here rather than merging, because this PR cannot go green on its own: its only CI failure is the ct lint version gate —

✖︎ common-services => (version: "2.0.2", path: "charts/common-services") > chart version not ok. Needs a version bump!

— and the whole point of leaving Chart.yaml at 2.0.2 was to avoid colliding with 2.0.3. Riding on the 2.0.3 bump clears that with no version games.

#65 carries the commit from this branch cherry-picked unmodified, plus a ### Curator section in the CHANGELOG that #63 introduced. It targets common-services/2.0.3, so it merges into #63's branch and ships with the release.

The measurements and rationale in this PR remain the reference for the change; #65 links back here rather than restating them.