Page History

...

1. Should be able to add guest os
2. Should be able to delete guest os
3. Should be able to modify guest os
4. Should be able to add guest os -> hypervisor emulator platform mapping
5. Should be able to delete guest os -> hypervisor emulator platform mapping
6. Should be able to modify guest os -> hypervisor emulator platform mapping

...

To accommodate Xen specifics (mappings are version specific in some cases), the hypervisor version will be stored in the table too.

Additionally, a table will be needed to store the available platform emulators for a hypervisor.

The admin is responsible for passing the right mapping.

API

The APIs needed are :

1. Create new guest os type
   1. oscategory is required
   2. display name is required. Display names are unique
   3. name is optional (defaults to NULL)
2. Modify guest os type
   1. UUID of guest os to modify is required
   2. display name is required. Display name should be unique
3. Remove guest os type. It is a soft delete.
   
   1. UUID is required
4. List all mappings
   
   1. hypervisor as parameter. Not mandatory. This will list all mappings for given
   List all platform emulators for a
   1. hypervisor
   2. hypervisor version as parameter. Not mandatory. This is used in conjunction with hypervisor
5. Add new mapping. Does not allow duplicate mappings
   
   1. hypervisor, hypervisor version, guest OS name id and platform emulator name as parameters
   Delete
6. Remove existing mapping (some mappings may be marked as non-deletable / editable. This is an open question)a soft delete
   
   1. UUID of mapping is required
   2. hypervisor, guest OS name as parameter
7. Modify existing mapping
   1. UUID is required
   2. hypervisor specific name is required.hypervisor, guest OS name and platform emulator as parameters

The APIs will not allow for duplicate guest OS -> platform emulator mappings for a specific hypervisor.

All the APIs, other than list, shall be async APIs.

The APIs above are sufficient to implement a UI on top of this.

DB Schema

Schema shall be changed as :

• GUEST_OS_HYPERVISOR table that stores the mappings:

ALTER TABLE `cloud`.`guest_os_hypervisor` ADD COLUMN `hypervisor_version` varchar(32) NOT NULL DEFAULT 'default' COMMENT 'Hypervisor version for this mapping';

ALTER TABLE `cloud`.`guest_os_hypervisor` ADD COLUMN `uuid` varchar(40) COMMENT 'UUID of the mapping';

ALTER TABLE `cloud`.`guest_os_hypervisor` ADD CONSTRAINT `uc_guest_os_hypervisor__uuid` UNIQUE (`uuid`);

ALTER TABLE `cloud`.`guest_os_hypervisor` ADD COLUMN `created` datetime COMMENT 'Time when mapping was created';

ALTER TABLE `cloud`.`guest_os_hypervisor` ADD COLUMN `removed` datetime COMMENT 'Time when mapping was removed if deleted, else NULL';

UPDATE `cloud`.`guest_os_hypervisor` SET `uuid` = UUID();

UPDATE `cloud`.`guest_os_hypervisor` SET `created` = now();

• GUEST_OS table changes :

ALTER TABLE `cloud`.`guest_os` ADD COLUMN `created` datetime COMMENT 'Time when Guest OS was created in system';

ALTER TABLE `cloud`.`guest_os` ADD COLUMN `removed` datetime COMMENT 'Time when Guest OS was removed if deleted, else NULL';

UPDATE `cloud`.`guest_os` SET `created` = now();

The ResourceBase / OsMapper files will load the mappings from DB, via the respective Gurus.

...