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

policyArns in RoleWithPolicyArgs should be input #1197

Open
dhilgarth opened this issue Jan 10, 2024 · 3 comments · May be fixed by #1276
Open

policyArns in RoleWithPolicyArgs should be input #1197

dhilgarth opened this issue Jan 10, 2024 · 3 comments · May be fixed by #1276
Labels
kind/bug Some behavior is incorrect or out of spec vNext-breaking Issues scoped for the next breaking change

Comments

@dhilgarth
Copy link

dhilgarth commented Jan 10, 2024

What happened?

Right now, the policyArns property of RoleWithPolicyArgs is a simple string: https://github.com/pulumi/pulumi-awsx/blob/master/sdk/nodejs/types/input.ts#L309
This forces us to create the service within apply, if we want to use a policy that we also create in the same program.

Example

What I would expect to work:

import * as aws from "@pulumi/aws";
import * as awsx from "@pulumi/awsx"

const policy = new aws.iam.Policy("put-metrics", {
    policy: aws.iam.getPolicyDocumentOutput({
        statements: [{
            actions: ["cloudwatch:PutMetricData"]
        }]
    }).json
});

const service = new awsx.ecs.FargateService("sample", {
    taskDefinitionArgs: {
        container: {
            image: "nginx",
            name: "sample"
        },
        taskRole: {
            args: {
                policyArns: [policy.arn]
            }
        }
    }
})

What I have to do instead:

import * as aws from "@pulumi/aws";
import * as awsx from "@pulumi/awsx"

const policy = new aws.iam.Policy("put-metrics", {
    policy: aws.iam.getPolicyDocumentOutput({
        statements: [{
            actions: ["cloudwatch:PutMetricData"]
        }]
    }).json
});

const service = policy.arn.apply(policyArn => new awsx.ecs.FargateService("sample", {
    taskDefinitionArgs: {
        container: {
            image: "nginx",
            name: "sample"
        },
        taskRole: {
            args: {
                policyArns: [policyArn]
            }
        }
    }
}));

Output of pulumi about

CLI
Version 3.99.0
Go Version go1.21.5
Go Compiler gc

Plugins
NAME VERSION
aws 6.18.0
awsx 2.4.0
docker 4.5.0
docker 3.6.1
nodejs unknown

Host
OS Microsoft Windows 11 Pro
Version 10.0.22631 Build 22631
Arch x86_64

This project is written in nodejs: executable='C:\Program Files\nodejs\node.exe' version='v20.9.0'

Backend
Name laptop-dh
URL file://~
User AzureAD\DanielHilgarth
Organizations
Token type personal

Pulumi locates its logs in C:\Users\DANIEL~1\AppData\Local\Temp by default

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).

@dhilgarth dhilgarth added kind/bug Some behavior is incorrect or out of spec needs-triage Needs attention from the triage team labels Jan 10, 2024
@mjeffryes
Copy link
Contributor

You're absolutely right @dhilgarth. Feel free to submit a PR if we don't get to it first!

@mjeffryes mjeffryes removed the needs-triage Needs attention from the triage team label Jan 10, 2024
@flostadler flostadler self-assigned this Apr 23, 2024
flostadler added a commit that referenced this issue Apr 24, 2024
Previously the policyArns attribute in RoleWithPolicyArgs only
accepted plain types as inputs. This forced users to use
workarounds like using `apply` in order to configure policies
created in the same pulumi program.

Fixes #1197
@flostadler
Copy link
Contributor

Changing policyArns to Input<Input<string>[]> would result in breaking changes.

I’m thinking about adding a new parameter (e.g. policyArnInputs) and marking the old one as deprecated + making the two mutually exclusive.

@t0yv0 @corymhall what do you think?

@flostadler
Copy link
Contributor

Given that adding a new parameter and deprecating the old one wouldn't really improve the usability here, we'd rather make a breaking change and are planning this for the next major version upgrade.
The linked PR has the necessary changes already and just needs some polishing in terms of tests.

@flostadler flostadler added the vNext-breaking Issues scoped for the next breaking change label May 8, 2024
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 vNext-breaking Issues scoped for the next breaking change
Projects
None yet
Development

Successfully merging a pull request may close this issue.

3 participants