unkin-agent
1172aa3e96
## Why pdbmux#9 drops primary/prefer and makes configured backend order the only tie-break, so the current `old`-first list would silently reverse which PuppetDB wins. ## How - Order `PDBMUX_BACKENDS` with `new=http://puppetdb.puppet.svc.cluster.local:8080` first and `old=http://puppetdbapi.service.consul:8080` second, URLs unchanged. - Drop `PDBMUX_PRIMARY` and `PDBMUX_PREFER`; both already resolve to `new`, on the deployed v0.1.0 image (estate defaults) and on pdbmux main (first-backend fallback), so the rendered behaviour is unchanged today. - Refresh the configmap and deployment comments to describe order-based precedence. Merge this before pdbmux#9. Reviewed-on: #452 Co-authored-by: unkin-agent <unkin-agent@unkin.net> Co-committed-by: unkin-agent <unkin-agent@unkin.net>
17 lines
666 B
YAML
17 lines
666 B
YAML
---
|
|
apiVersion: v1
|
|
kind: ConfigMap
|
|
metadata:
|
|
name: pdbmux-env
|
|
namespace: pdbmux
|
|
data:
|
|
PDBMUX_LISTEN: ":8080"
|
|
# Two PuppetDB backends merged during the VM -> k8s migration, in precedence
|
|
# order (first wins ties / pass-through):
|
|
# new = the in-cluster k8s PuppetDB (plain HTTP on 8080; in-cluster address
|
|
# is preferred over the external gateway to avoid a hairpin)
|
|
# old = legacy Consul-registered puppetdbapi (reachable from pods via the
|
|
# Consul DNS the puppet workloads already use)
|
|
PDBMUX_BACKENDS: "new=http://puppetdb.puppet.svc.cluster.local:8080,old=http://puppetdbapi.service.consul:8080"
|
|
PDBMUX_MERGE: "freshness"
|