Stuck on an issue?

Lightrun Answers was designed to reduce the constant googling that comes with debugging 3rd party libraries. It collects links to all the places you might be looking at while hunting down a tough bug.

And, if you’re still stuck at the end, we’re happy to hop on a call to see how we can help out.

constant diff from wafv2 with no changes

See original GitHub issue

The following wafv2 config…

  portal_frontend_whitelist_ipset = aws.wafv2.IpSet(
    f'portal-frontend-whitelist-{environment_name}',
    opts=ResourceOptions(provider=aws_provider),
    addresses=portal_frontend_whitelist,
    ip_address_version='IPV4',
    scope='REGIONAL',
    tags={
      'ResourceGroup': aws_resource_group_name
    }
  )

  portal_frontend_acl = aws.wafv2.WebAcl(
    f'portal-frontend-{environment_name}',
    opts=ResourceOptions(provider=aws_provider),
    scope='REGIONAL',
    default_action={
      'Block': {}
    },
    rules=[
      WebAclRuleArgs(
        name='AWS-AWSManagedRulesCommonRuleSet',
        priority=1,
        statement=WebAclRuleStatementArgs(
          managed_rule_group_statement=WebAclRuleStatementManagedRuleGroupStatementArgs(
            vendor_name='AWS',
            name='AWSManagedRulesCommonRuleSet',
          )
        ),
        override_action=WebAclRuleOverrideActionArgs(
          none=WebAclRuleOverrideActionNoneArgs()
        ),
        visibility_config=WebAclRuleVisibilityConfigArgs(
          sampled_requests_enabled=True,
          cloudwatch_metrics_enabled=True,
          metric_name='AWS-AWSManagedRulesCommonRuleSet',
        )
      ),

      WebAclRuleArgs(
        name='portal_frontend_whitelist_ipset',
        priority=2,
        statement=WebAclRuleStatementArgs(
          ip_set_reference_statement=WebAclRuleStatementIpSetReferenceStatementArgs(
            arn=portal_frontend_whitelist_ipset.arn,
          )
        ),
        action=WebAclRuleActionArgs(
          allow=WebAclRuleActionAllowArgs()
        ),
        visibility_config=WebAclRuleVisibilityConfigArgs(
          sampled_requests_enabled=True,
          cloudwatch_metrics_enabled=True,
          metric_name='portal_frontend_whitelist_ipset',
        )
      ),
    ],
    visibility_config={
      'cloudwatchMetricsEnabled': True,
      'metric_name': 'portal-frontend',
      'sampledRequestsEnabled': True,
    },
    tags={
      'ResourceGroup': aws_resource_group_name
    },
  )

produces this diff every time I run pulumi up. The update succeeds, with no changes as far as I can see.

  pulumi:pulumi:Stack: (same)
    [urn=urn:pulumi:portal.test1::portal::pulumi:pulumi:Stack::portal-portal.test1]
    > pulumi:pulumi:StackReference: (read)
        [id=acme/xxx/xxx.devx]
        [urn=urn:pulumi:portal.test1::portal::pulumi:pulumi:StackReference::acme/xxx/xxx.devx]
        name: "acme/xxx/xxx.devx"
    ~ aws:wafv2/webAcl:WebAcl: (update)
        [id=xxx]
        [urn=urn:pulumi:portal.test1::portal::aws:wafv2/webAcl:WebAcl::portal-frontend-test1]
        [provider=urn:pulumi:portal.test1::portal::pulumi:providers:aws::aws_provider::xxxxx]
      ~ rules: [
          ~ [0]: {
                  + name            : "AWS-AWSManagedRulesCommonRuleSet"
                  + priority        : 1
                  ~ statement       : {
                      ~ managedRuleGroupStatement: {
                          + name      : "AWSManagedRulesCommonRuleSet"
                          + vendorName: "AWS"
                        }
                    }
                  ~ visibilityConfig: {
                      + cloudwatchMetricsEnabled: true
                      + metricName              : "AWS-AWSManagedRulesCommonRuleSet"
                      + sampledRequestsEnabled  : true
                    }
                }
          ~ [1]: {
                  + name            : "portal_frontend_whitelist_ipset"
                  + priority        : 2
                  ~ statement       : {
                      ~ ipSetReferenceStatement: {
                          + arn: "arn:aws:wafv2:ap-southeast-2:111111111:regional/ipset/portal-frontend-whitelist-test1-072a323/xxxxxxxxx"
                        }
                    }
                  ~ visibilityConfig: {
                      + cloudwatchMetricsEnabled: true
                      + metricName              : "portal_frontend_whitelist_ipset"
                      + sampledRequestsEnabled  : true
                    }
                }
        ]

requirements.txt

Package           Version
----------------- ---------
Arpeggio          1.10.1
attrs             20.3.0
certifi           2020.11.8
chardet           3.0.4
dill              0.3.3
grpcio            1.33.2
idna              2.10
parver            0.3.1
pip               20.2.3
protobuf          3.14.0
pulumi            2.23.2
pulumi-aws        3.35.0
pulumi-kubernetes 2.8.4
pulumi-postgresql 2.8.1
pulumi-random     3.1.1
PyYAML            5.3.1
requests          2.25.0
semver            2.13.0
setuptools        49.2.1
six               1.15.0
urllib3           1.26.2

Issue Analytics

State:
Created 2 years ago
Reactions:11
Comments:19 (4 by maintainers)

Top GitHub Comments

6reactions

SharpEdgeMarshallcommented, Mar 3, 2022

Any news on this?

2reactions

blampecommented, Jul 9, 2022

I can confirm we’re also seeing this internally at Pulumi. I tested 3 versions of pulumi-aws (ts) which all show the bug – 4.14, 4.28, and 5.9.2.

This is really a pain for us, running pulumi with the CI we have all this noise in the preview output each time.

Sorry you’re running into this. It’s the kind of bug that degrades the usefulness of the CI integration, so it’s top of mind for me. If we always show the user “hey check this out!” when in reality nothing is changing, it’s less likely they’ll notice or care when something actually does change.