In the same vein as Sovereign Cloud Support (#137, #1533, and #1593), this issue requests support for private clouds. For the purposes of this issue, a private cloud can be understood to be an instance of Azure that has some subset of Azure services available as compared to Azure Public (maybe a proper subset, maybe not; maybe equal).
There is a desire to not have information about private clouds exposed to the Internet or contained in Github even when membership is locked down, so we cannot hardcode endpoints into the code as has been done so far to support Azure Public, Azure US Government, etc. My thoughts are to switch the mcp server to be configuration driven and to have the existing hardcoded endpoints/etc stored in a new set of configuration files in Github for the public and sovereign clouds we currently support. Using the --cloud option, users would supply their own config file with the required endpoints specific to their private cloud.
The functionality can be tested using public cloud as we would move everything to be config file driven, including public. This would mean tools, like KeyVault, would need to have endpoint configuration injected into them at startup.
What this issue does not attempt to solve is any sort of api version parity issues between clouds (public, sovereign, or private). That can and should be solved in some other way.
In the same vein as Sovereign Cloud Support (#137, #1533, and #1593), this issue requests support for private clouds. For the purposes of this issue, a private cloud can be understood to be an instance of Azure that has some subset of Azure services available as compared to Azure Public (maybe a proper subset, maybe not; maybe equal).
There is a desire to not have information about private clouds exposed to the Internet or contained in Github even when membership is locked down, so we cannot hardcode endpoints into the code as has been done so far to support Azure Public, Azure US Government, etc. My thoughts are to switch the mcp server to be configuration driven and to have the existing hardcoded endpoints/etc stored in a new set of configuration files in Github for the public and sovereign clouds we currently support. Using the
--cloudoption, users would supply their own config file with the required endpoints specific to their private cloud.The functionality can be tested using public cloud as we would move everything to be config file driven, including public. This would mean tools, like KeyVault, would need to have endpoint configuration injected into them at startup.
What this issue does not attempt to solve is any sort of api version parity issues between clouds (public, sovereign, or private). That can and should be solved in some other way.