Mogan

= OpenStack Bare Metal Compute =

Without Twists and Turns, Mogan, for Bare Metal Compute As A Service

Why Mogan?
OpenStack Nova supports provisioning of virtual machines (VMs), bare metal and containers. True, BUT, Nova design started off as a virtual machine scheduler, with features specific to this use case. Nova enhancements to unify requesting any compute instance, be it VM, container or Bare Metal, while wonderful, unfortunately is convoluted at best, requiring the user to execute additional steps. Further, it does not yet support the more advanced requirements of bare metal provisioning such as storage and network configuration.


 * All Ironic nodes are associated with a single host aggregate in Nova, because of the notion that a compute *service* is equal to the compute *node*.
 * No affinity/anti-affinity support for bare metals in Nova, as it's based on *host*.
 * No specific APIs for bare metals like RAID configuration, Advanced partitioning at deploy time, Firmware management, etc.



What is Mogan?
Mogan is an OpenStack project which offers bare metals as first class resources to users, supporting variety of bare metal provisioning drivers including Ironic.

The figure below describes how Mogan interact with other OpenStack services to manage bare metal servers.



Services

 * mogan-api: Provides an OpenStack native REST API that processes API requests by sending them to the mogan-engine over RPC.
 * mogan-engine: Interacts with other OpenStack services (like cinder, neutron, glance, etc) through REST API. It transforms and dispatches the user request to drivers to provision bare metal servers.
 * mogan-scheduler: The scheduler service to help select nodes according to users' request, which will integrate with Placement service.

Drivers
Mogan has an abstraction layer for bare metal provisioning drivers. This is what allows you to choose which hypervisor to use for your Mogan deployment. Ironic is the default driver and the main driver we supported, but it's possible to add more provision tools support like maas, cloudboot, etc.



Scheduler
The Placement service is intended to enable more effective accounting of resources and better scheduling of various entities in the cloud. Mogan already migrated resources tracking to Placement service, that makes each ironic node a "resource provider", which has a custom resource class that reference the flavor, in short saying that the flavor requires exactly one thing from that resource class. Nova also has a plan for scheduling ironic resources like this way, but as the flavor contains many virtual machines related stuff, the process is slow.

The resource tracking model is as the following

resource classes:              CUSTOM_GOLD                    CUSTOM_SILVER /        \                          |    resource providers: baremetal_node1     baremetal_node2       baremetal_node2 |                  |                     |    inventories:       {'CUSTOM_GOLD': 1}   {'CUSTOM_GOLD': 1}  {'CUSTOM_SILVER': 1}

However, A parent->child relationship would be more appropriate here to handle NIC/DISK resources on a node. When Placement Nested Resource Providers landed, we will consider to change the tracking model.

Operators may define flavors like this

- baremetal-gold resources: baremeal_gold: 1 resource_traits: baremetal_gold: FPGA resource_aggregates: dev_team: true description: Intel(R) Xeon(R) E5620 2.40GHz 16 cores, 8GB RAM, 4*TB SSD, 4*10Gbps Ethernet

- baremetal-RSD-gold resources: valence-gold-flavor: 1 resource_traits: valence-gold-flavor: PodM1 description: Intel(R) Xeon(R) E5620 2.40GHz 16 cores, 8GB RAM 4*TB SSD, 4*10Gbps Ethernet

The figure below describes how Mogan interact with Placement service.



Node Aggregates
Node aggregate allows the partition of baremetal nodes into logical groups for server distribution. which is quite like Nova host aggregate, but we are based on baremetal nodes.

The figure below describes how we match flavors with aggregates and interact with Placement service.



Server Groups
Mogan Server Groups, make sure servers are on the same or different *affinity zone*, which is quite like nova's server groups, but nova only support *host* based affinity or anti-affinity. We plan to add a special aggregate metadata key *affinity zone* in Mogan. You may define it as failure domains (e.g., by power circuit, rack, room, etc), or whatever you want to make affinity and anti-affnity happen in such groups. More details can be found on Mogan docs after Pike.

RSD Integration(TBD)
Rack Scale Design (RSD) implementations represent the next generation of Software Defined Infrastructure that can be dynamically provisioned across compute, network and storage resources.The fundamental premise for an RSA-based solution is the customers’ ability to “right-size” their end-to-end infrastructure needs according to anticipated workload performance and capacity requirements, across pooled resources.

VALENCE[1] is a controller for pooled and composable resources which adhere to DMTF[2] Redfish[3] with hardware management requests. That includes provisioning and management of RSD components and underlay features.



Mogan Mission Statement
1. To implement services which focus on the management of bare metal computing resources.

2. To promote the speed of bare metal development in OpenStack.

Use Cases
1. A cloud provider wants to deliver vm and bare metal services separately with different capabilities instead of just one service including both vms and bare metals.

2. An enterprise user wants to leverage their already deployed provision tools(instead of Ironic) to provide bare metal cloud by adding a driver to Mogan.

3. An enterprise user wants to manage the RSD(Rack Scale Design) and general hardware in a unified manner.

4. An enterprise user wants more bare metal specific capabilities like Hard Drive, Nics Bond, Firmware, etc management.

= Projects =

mogan-ui
= IRC =

Discussion of the project also takes place in #openstack-mogan on irc.freenode.net. This is a great place to jump in and start your mogan adventure.

= Developers =

Guidelines for developers can be found here: https://wiki.openstack.org/wiki/Ironic/Developer_guidelines Please note that for any non-trivial change that is not a fix for a particular bug, you have to go through the specs review process

For more information please refer to our dev-quickstart doc Mogan devref

= FAQ =

1) What's the relationship between Mogan and Nova?

Compared with Nova, Mogan is dedicated for bare metals, it's more lightweight and with more baremetal specific features which VM users don't need. Nova provides a unified manner for all compute resources management.

2) Does Mogan compete with Nova?

We do not intend to compete with Nova. Nova focuses on VM management and provides many advanced features like live migrating, availability zone, host aggregates, etc. The ironic driver allows to manage baremetals via Nova's API (which is unified for VMs, baremetals, and containers, but in fact, it's customized for VMs). Baremetal instance in Nova seems like a pretended VM which ocuppies all resources of the compute node, While Mogan is designed specifically for baremetals, it offers bare metals as first class resources to users, supporting variety of bare metal provisioning drivers including Ironic.

3) What's the relationship with Mogan and Ironic？

Ironic is integrated into Mogan as a driver, which will be used to deploy(part of provisioning) baremetal node. And also Mogan leverage Ironic API to manage node’s lifecycle.

4) What's the relationship with Mogan and Valence?

Valence is a RSD controller for pooled and composable resources, it provide compose API for pooled resource, and also Redfish endpoint to control composed node. Mogan will contact with RSD through Valence to compose resouces then enroll the composed node to ironic and provision the node like generic nodes.

= References =

[1] https://wiki.openstack.org/wiki/Valence

[2] https://www.dmtf.org/standards/redfish

[3] https://www.dmtf.org/