Bare Metal Service

Cross Project Spec - None

User Story Tracker - None

Problem description

Problem Definition

In order to support certain Enterprise Business Requirements, OpenStack must be able to provision bare metal machines in a secure, multi-tenant, and highly-available fashion, while providing the same integration with other OpenStack services (such as volume storage, console access, etc) as it does for virtual machines.

Some use cases for bare metal machines are:

1. Performance-sensitive applications that want to maximize efficiency, reduce overhead from virtualization, and avoid CPU, Network, or IO fluctuations from neighboring instances.
2. Security-sensitive applications, or applications with regulatory compliance requirements that can not be run on shared hardware.
3. Applications whose licensing costs depend on # of CPUs on the Host, regardles of whether virtualization is in play.
4. Applications that need direct IO access to specialized PCI devices which are not yet virtualizable.

To support these use cases, we need:

1. Bare metal machine configuration: Bare metal machine can be configured with CPU specification, memory capacity, local storage drive type such as SATA or SSD and it’s capacity, and network iplink bandwidth. Infiniband or RoCEE may be needed to achieve network performance.
2. Network Isolation: Networks for one tenant is isolated from other tenants.
3. Storage Service Integration: Bare metal machine can be connected with block device service such as Cinder. Bare metal machine connects cinder backends dedicated to single tenant. Tenant can also back up internal storage of bare metal machine to external block device managed by Cinder and recover from it.
4. Console: Tenant can operate bare metal machine from console, see console log integrated with existing Horizon UI.
5. Unified VM/BM Management: Unified management of both VMs and BMs (Bare metal machines) by software with the similar set of services/functionalities can be provided to users such as FWaaS, LBaaS, VPNaaS, Security Group, Block Storage, Backup, High Availability, Connection to VMs in virtual network (VXLAN), and Console.

Opportunity/Justification

Cloud service providers want to support bare metal machine, but it is a tough challenge to provide IaaS access to bare metal with the same elastic and service-oriented properties as they do with virtual machines.

Requirements Specification

Use Cases

• BMT001 - As an Enterprise user, I want to use bare metal machine so that I get consistent performance not affected by another machine, nor impacted by hypervisor.
• BMT002 - As an Enterprise user, I want to have a secure and clean bare metal machine deployed no matter who used it before.
• BMT003 - As an Enterprise user, I want to create networks elastically so that I can use network like I have these networks not affected by other companies.
• BMT004 - As an Enterprise user, I want to back up internal disk of bare metal and create a snapshot. This can be backed up to an external storage managed by Cinder.
• BMT005 - As an Enterprise user, I want to use bare metal machine integrated with block storage service so that I can use external storage service.
• BMT006 - As an Enterprise user, I want to see bare metal machine from console log and operate from console so that I can analyze problems at booting time and so on.
• BMT007 - As an Enterprise user, I want to continue my operation immediately when a bare metal machine fails without any manual operations such as switchover. Similar to HA VM user story, The user should not have to design the fail-over mechanism themselves. The system should monitor and detect bare metal machine failure and automatically fail-over to a spare bare metal machine.
• BMT008 - As an Enterprise user, I want to use a bare metal machine with the network services such as FWaaS, LBaaS, Security Group, VPNaaS, and connection to VMs in virtual network(VXLAN) in the same manner of VMs.

Usage Scenario Examples

1.Successful bare metal service

1. Enterprise user creates virtual network.
2. Enterprise user boots bare metal machine.
3. Enterprise user uses block storage from bare metal machine.
4. Enterprise user uses bare metal machine with consistent performance.

2.Analyze bare metal machine rebooting problem

1. Enterprise user can’t connect to bare metal machine remotely when rebooting.
2. Enterprise user can see state of bare metal machine from console log.
3. Enterprise user analyzes boot problem and resolved the issue.
4. Enterprise user can boot successfully.

3.Bare metal machine data protection

1. Enterprise user backs up data in bare metal machine.
2. Enterprise user restore from data backed up.

Related User Stories

• High Availability for Virtual Machines

Requirements

None.

External References

• [RFE] [Ironic] Ironic Neutron ML2 Integration
• [SPEC] [Ironic] Update of the Ironic Neutron Integration spec
• [RFE] [Ironic] VLAN Aware Baremetal Instances
• [SPEC] [Ironic] VLAN Aware Baremetal Instances
• [BP] [Nova] Tenant networking support for Ironic driver
• [SPEC] [Nova] Tenant networking support for Ironic driver
• [RFE] [Ironic] Add volume connection information into ironic db
• [SPEC] [Ironic] Volume connection information for Ironic nodes
• [BP] [Nova] Add support for Ironic nodes to boot from Cinder volume
• [RFE] [Ironic] Nova serial console support for Ironic
• [SPEC] [Ironic] Nova serial console support
• [SPEC] [Ironic] Add nova-compatible-serial-console.rst to not-implemented
• [RFE] [Ironic] Bare metal node N+1 redundancy
• [SPEC] [Ironic] Bare metal node N+1 redundancy

Rejected User Stories / Usage Scenarios

None.

Glossary

TBD.