Page History

...

Part of the reason is since the OS to hypervisor-specific platform mappings are currently built hard-coded into the code-base

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

...

At the core, the mappings will be stored in a new 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.

...

1. List all platform emulators for a hypervisor
   1. hypervisor as parameter
2. Add new mapping
   1. hypervisor, guest OS name and platform emulator as parameters
3. Delete existing mapping (some mappings may be marked as non-deletable / editable. This is an open question)
   1. hypervisor, guest OS name as parameter
4. Modify existing mapping
   1. 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.

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

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

<Additional details and sequence diagram here>

Comments / Suggestions