[full-ci] fix: always select next gateway client

[micbar]

Description

Needed for #10123

@d7oc This is a very important bugfix for kubernetes environments.

Related Issue

• Fixes <issue_link>

Motivation and Context

How Has This Been Tested?

• test environment:
• test case 1:
• test case 2:
• ...

Screenshots (if appropriate):

Types of changes

• Bug fix (non-breaking change which fixes an issue)
• New feature (non-breaking change which adds functionality)
• Breaking change (fix or feature that would cause existing functionality to change)
• Technical debt
• Tests only (no source changes)

Checklist:

• Code changes
• Unit tests added
• Acceptance tests added
• Documentation ticket raised:

[mmattel]

Should we do any docs in the readme about this? (imho yes)

[rhafer]

Looks ok to me. Please just remove the unused GetCS3apiClient method

[jvillafanez]

I think we could reuse one selector per request. The PR gets a new selector each time we need to contact the gateway, which I'm not sure if it's a good idea. If we want to go this way, a helper method might keep the same complexity.

For example, the RenameFile has several f.gws.Next(), but maybe we only need one for the whole request.

[micbar]

I think we could reuse one selector per request. The PR gets a new selector each time we need to contact the gateway, which I'm not sure if it's a good idea. If we want to go this way, a helper method might keep the same complexity.

For example, the RenameFile has several f.gws.Next(), but maybe we only need one for the whole request.

Discussed that with @butonic

we need to do it every time, because a pod can disappear between two requests.

The „good“ solution will be using a client which can do the next selector by itself.

[jvillafanez]

assuming tests pass

[sonarcloud]

Quality Gate passed

Issues
3 New issues
1 Accepted issue

Measures
0 Security Hotspots
63.2% Coverage on New Code
22.1% Duplication on New Code

See analysis details on SonarCloud

[jvillafanez]

The „good“ solution will be using a client which can do the next selector by itself.

Canceling this for now because it seems too much work for little gain.

We'd need to implement the whole GatewayAPIClient, which is huge, just to hide the selector code inside our custom client. I think we should enrich our client with something more in order to make it worthy.

I've tried to include a retry policy in case of network errors so the next request would go to a different gateway, but it seems we don't have guarantees that the next request wouldn't go to the same gateway. Right now, the selector policy is random (we could still hit the same gateway), and even with a round robin policy, since the client is shared, concurrent requests could cycle through the clients, so the retried request might still go to the same gateway.

[micbar]

We can just use the go micro client, which is already capable of doing that. And this also applies for http