Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

What-if with bicep does not show changes introduces by deeply nested modules #201

Closed
miqm opened this issue Jun 16, 2021 · 3 comments
Closed

Comments

@miqm
Copy link

miqm commented Jun 16, 2021

Describe the bug
running what-if when you have module that calls a module results that changes introduced by that 2nd module are not reflected.

To Reproduce
Steps to reproduce the behavior:

  1. deploy main.bicep that calls moduleA
  2. moduleA calls moduleB
  3. moduleB deploys resources

Expected behavior
What-if should detect changes introduced by entire deployment, regardless how many module calls are there

Client [e.g. PowerShell, CLI, API)
CLI

Additional context
With bicep is very easy now to nest modules. What-if should reflect that.

@ghost ghost added the Needs Triage 🔍 label Jun 16, 2021
@sladkoff
Copy link

Note that it doesn't even have to be 'deeply nested'.

It can be reproduced with the following example where there is one 'main' bicep file A, which uses modules B and C.
B outputs variables that C wants to use.

Module A

module B 'B.bicep' = {
  name: 'B'
}

module C 'C.bicep' = {
  name: 'C'
  params: {
    storageAccountName: B.outputs.storageAccountName
  }
}

Module B

resource storageAccount 'Microsoft.Storage/storageAccounts@2021-01-01' = {
  name: 'bstorageaccount'
  location: resourceGroup().location
  sku: {
    name: 'Standard_LRS'
    tier: 'Standard'
  }
  kind: 'StorageV2'
  properties: {
  }
}

output storageAccountName string = storageAccount.name

Module C

param storageAccountName string

resource blobServices 'Microsoft.Storage/storageAccounts/blobServices@2021-04-01' = {
  name: '${storageAccountName}/default'
  properties: {
    cors: {
      corsRules: []
    }
    deleteRetentionPolicy: {
      enabled: true
      days: 7
    }
  }
}

Output

Deploying these templates will lead to the following output (Note the missing blobServices resource from C.bicep)

$ az deployment group what-if --template-file A.bicep -g my-rg
Note: The result may contain false positive predictions (noise).
You can help us improve the accuracy of the result by opening an issue here: https://aka.ms/WhatIfIssues.

Resource and property changes are indicated with these symbols:
  + Create
  * Ignore

The deployment will update the following scope:

Scope: /subscriptions/xxxxxxxxxxxx/resourceGroups/my-rg

  + Microsoft.Storage/storageAccounts/bstorageaccount [2021-01-01]

      apiVersion: "2021-01-01"
      id:         "/subscriptions/xxxxxxxxxxxx/resourceGroups/my-rg/providers/Microsoft.Storage/storageAccounts/bstorageaccount"
      kind:       "StorageV2"
      location:   "westeurope"
      name:       "bstorageaccount"
      sku.name:   "Standard_LRS"
      type:       "Microsoft.Storage/storageAccounts"

Resource changes: 1 to create, 0 to ignore.

A workaround for the above example is to move content from C to B. We will then see that two resources are to be created in the what-if command.

I think bicep modules are very useful! However we are currently forced to workaround the issue described here by maintaining large flat template files.

@miqm
Copy link
Author

miqm commented Jun 25, 2021

@alex-frankel?

@alex-frankel
Copy link
Contributor

This is a dup of #157. Just so folks are aware, this is a pretty low-level issue that we need to be careful in resolving. We're trying to get it fixed before end of CY21.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

3 participants