Creation of resources with the same name is problematic

[fernando-villalba]

Issue

This issue is a big one and it affects more than the CLI

Currently our interaction with resources hinges on the name of these resources, but we are allowing name duplicates in a lot of different resources, which creates a problematic situation in some scenarios:

For example if you run this command

for _ in {1..8} ; do civo kubernetes create --nodes 1 --size g4s.kube.xsmall test ; done

You are creating 8 clusters of the same name!

% civo kubernetes ls
+--------------------------------------+------+--------------+-------+-------+-------------------------------------+
| ID                                   | Name | Cluster-Type | Nodes | Pools | Conditions                          |
+--------------------------------------+------+--------------+-------+-------+-------------------------------------+
| f4865cba-963a-4ca3-8768-592a427d5673 | test | k3s          |     1 |     1 | Control Plane Accessible: True      |
|                                      |      |              |       |       | All Workers Up: True                |
|                                      |      |              |       |       | Cluster On Desired Version: False   |
|                                      |      |              |       |       |                                     |
+--------------------------------------+------+--------------+-------+-------+-------------------------------------+
| 4f3518ca-182d-499d-bcdc-3bc069ca0c58 | test | k3s          |     1 |     1 | Control Plane Accessible: True      |
|                                      |      |              |       |       | All Workers Up: True                |
|                                      |      |              |       |       | Cluster On Desired Version: True    |
|                                      |      |              |       |       |                                     |
+--------------------------------------+------+--------------+-------+-------+-------------------------------------+
| 658ac935-ecfe-42a7-85e9-6a150d0e4238 | test | k3s          |     1 |     1 | Control Plane Accessible: False     |
|                                      |      |              |       |       | All Workers Up: True                |
|                                      |      |              |       |       | Cluster On Desired Version: Unknown |
|                                      |      |              |       |       |                                     |
+--------------------------------------+------+--------------+-------+-------+-------------------------------------+
| 10135500-c96a-4bd0-a34b-cbd8163ac39e | test | k3s          |     1 |     1 | Control Plane Accessible: False     |
|                                      |      |              |       |       | All Workers Up: True                |
|                                      |      |              |       |       | Cluster On Desired Version: Unknown |
|                                      |      |              |       |       |                                     |
+--------------------------------------+------+--------------+-------+-------+-------------------------------------+
| e84ff843-ea5b-4339-8395-49ed90bc218e | test | k3s          |     1 |     1 | Control Plane Accessible: False     |
|                                      |      |              |       |       | All Workers Up: True                |
|                                      |      |              |       |       | Cluster On Desired Version: Unknown |
|                                      |      |              |       |       |                                     |
+--------------------------------------+------+--------------+-------+-------+-------------------------------------+
| b8d0e8e8-1399-4da4-b02a-4339f928b4cf | test | k3s          |     1 |     1 | Control Plane Accessible: False     |
|                                      |      |              |       |       | All Workers Up: False               |
|                                      |      |              |       |       | Cluster On Desired Version: Unknown |
|                                      |      |              |       |       |                                     |
+--------------------------------------+------+--------------+-------+-------+-------------------------------------+
| b72bdf21-007c-4667-8481-e98b175d0f56 | test | k3s          |     1 |     1 | Control Plane Accessible: Unknown   |
|                                      |      |              |       |       | All Workers Up: False               |
|                                      |      |              |       |       | Cluster On Desired Version: Unknown |
|                                      |      |              |       |       |                                     |
+--------------------------------------+------+--------------+-------+-------+-------------------------------------+
| 39591fdd-c299-4712-a56a-5022dafb1f90 | test | k3s          |     1 |     1 | Control Plane Accessible: False     |
|                                      |      |              |       |       | All Workers Up: False               |
|                                      |      |              |       |       | Cluster On Desired Version: Unknown |
|                                      |      |              |       |       |                                     |
+--------------------------------------+------+--------------+-------+-------+-------------------------------------+

Here you could make the argument that this is fine because you can use the the id to delete the cluster. But the id is not a first class citizen in our interactions with resources, not in the documentation and not in every day usage.

Consider this situation

% civo kubernetes delete test                                                             
Warning: Are you sure you want to delete the test Kubernetes cluster (y/N) ? y
The Kubernetes cluster (test) has been deleted

Which test cluster did I delete? How can I know for sure I didn't delete someone else's test cluster? The CLI won't tell you!

And this isn't even the only issue, if you go into the UI:

There isn't a single clue there what the actual id of each cluster is. In fact, the only way to be able to tell the id of each cluster is clicking on it and looking at the URL of the dashboard, or the DNS name of the cluster:

Finally, if you want to delete a bunch of clusters of the same name by passing the name, you will find yourself in funny situations like this:

 % civo k3s delete $(civo k3s ls -o custom -f name)
Warning: Are you sure you want to delete the test, test, test, test, test, test, test Kubernetes clusters (y/N) ? y
Please check if you are using the latest version of CLI and retry the command 
If you are still facing issues, please report it on our community slack or open a GitHub issue (https://github.com/civo/cli/issues) 
Error: error deleting the kubernetes cluster: DatabaseKubernetesClusterNotFound: Failed to find the Kubernetes cluster in the internal database
% civo k3s delete $(civo k3s ls -o custom -f name)
Warning: Are you sure you want to delete the test, test, test, test, test, test Kubernetes clusters (y/N) ? y
Please check if you are using the latest version of CLI and retry the command 
If you are still facing issues, please report it on our community slack or open a GitHub issue (https://github.com/civo/cli/issues) 
Error: error deleting the kubernetes cluster: DatabaseKubernetesClusterNotFound: Failed to find the Kubernetes cluster in the internal database
 % civo k3s delete $(civo k3s ls -o custom -f name)
Warning: Are you sure you want to delete the test, test, test, test, test Kubernetes clusters (y/N) ? y
Please check if you are using the latest version of CLI and retry the command 
If you are still facing issues, please report it on our community slack or open a GitHub issue (https://github.com/civo/cli/issues) 
Error: error deleting the kubernetes cluster: DatabaseKubernetesClusterNotFound: Failed to find the Kubernetes cluster in the internal database
% civo k3s delete --yes $(civo k3s ls -o custom -f name)
Please check if you are using the latest version of CLI and retry the command 
If you are still facing issues, please report it on our community slack or open a GitHub issue (https://github.com/civo/cli/issues) 
Error: error deleting the kubernetes cluster: DatabaseKubernetesClusterNotFound: Failed to find the Kubernetes cluster in the internal database
% civo k3s delete $(civo k3s ls -o custom -f name)      
Warning: Are you sure you want to delete the test, test, test Kubernetes clusters (y/N) ? y
Please check if you are using the latest version of CLI and retry the command 
If you are still facing issues, please report it on our community slack or open a GitHub issue (https://github.com/civo/cli/issues) 
Error: error deleting the kubernetes cluster: DatabaseKubernetesClusterNotFound: Failed to find the Kubernetes cluster in the internal database

Acceptance Criteria

Here are a few proposed solutions

1. Make the ID a first class citizen when interacting with resources.

This may require disallowing using the name to delete resources and only allowing for non destructive operations with it, such as fetching info.

In order to do this we may need to change how we create ids for resources though to make them more human friendly, instead of using such a long id, we could suffix a shorter id to the name.

2. Continue with the current behaviour for now, but outputting the id of the cluster being deleted. This isn't ideal
3. Disallowing deletion of resources when there is more than one with the same name. This could work as a compromise

In addition we should list the id of the resource, or have shorthand ids to show as part of the UI column

[uzaxirr]

This issue is solved from the API side itself.