fwprovider vs. proxmoxtf

[muhlba91]

Is your feature request related to a problem? Please describe.
I discovered that, e.g., HA resources are encapsulated in the fwprovider package, and not, as all other resources and datasources, in the proxmoxtf package.

This creates an issue with the Pulumi provider (https://github.com/muhlba91/pulumi-proxmoxve) which (can) only map(s) the proxmoxtf exposed resources. Until now, this provider doesn't seem to expose the fwprovider provider resources, and, in fact, those resources cannot be used with the Pulumi provider.

Describe the solution you'd like
The proxmoxtf provider exposes fwprovider resources as well.

Describe alternatives you've considered
None.

Additional context
The Pulumi terraform bridge hooks into one provider, and maps the provider's resources to Pulumi resources. Hence, only one provider can be mapped with one Pulumi provider.

[bpg]

Hi @muhlba91! 👋🏼

That's an interesting one.

As you noted, there are actually 2 provider implementations under the hood: the old v5 version based on Terraform SDK v2 (proxmoxtf) that manages most of the resources, and the new v6 version based on Terraform Provider Framework (fwprovider) that contains new resource like HA or network interfaces. The both implementations are "multiplexed" at the provider's entry point in main.go, so the wrapper server implementing v6 protocol knows which resource is registered in which implementation and routes Terraform RPC traffic accordingly.

After a brief look into the Pulumi provider's code I found that it wraps only proxmoxtf/provider.ProxmoxVirtualEnvironment() implementation, so the one under fwprovider is ignored.

I'm not familiar with the Pulumi API at all, but it might also have an option to "mux" different providers and protocols behind the same API facade? If not, that will be a tricky problem to solve. But I hope this is not the first such case of integration, and someone else have solved it already 🤞🏼

[muhlba91]

thank you for this info! it helped to understand what's the difference and happening here in the background with both versions. 😃

i think i'm on a good path to have that covered in the pulumi provider soon - hence, i'm closing this issue.

[muhlba91]

@bpg i tried muxing the two providers and now run into https://github.com/bpg/terraform-provider-proxmox/blob/main/utils/io.go#L20 with the error EOF, nothing more and nothing less… is there a way to be able to debug that further? any apparent reasons this could happen with an EOF error?

[bpg]

@muhlba91 That's really hard tell where it's coming from. That func is called from multiple places, and it's a deferred call at the end.
I would suspect it is trying to close already closed resource, though can't say which one.

What is the use case you're running? Could you enable terraform debug logs (set env var TF_LOG=debug) and post them here, so we can take a look?
(Logs might have sensitive details like passwords, etc.)

[muhlba91]

@bpg EDIT i think this issue is caused on your side and not the pulumi one... (see next comment for logs)

i ran my pulumi up and pulumi destroy with TF_LOG=TRACE set - see attached screenshots. i can also enable full logging with pulumi if you require more logs but this would also include lots of pulumi related logs...

i receive this error (or similar ones) when creating any resource - VM and File were tested. when destroying them i receive a warning of the HTTP request being closed but, as it's a warning, it goes through successfully.

[muhlba91]

@bpg i recreated this scenario with the TF provider itself to mitigate any pulumi magic and i actually get the same error although it doesn't break the terraform apply. i know why pulumi fails as it's parsing the TF logs and finds an error but i also get the same error with terraform directly. i attached debug logs - see line 1260.

out2.txt

[muhlba91]

@bpg i narrowed down the cause:
https://github.com/bpg/terraform-provider-proxmox/blob/main/proxmox/ssh/client.go#L132
https://github.com/bpg/terraform-provider-proxmox/blob/main/proxmox/ssh/client.go#L139

i created a separate issue for this now: #1111

[bpg]

Thanks @muhlba91! I'll take a look.
Though this error doesn't break anything, it's better to fix the behaviour.

[muhlba91]

@bpg thank you! 👍🏻

yes, i agree they don't break any feature and but they shouldn't appear either, as you say. 🙂

currently, they are making my pulumi provider "useless" because pulumi parses the TF log and if it reads an error log, it aborts the action - imo, this is a pretty correct behaviour.

so i'd be happy if we can get this fixed soon. the other question is if the log level shouldn't be warn instead or error if it doesn't abort the TF action anyway?
i'd expect an error to cause an abort. 🙂