Resource version attribute for target pools

[nouseforaname]

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

[rubenhoenle]

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 team

[fischerman]

Hi @nouseforaname, you can also use UpdateLoaderBalancer with 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-L163

Does that already help you? If not, can you explain your use case a bit further?

[nouseforaname]

@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 workarounds

[fischerman]

Targets 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.

[nouseforaname]

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.