Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Open
kayrus opened this issue Mar 11, 2020 · 1 comment
Labels
area/quality Output qualification (tests, checks, scans, automation in general, etc.) related effort/2d Effort for issue is around 2 days kind/enhancement Enhancement, improvement, extension lifecycle/rotten Nobody worked on this for 12 months (final aging stage) priority/4 Priority (lower number equals higher priority)

Comments

@kayrus
Copy link

kayrus commented Mar 11, 2020

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

@prashanth26 prashanth26 transferred this issue from gardener/machine-controller-manager Jul 21, 2021
@prashanth26 prashanth26 added area/quality Output qualification (tests, checks, scans, automation in general, etc.) related kind/enhancement Enhancement, improvement, extension effort/2d Effort for issue is around 2 days priority/4 Priority (lower number equals higher priority) labels Jul 21, 2021
@kon-angelo
Copy link
Contributor

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.

@gardener-robot gardener-robot added the lifecycle/stale Nobody worked on this for 6 months (will further age) label Jan 26, 2022
@gardener-robot gardener-robot added lifecycle/rotten Nobody worked on this for 12 months (final aging stage) and removed lifecycle/stale Nobody worked on this for 6 months (will further age) labels Jul 25, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
area/quality Output qualification (tests, checks, scans, automation in general, etc.) related effort/2d Effort for issue is around 2 days kind/enhancement Enhancement, improvement, extension lifecycle/rotten Nobody worked on this for 12 months (final aging stage) priority/4 Priority (lower number equals higher priority)
Projects
None yet
Development

No branches or pull requests

4 participants