Type mismatch between server.id and serverID

[kevinpapst]

Output Server.id returns a string but Input Rdns.serverId expects a number (several other places that expect a serverId as well, also want a number).

Expected behavior

Passing in the server.id should work without conversion:

const xyz = new hcloud.Server("xyz", {
...
}, {
    protect: true,
});

const rdns = new hcloud.Rdns("mydomain.de", {
    serverId: xyz.id,
    ipAddress: xyz.ipv4Address,
    dnsPtr: "mydomain.de",
});

According to https://docs.hetzner.cloud/#servers-get-a-server I believe that ID should be an int/number?

Current behavior

Compile error.

Steps to reproduce

Run the Typescript example from the official docs: https://www.pulumi.com/docs/reference/pkg/hcloud/rdns/#inputs

Affected feature

Just installed Pulumi 3.2.1 on MacOS with @pulumi/hcloud 1.0.0, so I assume latest lib versions.

[lukehoban]

Note that you can convert the string to an int with: serverId: server.id.apply(parseInt).

That said - ideally you should not need this ceremony.

Pulumi id properties are always strings today - but it looks like for Hetzner, we'll need to expose the ID also as a number, as many inputs expect it as an int. Alternatively - we may need to change all places where ids are accepted as inputs to accept strings - to be more consistent with typical provider behaviour.

[lukehoban]

Looks like #46 and #52 are also tracking this same issue.

[stack72]

I'll get a fix tested this morning for this

Paul

[kevinpapst]

Hm, I tried parseInt(server.id) before, but that prevented me from using the preview.
Obviously a little problem that I never used Typescript before 😁 your solution works, thanks!

If you leave a hint how to install your patch (once it is there), I 'd be happy to provide end-user feedback.

Edit: being consistent sounds good. Hetzer seems to use an int in their API, so the question is: do you want to be string consistent in the Pulumi API or do you want to expose the Hetzer internals? There is a good reason for both ways.
But from my view, it shouldn't be the end-users task to typecast these IDs depending on the used object.

[sebandgo]

@stack72 Any update on this?

Don't want to be rude, but pretty much everything / basic functionality relies on the resource.id bit.
IMO, atm the hcloud module it's basically dead in the water.

PS: So far I found a resource that works, hcloud.SshKey works. Firewall, Netowrk, Subnets and Volumes are failing...

[flexwie]

@lukehoban @stack72 Do you have any updates or wold you accept a PR for this?
This issue is making me consider switching back to Terraform for my use case.

[kevinpapst]

Pulumi might be working good with the largest cloud provider, but I guess Hetzner is absolutely not on the priority list (check commit history of this repo).
So many other tools out there to provide the same functionality...

[sebandgo]

You're right, by the look of it this isn't a priority.
What's been reported here so far it's about bugs, not feature requests.
These critical bugs makes Pulumi useless / unusable and I had to carry on with Terraform and to explore their CDK.

[jabbrwcky]

Basically anything with Id in the hcloud provider exhibits the same behaviour: Return IDs as Strings and expect Numbers as input.

[djmaze]

This is still broken and/or wrongly documented.

[srhb]

@AaronFriel Do you have a link to the upstream issue that needs fixing? :)

[ryands17]

Is there an update to this one or a workaround?