This message was deleted.

hi again, i finally found time to try this again - without much success... so far (see https://github.com/muhlba91/pulumi-proxmoxve/pull/260/files) i have changed the wrapped provider to the pf one. this was relatively easy and now i get all resources and datasources of the new platform provider BUT i don't get all my old resources of the shim-provider as i have to mux that in. basically i would want to create an instance of the shimv2 provider and mux it directly into the pf provider now. i checked your example of the azure provider and as far as i could tell you are actually muxing in a new resource but not a different wrapped TF provider? could you maybe point me into a direction because so far i think i'm either not seeing anything stipudly simple or there's a catch i just don't know...

@worried-energy-90920 in the old provider you have manually configured resources an data sources into specific modules. You're now using the automapper, which will map resources and data sources into different modules. Options that I can see: 1. Stick to the manual process of mapping data sources and resources. This includes getting the old mappings back, which are deleted right now (according to the diffs) and removing

prov.MustComputeTokens

2. Use the

module_overrides

map, to map resources and data sources to there old names. This would have the benefit of utilizing the automapper and will ease any upgrades of the upstream TF provider. One warning here: ensure that you don't end up with mixture of new old old module names, which will clutter up the namespaces of programming language SDKs. 3. Use the automapper as is and define aliases for the re-mapped "old" resources to the new naming schema. https://www.pulumi.com/docs/concepts/options/aliases/ But that would mean that everybody who used the provider in the past MUST define those aliases. So to me the least favorable alternative.

thanks for your input - highly appreciated! 🙂 and yes, @ancient-policeman-24615's comment to the original post with your mentioned 3 options made my brain click now on how i might progress here - i'll try to see if i can get the automapper to work with the

module_overrides

map since i'd very much like to avoid manually specifying all resources if mapping works well out-of-the-box for new resources.

@worried-energy-90920 what I totally forgot, sorry for that, you can combine the automapper with the old resource and data source mappings. Automapper is smart enough to only map unmapped resources and data sources with the configured strategy. So basically you could leave the old mappings as is and only make sure that the automapper will map new resources and data sources to your defined naming scheme of your modules.

@big-architect-71258 thanks for this info but keeping the old mappings doesn't seem to work for me. it overwrites the module names with the automapper-supplied ones. at least i got the automapper mapping most of the old resources correctly so far although i have one custom field transformer which i still need to figure out how to keep now... however, now, i'm stuck with the error

utils/io.go:20: provider: Failed to close: provider="proxmox@5.26.0-alpha.1709545503+9fbfb32d.dirty" error=EOF

when using a newly built provider locally (the current codebase is https://github.com/muhlba91/pulumi-proxmoxve/tree/fix/provider). did you encounter such errors already and have a pointer?

@worried-energy-90920 1.

automapper

should definitely keep manually defined mappings via the

Resources

and

DataSources

properties and should not push them through the configured mapping strategy. @ancient-policeman-24615 @enough-garden-22763 Am I wrong here at that point? I'm pretty sure I tested this, when I added the feature to my Cookiecutter template. 2. never came accross that error. Hard to tell from which module

pulumi

or

pulumi-terraform-bridge

the error is created

utils/io.go

can be almost everywhere. Do you have a more complete stack trace? Also CC @ancient-policeman-24615 and @enough-garden-22763 here. 🙂

On (1):

prov.MustComputeTokens

doesn’t prevent overriding

Tok

, that is a property of the strategy. To avoid overriding

Tok

, there should be a check for

elem.Tok == ""

here, but there isn’t one. In the bridge, the check is here.

@ancient-policeman-24615 On (1), good to know that this isn't the default. I'll add this to the Cookiecutter Template. 🙏

@ancient-policeman-24615 i ran with

TF_LOG=TRACE

and

-v11

and the only error i find in there is

I0304 15:08:57.268944   80429 eventsink.go:86] eventSink::Error(<{%reset%}>  utils/io.go:20: provider: Failed to close: provider="proxmox@5.26.0-alpha.1709547020+a3df0844.dirty" error=EOF

which is not surrounded by any other error. in general, looking through the logs for

error

i also find these but think they are probably unrelated:

I0304 15:08:44.332519   80429 eventsink.go:78] eventSink::Infoerr(<{%reset%}>I0304 15:08:44.331717   80453 main.go:305] one or more errors while discovering plugins: 3 errors occurred:
<{%reset%}>)
I0304 15:08:44.332569   80429 eventsink.go:78] eventSink::Infoerr(<{%reset%}>	* unmarshaling package.json /Users/daniel/Projects/tmp/proxmoxve/node_modules/resolve/test/resolver/false_main/package.json: json: cannot unmarshal bool into Go struct field packageJSON.main of type string
<{%reset%}>)
I0304 15:08:44.332590   80429 eventsink.go:78] eventSink::Infoerr(<{%reset%}>	* unmarshaling package.json /Users/daniel/Projects/tmp/proxmoxve/node_modules/resolve/test/resolver/invalid_main/package.json: json: cannot unmarshal array into Go struct field packageJSON.main of type string
<{%reset%}>)
I0304 15:08:44.332607   80429 eventsink.go:78] eventSink::Infoerr(<{%reset%}>	* unmarshaling package.json /Users/daniel/Projects/tmp/proxmoxve/node_modules/resolve/test/resolver/malformed_package_json/package.json: unexpected end of JSON input

@worried-energy-90920 Can you send a screenshot of what it looks like when you run

pulumi up

to test? I don’t recall seeing these errors before.

@ancient-policeman-24615 @big-architect-71258 - sure, i attached a screenshot of a normal

pulumi up

run and the full output when run with

TF_LOG

and

v11

set. the only error actually being printed without the log level increased is actually only the closed provider one.

Hey @worried-energy-90920. I’m pretty sure that I found the source of the error: https://github.com/bpg/terraform-provider-proxmox/blob/991db34fe2c77a0d4eb3a465f528f6f8119fdc79/utils/io.go#L17-L25

@ancient-policeman-24615 i analyzed the problem a bit further and realized my testing scenario for new releases was not correct - it seems like i brought in this issue with https://github.com/muhlba91/pulumi-proxmoxve/releases/tag/v5.20.0. investigating further with seeing https://github.com/pulumi/pulumi-terraform-bridge/pull/1569 (especially https://github.com/pulumi/pulumi-terraform-bridge/pull/1569/files#diff-d7506bc5e2599d93505fc453379c5336f9ba3c6ebe03569b9dacba4373c87a1dR313, https://github.com/pulumi/pulumi-terraform-bridge/pull/1569/files#diff-d7506bc5e2599d93505fc453379c5336f9ba3c6ebe03569b9dacba4373c87a1dR331 and https://github.com/pulumi/pulumi-terraform-bridge/blob/f3f47188b9ee67062a7e43465717980ac12a3824/unstable/logging/logging.go#L272) i found out that this error appears in the TF provider BUT there it's just a log entry and doesn't throw an error to make terraform apply fail. pulumi parsing the log and - imo, correctly - assuming this is a "real error" causes this issue. since my testing routine changed with this major update, i obviously just figured it out although it's in the provider since a while already.