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

Preview is not always correct for stable output properties #1892

Open
corymhall opened this issue Dec 6, 2024 · 0 comments
Open

Preview is not always correct for stable output properties #1892

corymhall opened this issue Dec 6, 2024 · 0 comments
Labels
kind/bug Some behavior is incorrect or out of spec

Comments

@corymhall
Copy link
Contributor

What happened?

Currently if you update a resource, all outputs are shown as computed
during preview. This means that downstream resources might show a
replacement in the plan if they are using one of those output values.

There are some outputs that we know will not change unless the resource
is replaced (I'm referring to these as "stable" outputs). For stable
outputs we can copy the value from the state in order to show an
accurate preview.

The problem is that the CCAPI schema has no way of determining
programmatically which outputs are stable and which are not. We took the first step in #1891, but we can do better

Couple of ideas on how we can handle this.

  1. readOnly properties that are also a primaryIdentifier
    If a computed output is also part of the primary identifier of the resource then we should be able to assume that it is a stable output.
  2. Create a schema overlay where users can contribute a list of stable outputs per resource. We already have an autoname overlay which we could adapt to be a generalized overlay.

Example

Note: this example won't show the issue after #1891 is merged.

const role = new aws.iam.Role('role', {
  assumeRolePolicy: aws.iam.assumeRolePolicyForPrincipal(
    aws.iam.Principals.LambdaPrincipal,
  ),
});

const asset = archive.getFile({
  type: 'zip',
  sourceFile: path.join(__dirname, 'apps', 'node-app', 'index.js'),
  outputPath: 'lambda_function_payload.zip',
});

const code = new pulumi.asset.FileArchive(asset.then((a) => a.outputPath));
const bucket = new aws.s3.BucketV2('bucket', {
  forceDestroy: true,
});
const object = new aws.s3.BucketObjectv2(
  'object-abcd',
  {
    source: code,
    bucket: bucket.bucket,
    key: 'abc.zip',
  },
);
const handler = new native.lambda.Function('my-function', {
  code: {
    s3Bucket: bucket.bucket,
    s3Key: object.key,
  },
  runtime: 'nodejs20.x',
  handler: 'index.handler',
  role: role.arn,
});

new native.lambda.Permission('permission', {
  functionName: handler.arn,
  action: 'lambda:InvokeFunction',
  principal: 's3.amazonaws.com',
});

Output of pulumi about

n/a

Additional context

No response

Contributing

Vote on this issue by adding a 👍 reaction.
To contribute a fix for this issue, leave a comment (and link to your pull request, if you've opened one already).

@corymhall corymhall added kind/bug Some behavior is incorrect or out of spec needs-triage Needs attention from the triage team labels Dec 6, 2024
@flostadler flostadler removed the needs-triage Needs attention from the triage team label Dec 6, 2024
corymhall added a commit that referenced this issue Dec 12, 2024
Currently if you update a resource, all outputs are shown as computed
during preview. This means that downstream resources might show a
replacement in the plan if they are using one of those output values.

There are some outputs that we know will not change unless the resource
is replaced (I'm referring to these as \"stable\" outputs). For stable
outputs we can copy the value from the state in order to show an
accurate preview.

The problem is that the CCAPI schema has no way of determining
programmatically which outputs are stable and which are not. Because of
this, this PR introduces a heuristic to determine if an output is a
stable output.

- Is the value a `readOnlyProperty` in the schema? This indicates that
  it is a computed output property
- Is the property the resource `id`, `arn` or `name`? If the id, arn, or
  name is a computed property then we can assume that it is a stable
  property. I don't know of any cases where these change outside of a
  resource replacement.

This is not 100% coverage of stable properties, but it should get us
most of the impactful properties. To get close to 100% coverage we will
probably need a schema overlay where we can contribute to mapping these
stable properties for each resource.

Note: as part of this I had to add `readOnly` properties to
`metadata.json`

closes #1141, re #1892
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
kind/bug Some behavior is incorrect or out of spec
Projects
None yet
Development

No branches or pull requests

2 participants