search

Azure / azure-cli

Azure Command-Line Interface
MIT License
4.01k stars 2.98k forks source link

Cannot update redis cache with vnet integration #6769

Closed kalavan closed 5 years ago

kalavan commented 6 years ago

Describe the bug When I try to scale redis cache that has vnet integration with command az redis update --name <<REDIS_NAME> --resource-group <RG_NAME> --set shardCount=1 command fails with: The requested update to the resource is not permitted. The following properties(s) cannot be modified: 'properties.subnet,properties.staticIP'.

To Reproduce 1) Create clustered redis cache with vnet integration. 2) Try to scale it with cli with command like: az redis update --name <<REDIS_NAME> --resource-group <RG_NAME> --set shardCount=2

Expected behavior I expect the service to be scaled.

Environment summary CLI is installed on linux machine with installation script curl -L https://aka.ms/InstallAzureCli | bash az --version azure-cli (2.0.41)

uname -a Linux 4.16.4-1-ARCH #1 SMP PREEMPT Tue Apr 24 13:21:29 UTC 2018 x86_64 GNU/Linux

abforman commented 6 years ago

I'm seeing the same issue while trying to enable redis persistence (RDB). In the portal it just silently fails, but via CLI it errors out saying prperties.subnet and properties.staticIP cannot be modified (even though those aren't technically the correct property values).

abforman commented 6 years ago

I opened a ticket with MS support on this issue. and found out the issue was with a VNet-isolated storage account. Once I removed the storage account firewall settings, it worked fine.

"It appears that you may be trying to setup Redis data persistence using a storage account that is deployed to your virtual network with the service endpoint feature. This scenario is not currently supported but will be in the future. The storage account used for Redis data persistence must be accessible to all networks (default configuration). Additionally, the engineering team will be looking into improving the error messages in the Azure portal, as well as identifying and fixing the cause of the incorrect error message from the Azure CLI."

My best guess is that you're running into a similar situation with the scaling. Do you have persistence or storage endpoints enabled on your cache/subnet?