Adding an Azure Stack provider will require the admin to specify the "typical stuff" we do for the public cloud environments, but also require additional information to properly set up the environment such as:
* Resource manager URL for their specific stack deployment -- we should be able to use this URL to discover the other service URLs "under the hood"
* API version profile so we can config the azure API versions we use (or ensure it matches with whatever set of versions we decide to support, if there's a limited list)
* Possibly some other info such as suffixes
* Ability to add a CA cert for the Azure Stack deployment to our local trust list if needed
See this doc which explains how to point Azure CLI at an AzureStack environment: https://github.com/MicrosoftDocs/azure-docs/blob/master/articles/azure-stack/user/azure-stack-version-profiles-azurecli2.md
We likely need to offer similar config options in our "Add Provider" UI pages when the admin wants to add an AzureStack provider.
Please assess the impact of this issue and update the severity accordingly. Please refer to https://bugzilla.redhat.com/page.cgi?id=fields.html#bug_severity for a reminder on each severity's definition.
If it's something like a tracker bug where it doesn't matter, please set the severity to Low.
Adding capability to armrest as described here will help with some of the URL discovery: https://github.com/ManageIQ/azure-armrest/issues/370
The admin will still need to manually specify the key vault suffix, storage endpoint suffix (as needs to be done for azure cli, stated in the above Microsoft doc). It appears there's no way to 'discover' that data yet -- https://github.com/Azure/msrestazure-for-python/issues/64
I believe the following PR's effectively close this issue:
https://github.com/ManageIQ/manageiq-ui-classic/pull/4304 (endpoint on UI side)
https://github.com/ManageIQ/manageiq-providers-azure/pull/274 (backend support for custom endpoint)
https://github.com/ManageIQ/manageiq-providers-azure/pull/275 (api handling)
Other outstanding issues should be (or already are) be tracked separately.
Moving to POST.