Provide a way to dump the TF schema of a bridged provider

[VenelinMartinov]

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

It'd be very useful if a provider binary had a flag to dump the TF schema. This would be invaluable for bug reports against dynamically bridged providers and could also be useful for using the TF schema for analytics purposes.

Affected area/feature

[t0yv0]

Tabular form (stored in CSV or better parquet) could make it quite easy to ingest and cross-analyze. There's a tiny bit of design here to see how this mapping looks like.

[VenelinMartinov]

Should the provider binary be responsible for that or should the binary dump some JSON blob which we can then post-process into whatever form we want?

[t0yv0]

I have not thought this through don't have strong opinions. So long as we can query the end result. I've used a small tool before like https://github.com/pulumi/pulumi-trace-tool for processing some Pulumi program outputs as part of the CI->S3 pipe so there's precedent.

[t0yv0]

There's MarshallableProviderInfo that has mapping information including, I think, TF schema, but it's worth double checking if it is missing anything interesting for us.

You can get it with a flag already:

	dumpInfo := flags.Bool("get-provider-info", false, "dump provider info as JSON to stdout")

For quick and dirty, TF schema itself has a gRPC representation (and every gRPC has associated JSON form). That could be used.

Decisions to be made how to tabularize this though can indeed affect usability for our query scenarios, but we can draw on Pablo's expertise possibly.

[VenelinMartinov]

As @t0yv0, get-provider-info seems to do what we need already. It seems to have the schema and the mapping information.

pulumi-gitlab dump: https://gist.github.com/VenelinMartinov/315dd3da23e6975f6dc37c82255c6b76

I don't see anything interesting missing so I'll close this issue and continue the discussion on the other one.

[VenelinMartinov]

Taking it back: the provider info does not contain information about property constraints like ExactlyOneOf and ConflictsWith which would be useful for #1949

[VenelinMartinov]

ConfigMode is also missing there, which would be useful for #2025