Improve error messages about devpod-provider-hetzner

[neingeist]

Just for searchability: The screenshot says

info Error:   (server_error)

[mrsimonemms]

Aaaah, now I understand the request - apologies.

It looks like it's a Hetzner error code.

I think there is an improvement that can be made, which is to put the Hetzner error into a nicer format - instead of just <err.code>, something like <err.code>: <err.message> - <err.details>. It might get a bit big, but I think I can do something better than what it is now.

Thanks for the clarification.

[neingeist]

Thanks for the clarification.

Pleased to clarify ;) I had it mixed-up a bit first, due to multiple problems at once (my mistake of changing the region while not thinking about the volume, Hetzner's hickup today + the inconsistent state of the workspace/leftover SSH key).

[neingeist]

A second thing I notice: The error was logged as info, should probably be at level error, if that's possible.

[mrsimonemms]

Unless I'm reading it wrong, the error is already printed out (the SSH key uniqueness error).

The usage error is Cobra's standard setting of outputting the usage after all errors - I think it's here in the docs.

I'm not against changing it, but it does seem like a lot of faff for not much benefit

[neingeist]

Yes but this was a second error! After removing the SSH key manually via Hetzner's Web interface (probably some inconsistent state after the Hetzner problems today), I get the original error:

Any ideas on that?

[neingeist]

Ah, I had a volume from the wrong region left - after deleting that, creating the workspace worked again. And then I got confused by Hetzner's service issues.

I'm not sure if devpod-provider-hetzner can give better error messages than (server_error) in this case. Please decide if you want to keep the issue open.

[neingeist]

I think there is an improvement that can be made, which is to put the Hetzner error into a nicer format - instead of just <err.code>, something like <err.code>: <err.message> - <err.details>. It might get a bit big, but I think I can do something better than what it is now.

That does sound like it would be an improvement, at least I would expect that Hetzner API would tell me what is wrong.

The actual problem might be easily reproducible by 1. changing the Hetzner region used in the provider and 2. rebuilding the workspace. I think this provider should then try to re-use the volume - and fail because of the region change. (I use DevPod and devpod-provider-hetzner since yesterday and might not understand the details properly.)