Difference between revisions of "BaremetalSplitRationale"

Revision as of 02:20, 25 April 2013

The "baremetal" driver is in the Grizzly release of OpenStack Nova, along with an API extension to add, remove, and list baremetal nodes (physical machines) and associated interfaces (MAC addresses). By enabling this hypervisor driver, Nova is able to drive image deployments to physical machines using PXE and IPMI. A more full description is available here: https://wiki.openstack.org/wiki/Baremetal

At the Havana Design Summit, the idea was discussed among nova-core and some other PTLs to split the baremetal driver out into its own top-level project as was done with Cinder. Everyone present in the "Baremetal Next Steps" session agreed that this would be A Good Thing. The etherpad for that session is here: https://etherpad.openstack.org/HavanaBaremetalNextSteps

Motivation for a split

Baremetal already has a separate database; this means that a Nova deployment using the Baremetal driver must have two database back-ends. This increases the complexity of deploying Nova. By separating Baremetal to its own project, Nova returns to the "one db per project" model.
Deploying to and managing physical hardware requires a considerable about of information which is unrelated to virtualized deployments. Accessing the currently-minimal information via Nova's API is already awkward; adding more such information seems like the wrong approach. Separating this out of Nova, and into its own API, would help reduce Nova's complexity and create a clear separation between physical and virtual deployments.
Operational teams often perform tasks on hardware which do not apply to virtual machines (eg., discovery, HW RAID configuration, firmware updates, burn-in). These could be added as Nova API extensions, but again, it seems like the wrong approach. Instead, a separate API could manage hardware before exposing via the Nova API. For example, after being discovered, configured, updated, and burned in by Tyr, it could then be enrolled with Nova and provisioned as any other cloud instance (eg, via "nova boot").
Due to physical constraints, there are some interactions with other projects (Quantum, Cinder) which do not apply to virtual environments. For example, some environments may have pre-configured VLANs which Quantum must be aware of before it can properly determine the network configuration for a bare metal tenant. Knowledge of the HW interface <-> VLAN relationship should be modeled inside of Tyr; the interface to pass this information out to Quantum already exists, but there is no place to store this in Nova.

Roadmap for Tyr

Provide an API to discover and interrogate hardware, but store only the minimal necessary information for hardware configuration and provisioning. Initially, this will just be: cpu arch and # of cores, ram, disk space, mac address(es), and power management information. Further information (eg, output of "lspci") may be stored for later retrieval via the API. Any information which can not be discovered (eg, IPMI credentials) may be added or updated via the API.
Provide an API for managing machine power state.
Provide an API for deploying a cloud image to a machine.
Provide an API for managing BIOS settings and updating firmware.
Provide a generic implementation which satisfies the above APIs on common architectures.
Provide extension points to interact with vendor-specific control modules (eg, iLO, DRAC).
Provide extension points for multiple deployment models and vendor-specific deployments.
Provide API bindings within Nova's virt driver interface to allow provisioning bare metal servers. Initially, this will match the functionality of the Grizzly baremetal driver, but should exceed that within a cycle or two.

Migration Plan

Establish the Tyr project, while maintaining the existing baremetal driver
- Copy the baremetal code from Nova.
- Create API and management services for Tyr.
- Create a python API client for Tyr.
- Create a virt driver for Nova that talks to the new project via its API.
Establish CI for the Tyr project.
Once Tyr is deemed stable and has reached feature-parity with the Nova baremetal driver, mark the baremetal driver "deprecated" for a release cycle and then remove it, while continuing development of Tyr.

Project Plan

Several baremetal blueprints targeted to Nova could be implemented there or re-targeted to Tyr, depending on the timing of the split. Here are the project's short- and mid-term goals:

Here are some long-term goals of the project, which will require substantial work and are probably better left until after the split:

Location of Source Code

https://github.com/openstack/nova/tree/master/nova/virt/baremetal

Language and Dependencies

Language: Python

Package dependencies:

ipmitool
open-iscsi
syslinux

Project dependencies:

https://github.com/stackforge/diskimage-builder -- this builds the ramdisk used during PXE deploys.

Associated projects (but not dependencies):

Maturity of Project

The baremetal driver was proposed prior to the release of Folsom, but none of the code landed at that time. It was initially written as a collaboration between NTT-Docomo and USC/ISI, with specific contributions by Mikyung Kang and David Kang at ISI, Arata Notsu at VirtualTech, and Ken Igarashi at NTT. Stewardship of the codebase was passed to Devananda van der Veen and the TripleO team at the Grizzly summit, and over the following months the code was cleaned up and partially rewritten. The driver and main changes landed during G-1 and G-2 with significant bug fixes during G-3, led by Devananda. The baremetal driver currently has a stable core, but there are many additional features which need to be implemented before it is mature and robust overall.

Substantial community interest - in both leveraging the driver and contributing to the project - was expressed at the Havana summit, with some companies reporting deployments based on the Grizzly release.

@@ Line 20: / Line 20: @@
 === Roadmap for Tyr ===
-* Provide an API to interrogate hardware, but store only the minimal necessary information for hardware configuration and provisioning. Initially, this will just be: cpu, ram, disk space, power management, and mac addresses. Further information (eg, output of "lspci") may be stored for later retrieval by an external CMDB.
+* Provide an API to discover and interrogate hardware, but store only the minimal necessary information for hardware configuration and provisioning. Initially, this will just be: cpu arch and # of cores, ram, disk space, mac address(es), and power management information. Further information (eg, output of "lspci") may be stored for later retrieval via the API. Any information which can not be discovered (eg, IPMI credentials) may be added or updated via the API.
-* Provide extension points to interact with vendor-specific control modules (eg, iLO, DRAC) for raid and firmware configuration and management.
+* Provide an API for managing machine power state.
-* Provide extension points for multiple deployment models (eg, PXE, chain loading, boot-from-volume, etc).
+* Provide an API for deploying a cloud image to a machine.
+* Provide an API for managing BIOS settings and updating firmware.
+* Provide a generic implementation which satisfies the above APIs on common architectures.
+* Provide extension points to interact with vendor-specific control modules (eg, iLO, DRAC).
+* Provide extension points for multiple deployment models and vendor-specific deployments.
 * Provide API bindings within Nova's virt driver interface to allow provisioning bare metal servers. Initially, this will match the functionality of the Grizzly baremetal driver, but should exceed that within a cycle or two.