Bug Reference





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.

API Changes

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 :-

  • Format - The custom Id should follow the UUID format.
  • Uniqueness - It should be unique within the resource type.
  • Optional - This is an optional field and if not set, CS will use its existing custom logic to assign the resource id. If the CS id generation collides with the custom id, it will retry.

Note - This is external Id change only and MS refers to all the objects through the DB ids  


  • Introduce abstract classes containing the custom id which the Create/Update API's can extend.
public abstract class BaseAsyncCreateCustomIdCmd extends BaseAsyncCreateCmd{

@Parameter(name=ApiConstants.CUSTOM_ID, type=CommandType.STRING, description="an optional field, in case you want to set a custom id to the resource")
private String customId;

public String getCustomId() {
 return customId;

  • Create/Update API's can extend these abstract classes
    public class CreateVolumeCmd extends BaseAsyncCreateCustomIdCmd {
    // some code using customId.....
  • Introduce a manager called UuidManager having the following functions - updateUuid() , generateUuid()
public interface UUIDManager {
public interface UUIDManager {

     * Generates a new uuid or uses the customId
     * @param entityType the type of entity
     * @param customId optional custom uuid of the object.
     * @return newly created uuid.
    public <T> String generateUuid(Class<T> entityType, String customId);

     * Checks the uuid for correct format, uniqueness and permissions.
     * @param uuid uuid to check
     * @param entityType the type of entity
     * .
    <T> void checkUuid(String uuid, Class<T> entityType);


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. 

Open Questions

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

  • No labels