Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

refactor: externalize NewFrameworkProvider as we do with SDKv2 Equinix Provider for easier downstream Pulumi provider #619

Open
ocobles opened this issue Mar 11, 2024 · 2 comments · May be fixed by #735
Open

refactor: externalize NewFrameworkProvider as we do with SDKv2 Equinix Provider for easier downstream Pulumi provider #619

ocobles opened this issue Mar 11, 2024 · 2 comments · May be fixed by #735

Comments

@ocobles
Copy link
Contributor

ocobles commented Mar 11, 2024 •
edited
Loading

Comparing our Pulumi and Terraform provider to the Talos provider and their effort to work with an internal/ provider, siderolabs/terraform-provider-talos#130, I see that Talos had internalized the provider and needed to revert that to simplify the shimming.

Looking at how the Pulumi providers wrap the SDKv2 and Framework providers, it appears that this is the only resource from TF that they depend on -- the provider objects.

For example:
https://github.com/pulumiverse/pulumi-talos/blob/main/provider/resources.go#L35

Our SDKv2 Provider is exposed today as equinix.Provider. We intentionally left this object in an exported package because of the dependency that Pulumi and Crossplane (at the time) had on this object.

Looking at the Equinix TF provider, I think within equinix/provider.go we can export a framework provider function (name doesn't matter -- equinix.NewFrameworkProvider(version, ua string)?) that effectively calls on https://github.com/equinix/terraform-provider-equinix/blob/main/internal/provider/provider.go#L27C1-L32C1

The Pulumi Equinix shim would take the return value of that function. With the New... function exported and taking user-agent as an argument, we wouldn't need the submodule, shim patch, or the UA patch.

Originally posted by @displague in equinix/pulumi-equinix#79 (comment)
@ocobles ocobles changed the title Comparing our Pulumi and Terraform provider to the Talos provider and their effort to work with an internal/ provider, https://github.com/siderolabs/terraform-provider-talos/issues/130, I see that Talos had internalized the provider and needed to revert that to simplify the shimming. refactor: externalize NewFrameworkProvider as we do with SDKv2 Equinix Provider for easier downstream Pulumi provider Mar 11, 2024
@ctreatma
Copy link
Contributor

Based on the difficulties we ran into with refactoring provider resources into isolated packages, we probably don't want to (and maybe can't) tie the framework provider back into the equinix package/directory.

I'm hesitant to introduce a public interface to satisfy Pulumi--and thus establish that there is some broader validity in consuming this provider as a Go module rather than a plugin binary--but if we do go that route, we should introduce a new package for that purpose and hide both the SDK and framework providers behind it.

@displague
Copy link
Member

if we do go that route, we should introduce a new package for that purpose and hide both the SDK and framework providers behind it.

Cyclical dependencies have been a concern with the refactor. That would make sense.

@ctreatma ctreatma linked a pull request Jul 19, 2024 that will close this issue
Open
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
3 participants
@displague @ctreatma @ocobles