Azure Redis CLI does not Support Geo-Replication Configuration #9286
Description
az feedbackauto-generates most of the information requested below, as of CLI version 2.0.62
Describe the bug
-
The azure cli command for configuring redis cache geo-replication only works when the redis instances are a) in the same resource group and therefore b) in the same region. Effectively, this means geo-replication cannot be configure via az cli at the moment since functionality is limited to geo-replication within a single region.
-
The azure cli documentation for configuring redis cache geo-replication is not clear on which resource-group should be specified (the resource group of the primary redis instance or the secondary?). Unless this implies that both instances should be in the same resource group (which is not clear from the documentation).
To Reproduce
- Test Code bootstrap #1: Azure cli geo-replication configuration within the same region and same resource-group:
az redis server-link create --debug --name rds-1-region1 --replication-role Primary --resource-group rsg-region1 --server-to-link rds-2-region1
- Test Add current directory to search path to allow load of modules without… #2: Azure cli geo-replication configuration with redis instances in different regions and separate resource groups
az redis server-link create --debug --name rds-1-region1--replication-role Primary --resource-group rsg-region2 --server-to-link rds-2-region2
.
.
{"error":{"code":"ResourceNotFound","message":"The Resource 'Microsoft.Cache/Redis/rds-1-region1' under resource group 'rsg-region2' was not found."}}
.
.
Expected behavior
Azure CLI should allow Geo-replication to be configured between redis caches in separate regions and separate resource groups.
Environment summary
Install Method (e.g. pip, interactive script, apt-get, Docker, MSI, edge build) / CLI version (az --version) / OS version / Shell Type (e.g. bash, cmd.exe, Bash on Windows)
Additional context
When the instances are in the same resource group and same region, replication configuration works. However, that does not achieve our use-case. Putting the instances into separate regions requires separate resource groups. However, once we use separate resource groups the az cli command for setting up replication fails, unwilling to accept either resource group as an argument. So it seems the only conclusion to deduce from that is that the az cli only supports geo-replication within a region and within the same resource group and therefore is not actually "geo" replication, but just "replication"