Repository navigation
Resource version attribute for target pools #3843
Description
Activity
Hi @nouseforaname,
this is an API limitation, but I will forward it to the Loadbalancer team for you.
Best regards
Ruben from STACKIT Developer Tools teamHi @nouseforaname, you can also use
UpdateLoaderBalancerwith optimistic locking if you only want to apply changes to the target pool. This is how the Kubernetes cloud controller manager does it: https://github.com/stackitcloud/cloud-provider-stackit/blob/fac900f299d8bbe5eee197274593368a24e76295/pkg/ccm/loadbalancer.go#L160-L163Does that already help you? If not, can you explain your use case a bit further?
@fischerman My usecase is to update a single target pool, not the full loadbalancer.
I'm aware about your suggested workaround. I just think it's a bit weird to
rebuild the whole house because I want to exchange a single window
If something on the LB request goes wrong X target pools are affected.
If something on the TargetPool request goes wrong, 1 target pool is affected.My code isn't aware about most of the settings on an LB, because It doesn't need to be. Additionally the component I'm working on is itself stateless ( within it's execution context, my code has limited knowledge around the FULL state of the system). E.g. at the time of attaching a VM, I have zero information about any other attached instances of that LB.
Yes, I could just copy most of these settings from the upstream object before changing only the target pool I care about, but that still leaves room for errors. I can come up with yet another workaround ( e.g. by introducing state into my component and client side locking on the UUID for the resource before the request ), etc.
I'm not necessarily asking for workaround, this is just trying to get an existing feature of the API ( resource versioning ) available for further resources to
avoid workaroundsTargets pools aren't their own entity. They are part of a load balancer. I don't think it makes sense to introduce versions on sub structures.
Even if you just want to update a target pool, I don't see it as a workaround to send an update for the entire load balancer. The workflow would be the following.
- Get load balancer from API. You want to do this just before the update to get the most recent changes.
- Apply changes to your copy of the load balancer, e.g. update target pool. Everything you don't touch remains unchanged.
- Update load balancer with your copy
One thing that is currently a bit annoying is that read-only fields must be wiped before the update. We are looking into ignoring those fields on update requests.
I'm a bit confused by
Targets pools aren't their own entity.Yes, none make sense without an LB. But neither do interfaces make sense without a network or a loadbalancer without a network.As far as
what do we practically communicate about target groups with our dev exp?- SDK level single target pool calls
- API Level management endpoints for single target groups
- unique identifiers for target groups
etc..
And again, I understand the workaround. I just don't think it's a great workaround.
I'm not sure that I follow entirely. My proposal isn't a workaround. It is the way that every client (for the Load Balancer APIs) should be implemented. Can you elaborate what problem you are facing with this approach?
I have a loadbalancer. That loadbalancer has x target groups ( because the systems behind it, do no create much traffic).
I deploy concurrently.
Lets assume I have 10 target groups on that LB
Lets assume each target group maps to a deployment of 10 VMs,
I roll 3 instances at once per deployment,
If I start all 10 deployments at the same time, it is highly likely that 30 VMs will be created around the same time.
That means that those 30 processes ( each running in isolation without any knowledge of the others ) will create update loadbalancer calls at the same time and thus compete with each other.
If I had the option to do the versioning on target group level, I'd see 3 processes creating competing requests at the same time.
In any case, looking at
I'm not totally sure I can follow your argument:
Targets pools aren't their own entity.Why did we implement ApiEndpoints to handle them as single Entities?
when I want to run concurrent updates to a target pool of a load balancer, I'm going ( I in fact have to achieve this and I have to work around this issue) to have a bad time.
The API already provides a resource version field for the load balancer itself:
https://docs.api.stackit.cloud/documentation/load-balancer/version/v2#tag/Load-Balancer/operation/APIService_UpdateLoadBalancer
Please add a resource version for Update Target Pool as well:
https://docs.api.stackit.cloud/documentation/load-balancer/version/v2#tag/Load-Balancer/operation/APIService_ReplaceTargetPool