This repository has been archived by the owner on Oct 10, 2023. It is now read-only.
Dynamically assign AD endpoints for Azure, support AzureStack #3162
Labels
area/lcm
Related to Cluster Lifecycle management
kind/feature
Categorizes issue or PR as related to a new feature
provider/azure
related to CAPZ provider support
Comments
conzetti
added
kind/feature
|
Hey @conzetti! Thanks for opening your first issue. We appreciate your contribution and welcome you to our community! We are glad to have you here and to have your input on Tanzu Framework. |
vuil
added
area/lcm
|
Thanks @conzetti for the issue. So does the change boil down to adding support for the AzureStackCloud and CLI user expecting to supply a configuration file whose location is controlled via the AZURE_ENVIRONMENT_FILEPATH env var? |
|
cc @tenczar |
|
@vuil That's pretty much the synopsis. If |
conzetti
added a commit
to conzetti/tanzu-framework
that referenced
this issue
Aug 22, 2022
TL;DR ===== - See vmware-tanzu#3162 - Leverage go-autorest for AD endpoints; open up possibility of using AzureStack / custom Azure clouds in doing so - Needs appropriate test/fake for AzureStack Detail ====== ddbbbea introduced several constants in `client.go` that are already defined in `Azure/go-autorest`. This commit simply relies on the cloud definitions in `Azure/go-autorest` so we can do the following: 1. Remain DRY 2. Maintain up-to-date values for all cloud endpoints, since Microsoft helps maintain that project 3. Open the possibility of additional Azure clouds that are defined entirely by configuration file (e.g. `AzureStack`, TS/S regions) Current shortcomings of this commit: * Missing appropriate fake for AzureStack * Doesn't remove all of the constants that are defined (e.g. the `PublicCloud` definition is required by `validate.go`, and I wasn't certain if we should import something outside of the project for input validation of the CLI)
rajathagasthya
removed
the
needs-triage
JefeDavis
pushed a commit
to JefeDavis/tanzu-framework
that referenced
this issue
Apr 20, 2023
by removing the hard-coded maps for Azure environments and calling the EnvironmentFromName function from the go-autorest/azure library we can use the existing tools to validate Azure Environments while also enabling the initial ability to specify custom endpoints for AzureStackCloud by using the Environment 'AzureStackCloud' and specifying AZURE_ENVIRONMENT_FILEPATH and providing an AzureEnvironment json file Closes Issue vmware-tanzu#3162 Signed-off-by: Jeff Davis <[email protected]>
JefeDavis
pushed a commit
to JefeDavis/tanzu-framework
that referenced
this issue
Apr 20, 2023
remove hard-coded maps for Azure environments and call EnvironmentFromName function from go-autorest/azure library to leverage existing tools to validate Azure Environments also enables initial ability to specify custom endpoints for AzureStackCloud by using the Environment 'AzureStackCloud' and specifying AZURE_ENVIRONMENT_FILEPATH and providing an AzureEnvironment json file Closes Issue vmware-tanzu#3162 Signed-off-by: Jeff Davis <[email protected]>
JefeDavis
pushed a commit
to JefeDavis/tanzu-framework
that referenced
this issue
Apr 20, 2023
remove hard-coded maps for Azure environments and call EnvironmentFromName function from go-autorest/azure library to leverage upstream provider to validate Azure Environments also enables initial ability to specify custom endpoints for AzureStackCloud by using the Environment 'AzureStackCloud' and specifying AZURE_ENVIRONMENT_FILEPATH and providing an AzureEnvironment json file Closes Issue vmware-tanzu#3162 Signed-off-by: Jeff Davis <[email protected]>
JefeDavis
pushed a commit
to JefeDavis/tanzu-framework
that referenced
this issue
Apr 21, 2023
remove hard-coded maps for Azure environments and call EnvironmentFromName function from go-autorest/azure library to leverage upstream provider to validate Azure Environments also enables initial ability to specify custom endpoints for AzureStackCloud by using the Environment 'AzureStackCloud' and specifying AZURE_ENVIRONMENT_FILEPATH and providing an AzureEnvironment json file Closes Issue vmware-tanzu#3162 Signed-off-by: Jeff Davis <[email protected]>
JefeDavis
pushed a commit
to JefeDavis/tanzu-framework
that referenced
this issue
Apr 21, 2023
remove hard-coded maps for Azure environments and call EnvironmentFromName function from go-autorest/azure library to leverage upstream provider to validate Azure Environments also enables initial ability to specify custom endpoints for AzureStackCloud by using the Environment 'AzureStackCloud' and specifying AZURE_ENVIRONMENT_FILEPATH and providing an AzureEnvironment json file Closes Issue vmware-tanzu#3162 Signed-off-by: Jeff Davis <[email protected]>
Sign up for free
to subscribe to this conversation on GitHub.
Already have an account?
Sign in.
Describe the feature request
By default,
go-autorestallows downstream consumers, such astanzu-frameworkto lookup various endpoints. Presently,tanzu-frameworkexplicitly sets the Active Directory endpoints for a subset of Azure clouds (referencinggo-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 ingo-autorest. Example:GermanCloud.The current set of unit tests compare the local Active Directory values in
tanzu-frameworkagainstgo-autorest, so those would ultimately need to be amended or removed if eliminating the additional logic fromazure/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 totanzu-frameworkto support this capability.Describe alternative(s) you've considered
Several customers have forked
tanzu-frameworkand 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)
Additional context
Please let me know if this is something that you'd be open to a pull request for.
The text was updated successfully, but these errors were encountered: