Jump to: navigation, search

Difference between revisions of "BaremetalSplitRationale"

(Roadmap for Tyr)
(Fixing links and names of related projects.)
 
(10 intermediate revisions by one other user not shown)
Line 3: Line 3:
 
Proposed official name: OpenStack Bare Metal
 
Proposed official name: OpenStack Bare Metal
  
Proposed code name: Tyr
+
Proposed code name: Ironic
 +
 
 +
===Trademarks===
 +
 
 +
None known.
  
 
===Summary===
 
===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
+
Provide a common framework for managing and provisioning physical servers, with pluggable implementations for different architectures, and integrate this with OpenStack such that physical instances can be managed via the same tools and APIs as virtual instances.
 +
 
 +
===Detailed Description===
 +
 
 +
Full description is available here: https://wiki.openstack.org/wiki/Baremetal
 +
 
 +
====Background====
 +
 
 +
The "baremetal" driver is in the Grizzly release of OpenStack Nova, along with an API extension to add, remove, and list 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.
 +
 
 +
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 ====
 +
 
 +
* The baremetal driver already has a separate database; this means that a Nova deployment using this driver must have two database back-ends. This increases the complexity of deploying Nova. By separating OpenStack Bare Metal (Ironic) to its own project, Nova returns to the "one db per project" model.
 +
* Deploying to and managing physical hardware requires a considerable amount 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 Ironic, 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 Ironic; the interface to pass this information out to Quantum already exists, but there is no place to store this in Nova.
 +
 
 +
=== Roadmap ===
 +
 
 +
The project's overall goals, some of which are already implemented in the Nova baremetal driver, are:
 +
 
 +
* 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 physical servers. Initially, this will match the functionality of the Grizzly baremetal driver, but should exceed that within a cycle or two.
 +
 
 +
==== Migration Plan ====
  
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
+
* Establish the Bare Metal (Ironic) project, while maintaining the existing baremetal driver
 +
** Copy the baremetal driver code from Nova, and create repositories for Ironic.
 +
** Create API and management services for Ironic.
 +
** Create a python API client for Ironic.
 +
** Create a virt driver for Nova that talks to Ironic via its API.
 +
* Establish CI for the Ironic project.
 +
* Create a migration path for existing deployments of the Nova baremetal driver.
 +
* Contingent upon passing incubation, at this point we could mark the baremetal driver "deprecated" for a release cycle and then remove it, while continuing development of Ironic.
  
=== Motivation for a split ===
+
==== Project Plan ====
  
* 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.
+
Several baremetal blueprints targeted to Nova could be implemented there or re-targeted to Ironic, depending on the timing of the split. Here are the project's short- and mid-term goals:
* 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 ===
+
* https://blueprints.launchpad.net/cinder/+spec/bare-metal-volumes
 +
* https://blueprints.launchpad.net/quantum/+spec/pxeboot-ports
 +
* https://blueprints.launchpad.net/nova/+spec/baremetal-force-node
 +
* https://blueprints.launchpad.net/nova/+spec/baremetal-compute-takeover
  
* 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 ===
+
Here are some long-term goals of the project, which will require substantial work and are probably better left until after the split:
  
* Establish the Tyr project.
+
* https://blueprints.launchpad.net/nova/+spec/baremetal-operations
* Split the baremetal code from Nova.
+
* https://blueprints.launchpad.net/nova/+spec/improve-baremetal-pxe-deploy
* 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 ===
 
=== Location of Source Code ===
  
https://github.com/openstack/nova/tree/master/nova/virt/baremetal
+
TBD. The code is being split now() and the decision of where to host it hasn't been made yet.
 +
 
 +
The code in Nova can be found at:
 +
 
 +
  nova/api/openstack/compute/contrib/baremetal_nodes.py
 +
  nova/cmd/baremetal*
 +
  nova/virt/baremetal/*
 +
  nova/tests/baremetal/*
  
 
=== Language and Dependencies ===
 
=== Language and Dependencies ===
Line 50: Line 91:
  
 
Project dependencies:
 
Project dependencies:
* https://github.com/stackforge/diskimage-builder -- this builds the ramdisk used during PXE deploys.
+
* https://git.openstack.org/cgit/openstack/diskimage-builder -- this builds the ramdisk used during PXE deploys.
  
  
 
Associated projects (but not dependencies):
 
Associated projects (but not dependencies):
* https://github.com/stackforge/tripleo-image-elements
+
* https://git.openstack.org/cgit/openstack/tripleo-image-elements
* https://github.com/stackforge/os-config-applier
+
* https://git.openstack.org/cgit/openstack/os-apply-config
* https://github.com/stackforge/os-refresh-config
+
* https://git.openstack.org/cgit/openstack/os-refresh-config
 +
* https://git.openstack.org/cgit/openstack/os-collect-config
 +
 
 +
=== Open Source License ===
 +
 
 +
Same as Nova (Apache 2).
  
 
=== Maturity of Project ===
 
=== 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.
+
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.
 +
 
 +
=== Proposed PTL ===
 +
 
 +
Devananda van der Veen has been working on OpenStack since February '12. He started by helping the Infra team and leading many of nova's database improvements during folsom and grizzly, and began shepherding the baremetal code at the Grizzly summit. He recently joined the nova-core review team. Prior to all this, he was a Sr Database Performance Consultant at Percona, where he helped solve database and scalability problems for many companies.
 +
 
 +
=== Other Project Developers ===
 +
 
 +
* Chris Krelle
 +
* Chris Jones
 +
* Arata Notsu
 +
* David Kang
 +
* Mikyung Kang
 +
* Ken Igarashi
 +
 
 +
=== Infrastructure Requirements ===
 +
 
 +
Functional testing of a majority of the codebase is possible with virtual machines. We have already implemented a VirtualPowerDriver which implements the same internal API as the IPMI power driver, thus allowing the code to simulate IPMI control via "virsh" commands. Thus, we expect to be able to integrate with OpenStack's existing test infrastructure to a large degree.
 +
 
 +
We are also looking to hardware vendors who want to demonstrate that their hardware is supported (or who want to add a vendor-specific plugin) to provide hardware on which to run non-gating tests of physical deployments. HP has volunteered a rack of SL 390s to this goal.
 +
 
 +
=== Have all contributors agreed to the CLA? ===
  
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.
+
Yes. The current code is in Nova, after all :)

Latest revision as of 19:04, 24 January 2014

Project Name

Proposed official name: OpenStack Bare Metal

Proposed code name: Ironic

Trademarks

None known.

Summary

Provide a common framework for managing and provisioning physical servers, with pluggable implementations for different architectures, and integrate this with OpenStack such that physical instances can be managed via the same tools and APIs as virtual instances.

Detailed Description

Full description is available here: https://wiki.openstack.org/wiki/Baremetal

Background

The "baremetal" driver is in the Grizzly release of OpenStack Nova, along with an API extension to add, remove, and list 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.

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

  • The baremetal driver already has a separate database; this means that a Nova deployment using this driver must have two database back-ends. This increases the complexity of deploying Nova. By separating OpenStack Bare Metal (Ironic) to its own project, Nova returns to the "one db per project" model.
  • Deploying to and managing physical hardware requires a considerable amount 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 Ironic, 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 Ironic; the interface to pass this information out to Quantum already exists, but there is no place to store this in Nova.

Roadmap

The project's overall goals, some of which are already implemented in the Nova baremetal driver, are:

  • 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 physical 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 Bare Metal (Ironic) project, while maintaining the existing baremetal driver
    • Copy the baremetal driver code from Nova, and create repositories for Ironic.
    • Create API and management services for Ironic.
    • Create a python API client for Ironic.
    • Create a virt driver for Nova that talks to Ironic via its API.
  • Establish CI for the Ironic project.
  • Create a migration path for existing deployments of the Nova baremetal driver.
  • Contingent upon passing incubation, at this point we could mark the baremetal driver "deprecated" for a release cycle and then remove it, while continuing development of Ironic.

Project Plan

Several baremetal blueprints targeted to Nova could be implemented there or re-targeted to Ironic, 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

TBD. The code is being split now() and the decision of where to host it hasn't been made yet.

The code in Nova can be found at:

 nova/api/openstack/compute/contrib/baremetal_nodes.py
 nova/cmd/baremetal*
 nova/virt/baremetal/*
 nova/tests/baremetal/*

Language and Dependencies

Language: Python

Package dependencies:

  • ipmitool
  • open-iscsi
  • syslinux


Project dependencies:


Associated projects (but not dependencies):

Open Source License

Same as Nova (Apache 2).

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.

Proposed PTL

Devananda van der Veen has been working on OpenStack since February '12. He started by helping the Infra team and leading many of nova's database improvements during folsom and grizzly, and began shepherding the baremetal code at the Grizzly summit. He recently joined the nova-core review team. Prior to all this, he was a Sr Database Performance Consultant at Percona, where he helped solve database and scalability problems for many companies.

Other Project Developers

  • Chris Krelle
  • Chris Jones
  • Arata Notsu
  • David Kang
  • Mikyung Kang
  • Ken Igarashi

Infrastructure Requirements

Functional testing of a majority of the codebase is possible with virtual machines. We have already implemented a VirtualPowerDriver which implements the same internal API as the IPMI power driver, thus allowing the code to simulate IPMI control via "virsh" commands. Thus, we expect to be able to integrate with OpenStack's existing test infrastructure to a large degree.

We are also looking to hardware vendors who want to demonstrate that their hardware is supported (or who want to add a vendor-specific plugin) to provide hardware on which to run non-gating tests of physical deployments. HP has volunteered a rack of SL 390s to this goal.

Have all contributors agreed to the CLA?

Yes. The current code is in Nova, after all :)