Azure / Azure/bicep-registry-modules

[AVM Module Issue]: Fabric Capacity - SKU Change fails when capacity is paused

Open
#5,196 14 comments 1 reaction 3 assignees Claimed by @cmaneu View on GitHub
Class: Resource Module :package: Needs: Immediate Attention :bangbang: Needs: Triage :mag: Status: Response Overdue :triangular_flag_on_post: Type: AVM :a: :v: :m: Type: Bug :bug:
Dominant language
Bicep
Stars
736
Forks
564
Avg merge
3d 15h
Merged PRs (30d)
30

Description

### Check for previous/existing GitHub issues

- [x] I have checked for previous/existing GitHub issues

### Issue Type?

Bug

### Module Name

avm/res/fabric/capacity

### (Optional) Module Version

0.1.1

### Description

I am working with some Fabric Capacities that are sometimes in a paused state to reduce costs. It is my understanding that when using a Pay-As-You-Go capacity, this is common to ensure the business reduces costs.
However, if an ADO pipeline runs with Bicep calling this AVM module and tries to change the SKU from one type to another (example: F2 --> F4) then the deployment will fail as the resource is not in a ready state with the following error:
```
"code": "BadRequest",
"message": "Service is not ready to be updated"
```
It is my understanding that the rule is that Bicep is declarative and states the end-result of the resource regardless of how you got there. In that case, it would make sense to possibly resolve this by:

- Find a way to allow the change of F SKU while the capacity is paused (this seems to me to be the easiest path as it is a config change)
- Find the current state and store it. If paused, then start the capacity, change the SKU, and set the state to the previous value. Otherwise, just change the SKU.
- Provide an additional parameter that allows the caller to decide whether to allow the starting of the capacity to allow changes. That allows for no change to current users to have no change in functionality (this failure if paused) but allow anyone to override that behavior to allow the capacity to be started and stopped to make the change. I do not see any reason for someone ever **not** allow that change, but if needed, then this boolean would allow for that. Since this is version 0.1.1 I do not see this as a large breaking change.

Currently, automation would intermittently fail because of the current state instead of allowing the change and ensuring the resource ends up in the state described in Bicep.

### (Optional) Correlation Id

d0d6a4fe-7fce-442d-bfd0-a564b76713e8

Contributor guide

Open the contributing guide

Assessment

This issue has not been assessed yet.

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.