fix balancer ld context
Motivation
Currently balancer uses a cloud_provider context with a key of the cloud provider which means all balancers use the same key aws. This seems to break LD contexts for the balancers and goes against the docs. dyncfg works with the current setup, but LD just won't recommend all keys/regions when create or updating a rule.
https://docs.launchdarkly.com/sdk/features/context-config
Keys must be a string type. Keys must be unique, deterministic, and should not contain personally identifiable information (PII). Keys must be consistent, which means the same person must correspond to the same key across > different services to contribute to consistent flag evaluations. You can use a primary key or a hash, as long as the same person always has the same key. We recommend using a hash if possible.`
The fix is to use a more specific contex and a key that reduces the scope of balancers to a set we can treat as the same. I'm also taking the opportunity to add build version into the context.
It's entirely possible we just don't want to do this and are more or less ok with the contexts overwriting each other.
Tips for reviewer
Checklist
- [ ] This PR has adequate test coverage / QA involvement has been duly considered. (trigger-ci for additional test/nightly runs)
- [ ] This PR has an associated up-to-date design doc, is a design doc (template), or is sufficiently small to not require a design.
- [ ] If this PR evolves an existing
$T ⇔ Proto$Tmapping (possibly in a backwards-incompatible way), then it is tagged with aT-protolabel. - [ ] If this PR will require changes to cloud orchestration or tests, there is a companion cloud PR to account for those changes that is tagged with the release-blocker label (example).
- [ ] If this PR includes major user-facing behavior changes, I have pinged the relevant PM to schedule a changelog post.
Currently balancer uses a
cloud_providercontext with a key of the cloud provider which means all balancers use the same keyaws. This seems to break LD contexts for the balancers and goes against the docs. dyncfg works with the current setup, but LD just won't recommend all keys/regions when create or updating a rule.
Hmm, what are you seeing going wrong? LD seems to correctly autocomplete the aws cloud provider context for me.
@benesch aws is the only thing it will consistently auto-complete as all contexts use that as their key. Things like region are regularly getting overwritten so only one region will ever be populated.