Jump to: navigation, search

BaremetalSplitRationale

Revision as of 22:38, 24 April 2013 by Devananda (talk | contribs) (Roadmap for Tyr)

Project Name

Proposed official name: OpenStack Bare Metal

Proposed code name: Tyr

Summary

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, complete with API and management services and a separate database. Everyone present in the "Baremetal Next Steps" design session agreed that this was 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 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 extension points to interact with vendor-specific control modules (eg, iLO, DRAC) for raid and firmware configuration and management.
  • Provide extension points for multiple deployment models (eg, PXE, chain loading, boot-from-volume, etc).
  • 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.

Project Plan

  • Establish the Tyr project.
  • Split 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 phase it out.

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:


Associated projects (but not dependencies):

Maturity of Project

The baremetal driver was proposed prior to the release of Folsom, but did not land in 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 much of the code was 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, and some companies reported existing deployments based on the Grizzly release.