Describe the bug
Release 0.9.0 introduced support for SFTP (and NFSv3) for Storage Accounts.
There are two problems:
- This is a Breaking Change and this is not advertised in the release notes
- This is a Breaking Change and makes it impossible to successfully run a deployment including existing Resource Groups that were first deployed with BICEPs using CARML <= 0.8.0
Looking in the repo history, this change comes from PR #2514 , which is erroneously marked as New feature (non-breaking change which adds functionality)
Regarding point 2, if you have deployed a Storage Account with any set of parameters with CARML <= 0.8.0, and you try to run a deployment again of the same BICEP with CARML >= 0.9.0 you get a BadRequest error with message The property 'isNfsV3Enabled' was specified in the input, but it cannot be updated as it is read-only. For more information, see - https://aka.ms/storageaccountupdate" and the deployment fails.
This is almost probably going to happen with isSftpEnabled too, for the same reason (can only be enabled when creating the storage account and not modified afterwards).
This might be an ARM (server side) issue: a parameter of 'isNfsV3Enabled: false' should be treated as 'isNfsV3Enabled' not being provided, given that the result is the same, and should not complain about an update to a read-only property.
For isSftpEnabled it should be the same.
New versions of the BICEP modules in stable releases should be backward compatible with existing deployments executed with old versions of the BICEP modules.
To reproduce
- Deploy a Storage Account with any set of parameters with CARML <= 0.8.0
- Run a deployment again of the same BICEP with CARML >= 0.9.0, it will fail
Code snippet
No response
Relevant log output
{
"status": "Failed",
"error": {
"code": "AccountPropertyCannotBeUpdated",
"message": "The property 'isNfsV3Enabled' was specified in the input, but it cannot be updated as it is read-only. For more information, see - https://aka.ms/storageaccountupdate"
}
}
Describe the bug
Release 0.9.0 introduced support for SFTP (and NFSv3) for Storage Accounts.
There are two problems:
Looking in the repo history, this change comes from PR #2514 , which is erroneously marked as New feature (non-breaking change which adds functionality)
Regarding point 2, if you have deployed a Storage Account with any set of parameters with CARML <= 0.8.0, and you try to run a deployment again of the same BICEP with CARML >= 0.9.0 you get a BadRequest error with message The property 'isNfsV3Enabled' was specified in the input, but it cannot be updated as it is read-only. For more information, see - https://aka.ms/storageaccountupdate" and the deployment fails.
This is almost probably going to happen with
isSftpEnabledtoo, for the same reason (can only be enabled when creating the storage account and not modified afterwards).This might be an ARM (server side) issue: a parameter of 'isNfsV3Enabled: false' should be treated as 'isNfsV3Enabled' not being provided, given that the result is the same, and should not complain about an update to a read-only property.
For
isSftpEnabledit should be the same.New versions of the BICEP modules in stable releases should be backward compatible with existing deployments executed with old versions of the BICEP modules.
To reproduce
Code snippet
No response
Relevant log output
{ "status": "Failed", "error": { "code": "AccountPropertyCannotBeUpdated", "message": "The property 'isNfsV3Enabled' was specified in the input, but it cannot be updated as it is read-only. For more information, see - https://aka.ms/storageaccountupdate" } }