iam: Override role on RolePolicy to accept a Role

[jen20]

This brings RolePolicy in line with RolePolicyAttachment in accepting a Role rather than requiring the ID as a string.

[ellismg]

I think we might want to do this a different way if possible to avoid breaking our API.

[ellismg]

I assume doing this is a breaking change? Could we instead use the AltTypes technology to project the argument as Input<string> | Input<Role>? I believe that would work as expected because we'd marshal the Role by taking the ID of the custom resource, which is what the string here is logically?

/cc @lukehoban

[joeduffy]

I was in fact just talking to @pgavlin about this sort of thing yesterday, as the places where we have strong types can trip up the HCL converter. I believe anywhere we add schema types that aren't just string typedefs, we should do what Matt is suggesting, so we can still accept strings.

[joeduffy]

This has the nice consequence that the dozens (hundreds?) of places we've not yet added the strong typing can be patched up incrementally over time without any breaking changes, something I'm eager to do because I love having the strong types.

[lukehoban]

Yes - we should use AltTypes here to avoid the breaking change. We should ideally do the same in the existing places where Role is used as a strongly typed override.

An example of the "right" pattern is here:

pulumi-aws/resources.go

Lines 437 to 442 in 44eed4b

	"alarm_actions": {
	Elem: &tfbridge.SchemaInfo{
	Type: "string",
	AltTypes: []tokens.Type{awsResource(snsMod, "Topic")},
	},
	},

.

This is a good reminder to write up the API guidelines for these projections - we made a set of decisions about a handful of related topics a few months back but doesn't appears we ever fully documented that. Opened https://github.com/pulumi/pulumi-terraform/issues/209 to track.

[jen20]

If we use AltTypes, does everything underneath just do the "right thing", or does it need additional changes?

[lukehoban]

If you do similar to the alarm_actions example above, everything else should “just work”.

[jen20]

@ellismg I think that latest round of changes should fix this - there was a spurious CI failure which looked network related, but re-kicking the build seems to work OK.

[ellismg]

LGTM.

[ellismg]

Thanks @jen20!