[Plugin Framework] Support bridging providers which incorporate both TFPF and SDK resources

[kpitzen]

Hello!

• Vote on this issue by adding a 👍 reaction
• If you want to implement this feature, comment to let us know (we'll work with you on design, scheduling, etc.)

Issue details

Today, when bridging a provider containing Terraform SDK resources and Terraform Plugin Framework resources, we appear to only emit Pulumi resources from the SDK side. For smaller providers, it seems that the upstream contains only one or the other, but in the case of AWS, we have examples of both. This manifested itself by a user noticing we did not support Resource Explorer issue here. This resource does exist in the upstream provider here. Ideally, the bridge would detect these resources alongside the current sdk resources, and emit them into the Pulumi provider using the new TFPF functionality within the bridge.

Affected area/feature

• New module: Muxer
• Bridge (muxer integration)

Update (March 24, 2023): #880

Project Parts

1. The Muxer: A bridge independent muxer that speaks the pulumi grpc protocol. This handles pre-computing token mapping from schemas as well as runtime dispatch and splitting for incoming RPC calls. This is not integrated into the bridge, and can be called independently.
2. Bridge Integration: This allows creating familiar /pkg/tfbridge.ProviderInfo and pf/tfbridge.ProviderInfo and muxing them together via pf/tfbridge.MainWithMuxer functions. This keeps the build process consistent, and handles intermediary build steps. (2) calls into (1) for computing mappings and during the runtime.

Progress on (1)

I have built a muxer component, currently located in x/muxer. It implements single dispatch for calls with obvious targets (such as Create[token=pkg:mod:Resource]) and mapping aware multi-dispatch for more ambiguous calls (such as splitting Configure calls, ensuring that providers get the keys they were expecting and only those). Dispatch is based on a ComputedMapping. It is possible to compute the mapping in advance or compute it as part of starting the muxer.

To compute mappings, the muxer providers:

func Mapping(schemas ...schema.PackageSpec) (ComputedMapping, schema.PackageSpec, error)

muxer.Mapping takes a set of schemas and combines them into a single schema. ComputedMapping remembers which elements from each schema wound up in the final schema.

Progress on (2)

Both pf/tfgen and pf/tfbridge has a MainWithMuxer function. This provides an entry point to muxer that resembles the standard pf/tf{gen,bridge}.Main functions. It takes as input a orderd list of {pf,pkg}/tfbridge.ProviderInfo and serves the providers correctly. Mapping errors (unmapped function errors) work as expected.

[t0yv0]

Thank you for filing this with a concrete example! We will need to figure out what's viable here.

Preliminarily at design doc phase we considered muxed providers via upstream-provided muxing library.

Here's one example of mux code in the context of AWS.

And we were looking at doing an experiment with AWS specifically:

https://github.com/pulumi/home/issues/2389

While that still may be worth doing, I'm leaning to recommend against it as there's way too much risk in rollout as every resource switches to the new BridgePF code path at once.

graph TD;
    Pulumi --> BridgePF;
    BridgePF --> Mux;
    Mux --> TFv2Provider;
    Mux --> TFPFProvider;

Loading

Instead we might need to figure out Pulumi-level mixers and upstream them to pulumi/pulumi SDKs. There's already a homegrown one in Docker, where we mix a handwritten resource with bridged resources. This could look like this, route by resource, and only roll out the new methods for a subset of resources:

graph TD;
    Pulumi --> PulumiMixer;
    PulumiMixer --> BridgePF;
    PulumiMixer --> BridgeV2;
    BridgeV2 --> TFv2Provider;
    BridgePF --> TFPFProvider;

Loading

[iwahbe]

Follow up work:

• [Muxer] Implement Support for GetMappings #946
• [Muxer] Add sanity checks when computing mappings #949

[t0yv0]

I would like to close this as we've spent bit more than planned 5 days and track follow-up in #981

We currently have a PR that's able to deploy aws:route53/cidrCollection:CidrCollection alongside an S3 Bucket that validates the basic design. The PR is not yet mergeable but we're working out the blockers.

I'd count the objectives of the spike achieved - we got evidence the design is viable and we identified work that needs to happen to take it to prod.

[t0yv0]

Interesting, a bit of GitHub eventual consistency issue. Just seeing:

iwahbe closed this as completed in https://github.com/pulumi/pulumi-terraform-bridge/pull/880[11 hours ago](#830 (comment))

[iwahbe]

Re-opening as a tracking issue until #981 closes and this can be used in production.

[iwahbe]

Re-opening as a tracking issue until #981 closes and this can be used in production.

#981 has merged, so I'm closing this tracking issue.