OpenStack: Reuse an existing OpenStack client, don't make an auth req in every mcm method call

[kayrus]

What would you like to be added:

Currently an authed OpenStack client is created for each OpenStack API call, this is not efficient. You can create an authed OpenStack client at startup and reuse it. For example you can take a look on how it is done in k8s openstack controller: https://github.com/kubernetes/cloud-provider-openstack/blob/8afa0f628e15a3016b2add62d53f96d4921a6a0a/pkg/cloudprovider/providers/openstack/openstack.go#L488..L554

Why is this needed:

This will reduce a load on keystone API and significantly lower an amount of API calls.

/cc @hardikdr @rfranzke @vpnachev

[kon-angelo]

This issue was moved here from the old MCM repository. Hence I would like to re-examine it's validity for the current MCM and out-of-tree providers.

Here are my concerns:

• the credentials can change at any time, including during the runtime and we would need to deal with credential updates. Therefore, simply creating at startup is not enough.
• The credentials are part of the machineclass and theoretically each machineclass can use different ones. Therefore we would need to support multiple authed clients.

It is a bit different usecase from CCM that gets restarted when credentials get updated. Since creation on startup is not an option for us, I think the next best thing would be to create and cache the clients per hashedCredentials or a similar scheme.

[kayrus]

Do you have updates on this issue?

[kon-angelo]

@kayrus no updates but I still consider it a valid improvement. We can bump it but I still need to tackle the credential invalidation.

/remove lifecycle-rotten

[gardener-robot]

@kon-angelo Label lifecycle-rotten does not exist.

[kon-angelo]

/remove lifecycle/rotten

[gardener-ci-robot]

The Gardener project currently lacks enough active contributors to adequately respond to all issues.
This bot triages issues according to the following rules:

• After 90d of inactivity, lifecycle/stale is applied
• After 60d of inactivity since lifecycle/stale was applied, lifecycle/rotten is applied
• After 60d of inactivity since lifecycle/rotten was applied, the issue is closed

You can:

• Mark this issue as active with /lifecycle active
• Mark this issue as frozen with /lifecycle frozen
• Mark this issue as fresh with /remove-lifecycle stale
• Mark this issue as rotten with /lifecycle rotten
• Close this issue with /close

/lifecycle stale