Admin should have the ability to control the external facing id of their resources (first class objects). This is important for the admins to have better control over their cloudssay in case of emergencies when he/she wants to recover their resources. For this I propose following changes to be introduced.
All the resource creation/updation API's need to be altered to take in the custom resource id in case the admin wants a custom id. Please note that this is an optional field and if not set, CS will use its custom logic to assign the resource id. Once its updated the resource would start getting referred by the new id.
Example for update APIs - here updateVolumeCmd. http://localhost:8096/client/api?command=updateVolume&id=60e56b83-9af4-4c80-b66b-17c0202cc2ed&customid=60e56b83-9af4-4c80-b66b-17c0202cc2ef
Example for create APIs - here createVolumeCmd. [http://localhost:8096/client/api?command=createVolume&name=fd&zoneId=3f44cb64-79ca-4f29-9f67-d6a850050f96&diskOfferingId=609851eb-5e9c-44f2-81ab-4662b885919b&size=1&customid=60e56b83-9af4-4c80-b66b-17c0202cc2ef|http://localhost:8096/client/api?command=updateVolume&id=60e56b83-9af4-4c80-b66b-17c0202cc2ed&customid=60e56b83-9af4-4c80-b66b-17c0202cc2ef]
Custom id should follow the following :-
Note - This is external Id change only and MS refers to all the objects through the DB ids
UI for admin view will need changes at all the places where we create/update resources such as during deployvm, update vm, create volume etc.
Example - When deploying a vm, the user should have option to pass the custom id
UI will also need to change its logic of listing the resource by the custom id if the resource was updated with the new resource id
No changes to the DB.
Since there are no db changes so no upgrade changes required.
Some of the API's create 2 resources so passing the custom id for both of them ?
Account and User creation already have custom UUIDs