Trying to use the provider directly with the RPC API I always get "Resource Not Implemented" errors

Terraform Providers Plugin Development
1

I’m directly running the latest provider plugin for aws: “terraform-provider-aws_v5.68.0_x5”.
And I’m using the RPC API to communicate with the plugin from Node.js.
But API calls that require the type_name prop will always give me the following error.

{
  diagnostics: [
    {
      severity: 1,
      summary: 'Resource Not Implemented',
      detail: 'The combined provider does not implement the requested resource type. This is always an issue in the provider implementation and should be reported to the provider developers.\n' +
        '\n' +
        'Missing resource type: '
    }
  ]
}

Example:

const result = await call("PlanResourceChange", {
  type_name: 'aws_s3_bucket',
  prior_state: dynamicValue(null),
  proposed_new_state: dynamicValue({}),
});

Am i doing something wrong or is this a bug?

2

Hey there @ivands :wave:,

Terraform plugins are designed to communicate with Terraform core, so if you’re trying to execute them outside of that context, you’d probably want to follow closely how core works with plugins as well.

On top of using go-plugin for both the client (core) and server (providers), Terraform core will start up the provider process and run the GetProviderSchema RPC, which for certain providers (AWS in particular, since it’s muxed), will load the servers that eventually handle the resource specific RPCs. In addition to that, some RPCs are considered “online”, in that the provider is expecting to receive an RPC call to ConfigureProvider prior to executing the intended RPC; PlanResourceChange is considered an “online” RPC, whereas ValidateResourceConfig is “offline”.

I’d say in your specific scenario, a call to GetProviderSchema and ConfigureProvider should occur before calling PlanResourceChange, although I imagine you’ll run into more issues attempting to call PlanResourceChange unless you emulate all of the same logic that Terraform core does prior to calling it. For example, the ProposedNewState field is relied on heavily by providers for producing an accurate plan.

We have some brief docs on the internals of our RPCs that may help you out, but they are missing a few of the most recent RPCs for provider functions.

For planning specifically, there is also a document that describes all of the assumptions + expectations of providers/core here, as there are constraints on what data the provider is expecting to receive vs. what the provider is expected to produce.

3

Hey @austin.valle,
Thanks for trying to help me out.
I’ve tried the following:
First I get the provider schema.
With the provider schema I can make a list of all the provider config props I need to send to configure the provider.
After i know all the fields, I make an object with all the fields inside but with undefined value’s.
This is because it seems the Configure RPC call requires all the fields to be set.
I then set the config value’s I actually want to set:

  Object.assign(config, {
    profile: "MY_AWS_PROFILE",
    region: "us-east-1",
  });

And when I Configure the RPC call I don’t see any errors.
When the whole configuration flow is finished I make my PlanResourceChange RPC call.
But i always get the same “Resource Not Implemented” error.
Reading the docs that you provided doesn’t really show me what I’m doing wrong.
I’m guessing that the “online” RPC calls are not working yet because the configuration might have failed.
However there are no errors and the debug logs also don’t show any useful info.
How do I proceed here ?

4

Just to make sure we’re on the same page, you’re specifically:

  1. Starting up the provider server (let’s call it process A)
  2. Calling the GetProviderSchema RPC on process A, no diagnostics returned
  3. Calling the ConfigureProvider RPC on process A, no diagnostics returned
  4. Calling PlanResourceChange RPC on process A, “Resource Not Implemented” diagnostic returned.

It’s important that all 3 of these calls happen on the same running provider process since they are stateful.

If that’s what you’re doing then I’m not sure exactly what is wrong off the top of my head. There are plenty of errors I would expect you to run into trying to construct your own custom PlanResourceChange RPC call, but the error you’re describing indicates that the provider server has not been initialized properly.

Reading the docs that you provided doesn’t really show me what I’m doing wrong.

There is no detailed documentation on building a client for a Terraform provider, so the best you’ll find it descriptions of the RPCs, their general purposes, and the actual Terraform source code.

How do I proceed here ?

If it was me, I’d run the AWS provider in debug mode and drop a breakpoint here to verify that this is what’s returning the error. If so, then I’d start looking for this server discovery to be triggered.

Another complexity to consider is the protocol handshake that is handled with go-plugin. The AWS provider is served via protocol v5, which is typically a detail that Terraform core negotiates with the provider. If you’re forcing/defaulting communication with protocol v6, you may be starting the plugin in an invalid state.

Any further debugging, you could always compare how Terraform core interacts with providers vs. your own client to find the delta.

5

@austin.valle Again many thanks for helping out.
I’m indeed calling the RPC calls in the right order on the same process with protocol v5.
The provider is running in debug mode because thats the only way i could start in up.
./terraform-provider-aws_v5.68.0_x5 -debug
If I try to startup the provider without the -debug flag it errors with the following message:
This binary is a plugin. These are not meant to be executed directly. Please execute the program that consumes these plugins, which will load any plugins automatically
I can confirm that the server discovery log is never called.
Even tho I get 0 diagnostic errors when configuring the provider.
Ill try looking searching through the Terraform core code.