Azure Redis CLI does not Support Geo-Replication Configuration

az feedback auto-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 #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 #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”

[alfantp]

Hello @archmangler , when resource ID is mentioned in azure, it generally refers to the ARM resource id, which you posted in the beginning of your post. When the cache you are trying to link is in a different Resource Group, you can use the resource id as the parameter value for ‘server-to-link’ as mentioned in the docs. In the variations you mentioned above, i only see resource name being tried and not ID. I just tried this and it worked: az redis server-link create --name < primarycachename > --resource-group < primaryRG > --server-to-link /subscriptions/< subscription >/resourceGroups/< secondaryRG >/providers/Microsoft.Cache/Redis/< secondarycachename > --replication-role Secondary

Design principles for CLI mentions using a single parameter to accept either ARM Resource ID or resource name for a supporting resource in an operation: https://github.com/Azure/azure-cli/blob/dev/doc/authoring_command_modules/authoring_commands.md#supporting-name-or-id-parameters This is so that when the supporting resource is in the same resource group, you can just type in resource name and if not, you can enter the resource ID.

[tjprescott]

Thanks for looking into the @alfantp. Since you have verified the command is working as intended and that the functionality is supported, I will close this issue.

@archmangler supplying --resource-group twice simply overwrites the first value with the second. As @alfantp mentioned, you need to supply the ARM resource ID for the secondary server.