-
Notifications
You must be signed in to change notification settings - Fork 80
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.
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
issue with servers that have numbers as server name #874
Comments
The root cause for this issue actually lays in hcloud-go. Here's the link to the relevant code. I agree that allowing numbers as resource names is a design oversight and shouldn't be allowed. However I don't agree with your proposals to solve this problem.
The API allows this behavior so we can't disallow it. Even if we did, you could still create resources with numeric names from the Console or the API.
My proposal would be to stop using numeric names for resources. You probably want more descriptive names anyway. If you really need to use numeric names, you will still be able to use the resource ID instead of the names. |
I believe there is some room for improvement, we can try to guess locally, and then query both |
If the name of a user-named resource was numeric, it was impossible to `Get` it from its name, since a number would always be interpreted as an ID. This PR fixes this behavior on user-namable resources by continuing to check if a resource with the given `idOrName` exists even though the `idOrName` is numeric and no resource with the given ID was found. See hetznercloud/cli#874
When you create a server an you give it a numeric name, like 123, when you do operations from the cli it does not work, because it threats the number as ID instead of as server name.
In my opinion you should do one of the following:
Minimal working example
The text was updated successfully, but these errors were encountered: