https://pulumi.com logo
Join Slack
Powered by
<@U033KKRC6HY> reports a problem building a provid...
# package-authoring
e
@many-telephone-49025 reports a problem building a provider on the latest Plugin Framework bridge, a bit of back story 🧵
Copy code
error: Resource azapi_resource has a problem: no "id" attribute. To map this resource consider specifying ResourceInfo.ComputeID
error: Resource azapi_update_resource has a problem: no "id" attribute. To map this resource consider specifying ResourceInfo.ComputeID
error: Resource azapi_resource_action has a problem: no "id" attribute. To map this resource consider specifying ResourceInfo.ComputeID
error: Resource azapi_data_plane_resource has a problem: no "id" attribute. To map this resource consider specifying ResourceInfo.ComputeID
This error is now blocking at build time since https://github.com/pulumi/pulumi-terraform-bridge/pull/1623 but even before the fix this error was present (at runtime) and the listed resources would not provision (pulumi up)
b
Obviously all objects are resources, which must define an ID. That's odd.
e
The Pulumi resource model requires an identity attribute which by convention it assumes is called "id"
However in some PF based resources in TF there is no ID
Or it's named differently, or has an unexpected type
https://github.com/pulumi/pulumi-random/issues/607 an issue with RandomBytes led us to this error
RandomBytes has a structural identity based on an attribute called base64..
So, resolution. We now have a ResourceInfo.ComputeID function that's the ultimate tool to resolve these things, it should be able to compute resource identity out of a PropertyMap representing its state
This is how we resolved the problem with RandomBytes.
In case the identity attribute is present but just has an expected name, renaming it to "id" could also work AFIAK.
Let me know if there's any further guidance we can offer on this. Appreciate y'all!
b
Interestingly the resource 
azapi_resource
does not expose it's ID ("id" field not in schema). Never saw that. https://github.com/Azure/terraform-provider-azapi/blob/f4d4045f609cdd2053139b24eac57f6c9dbd5736/internal/services/azapi_resource.go#L422
e
Yeah so this one is not affected because its' written against "github.com/hashicorp/terraform-plugin-sdk/v2/helper/schema"
The sdk/v2 API bakes in the assumption that every resource has an ID
And this does not require the resource to declare an "id" attribute
So the bridge historically had the same assumption
However it seems than the Plugin Framework brave new world there is no such assumption or Framework API I could call into to recover the identity.
Happy to be corrected if I missed something but it seems to be a genuine change in how they do things now.
So basically for terraform-provider-azapi I'd expect that you can upgrade the bridge just fine and not be affected by this at all (and not get the error). Since the resource is SDKv2 based and not PF based.
5 Views
Open in Slack
PreviousNext
Powered by