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

Improve Resource Provider registration handling #387

Open
kon-angelo opened this issue Oct 22, 2021 · 1 comment
Open

Improve Resource Provider registration handling #387

kon-angelo opened this issue Oct 22, 2021 · 1 comment
Labels
area/control-plane Control plane related kind/enhancement Enhancement, improvement, extension lifecycle/rotten Nobody worked on this for 12 months (final aging stage) platform/azure Microsoft Azure platform/infrastructure priority/3 Priority (lower number equals higher priority)

Comments

@kon-angelo
Copy link
Contributor

kon-angelo commented Oct 22, 2021

How to categorize this issue?

/area control-plane
/kind enhancement
/priority 3
/platform azure

What would you like to be added:
Improve Azure's resource provider registration handling.

When interacting with Azure APIs to create resources, we are interacting with a resource provider and its types (source). Currently for a user of the gardener-extension-provider-azure it is necessary to have all the required providers registered to his subscription prior shoot creation.

This could be thought as a regression since in the past Terraform used to try and register all available providers but this caused an issue with newer versions of the terraform-provider-azurerm in subscriptions whose settings did not allow the registration of certain providers and was resolved with the addition of this change. AFAIK, for terraform this option currently is all-or-nothing, meaning that we can't force TF to only try and register the required providers and instead TF will try to register all the providers it supports which makes removing the skip_provider_registration flag from the TF script hard to accomplish.

This means that we need to:

  • define explicitly in the documentation the required providers we interact.
  • create a mechanism to handle the registration.

Examples of such mechanism could be:

  • continue letting the user handle it (but mention it explicitly in the documentation).
  • infrastructure validation check for the required providers prior to calling TF.
  • attempt the registration ourselves.
@kon-angelo kon-angelo added the kind/enhancement Enhancement, improvement, extension label Oct 22, 2021
@gardener-robot gardener-robot added platform/azure Microsoft Azure platform/infrastructure priority/3 Priority (lower number equals higher priority) labels Oct 22, 2021
@gardener-robot
Copy link

@kon-angelo Label area/todo does not exist.

@gardener-robot gardener-robot added the area/control-plane Control plane related label Oct 22, 2021
@gardener-robot gardener-robot added the lifecycle/stale Nobody worked on this for 6 months (will further age) label Apr 21, 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 Oct 18, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
area/control-plane Control plane related kind/enhancement Enhancement, improvement, extension lifecycle/rotten Nobody worked on this for 12 months (final aging stage) platform/azure Microsoft Azure platform/infrastructure priority/3 Priority (lower number equals higher priority)
Projects
None yet
Development

No branches or pull requests

2 participants