Skip to content
This repository was archived by the owner on Oct 10, 2023. It is now read-only.
This repository was archived by the owner on Oct 10, 2023. It is now read-only.

Dynamically assign AD endpoints for Azure, support AzureStack #3162

Open
@conzetti

Description

@conzetti

Describe the feature request
By default, go-autorest allows downstream consumers, such as tanzu-framework to lookup various endpoints. Presently, tanzu-framework explicitly sets the Active Directory endpoints for a subset of Azure clouds (referencing go-autorest) while inadvertently crippling the ability to deploy to AzureStack, which mandates the setting of endpoints via an additional configuration file.

By dynamically assigning the endpoints, rather than defining the endpoints for a subset of clouds, we forgo the need to contain that logic in tanzu-framework. We also could eliminate the constants that represent the proper Azure cloud names (and not their monikers), which are also present in go-autorest. Example: GermanCloud.

The current set of unit tests compare the local Active Directory values in tanzu-framework against go-autorest, so those would ultimately need to be amended or removed if eliminating the additional logic from azure/client.go.

Currently folks that are attempting to build in secret/top-secret regions are incapable of doing so with the Tanzu CLI because of the limitations that have been mentioned here. Those Azure clouds follow the same pattern as AzureStack, which mandates custom endpoints (and thus the ability to supply an Azure configuration file). Supplying a custom configuration file is already a first-class citizen in go-autorest, so changes would simply need to be made to tanzu-framework to support this capability.

Describe alternative(s) you've considered
Several customers have forked tanzu-framework and built a custom CLI to support their POC efforts. Not a reasonable alternative (from a UX perspective) for licensed users, but an alternative nonetheless.

Affected product area (please put an X in all that apply)

  • ( ) APIs
  • ( ) Addons
  • (X) CLI
  • (X) Docs
  • ( ) IAM
  • (X) Installation
  • ( ) Plugin
  • ( ) Security
  • ( ) Test and Release
  • (X) User Experience
  • ( ) Developer Experience

Additional context
Please let me know if this is something that you'd be open to a pull request for.

Metadata

Metadata

Assignees

No one assigned

    Labels

    area/lcmRelated to Cluster Lifecycle managementkind/featureCategorizes issue or PR as related to a new featureprovider/azurerelated to CAPZ provider support

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions