Open asarubbo opened 1 month ago
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.
deny server creation that has only numbers as name
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.
check if the numbers refers to a server name and not just to an id.
While this would theoretically be possible, it would be very inefficient. API endpoints only support referencing resources by their IDs, so to make our commands work with resource names, we fetch the list of resources and then search for the name. By checking if the search string is a number, we can skip that step and just use the ID as is. If we searched for the name first every time, we would need to fetch the entire list of resources (which is especially inefficient in the case of servers), even though in almost all of the cases the ID is already provided.
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. hcloud <resource> list
will show you the IDs for each resource.
I believe there is some room for improvement, we can try to guess locally, and then query both GetByID
and GetByName
if no resource was found.
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: 1) deny server creation that has only numbers as name 2) check if the numbers refers to a server name and not just to an id.
Minimal working example