Proposal - Ability to add new guest OS mappings

Introduction

CloudStack currently does not allow an easy way to add new guest OS types, for example, a standard way to add say, CentOS 6.5.

Part of the reason is since the OS to hypervisor-specific platform mappings are currently hard-coded into the code-base (e.g : https://github.com/apache/cloudstack/blob/master/plugins/hypervisors/kvm/src/com/cloud/hypervisor/kvm/resource/KVMGuestOsMapper.java)

To support such new OS addition, the current way is to manipulate the DB using upgrade scripts and make the necessary code changes.

This proposal aims to partially mitigate this issue by allowing the CloudStack admin the ability to add new OS in the list, and update the mapping to hypervisor-specific platform names, via APIs / UI. For now, the admin will be responsible for providing the mapping to hypervisor-specific platform names based on his knowledge, which may be enhanced in future.

Scope

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

Implementation

At the core, the mappings will be stored in a table in DB.The table guest_os_hypervisor may be reused for this purpose (it is not being used elsewhere)

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 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 id and platform emulator name as parameters
6. Remove existing mapping. This is a soft delete
   
   1. UUID of mapping is required
7. Modify existing mapping
   1. UUID is required
   2. hypervisor specific name is required.

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.

<Additional details and sequence diagram here>

Comments / Suggestions