Repository navigation
Conversation
|
|
|
|
e90d50c to
f34df79
Compare
f34df79 to
c1147dd
Compare
0a15c1d to
c1147dd
Compare
| }, | ||
| "description": "Optional. The set of task queue types this scaling group serves.\nIf not provided, this scaling group serves all not otherwise defined\ntask types." | ||
| }, | ||
| "regionId": { |
There was a problem hiding this comment.
should this be a list just be on the safe side?
There was a problem hiding this comment.
I like that, we can leave the user facing interaction to be a single region but we can keep the API future proof using list of regions.
I went for a singular region because I kept thinking of provider details as region specific, but I think keeping this a list seems safer, I don't know how possible it is for a use case to come up where we'd apply a config to multiple regions though.
There was a problem hiding this comment.
May be when one wants to set cross cloud(namespace in aws, workers in gcp etc), which will be same if worker is not replicated for both primary and replica regions.
I revised it to use a list instead.
c1147dd to
5eead34
Compare
3 participants
What changed?
Adds an optional
region_idfield toComputeConfigScalingGroup. When set, the scaling group is used only while the namespace is active in that region. When empty, the scaling group is used as the default, so existing configurations behave exactly as before.Why?
This is to let users configure region specific compute on a Worker Deployment Version. The Worker Controller Instance can then invoke the compute that is set for the namespace's active region, so serverless workers follow the namespace through a failover.
Breaking changes
none
Server PR
none