IRONIC PROJECT
IRONIC AND THE OPENSTACK ECOSYSTEM
Openstack is like the open-source "AWS". OpenStack is an open source platform used to build and manage private and public clouds. Just like AWS it is made up of tools that comprise the OpenStack platform. These tools are called "projects" and they handle the core cloud-computing services. The main ones are compute, networking, storage, identity and image services.
THE OPENSTACK COMPONENTS.
OpenStack's architecture is made up of many open source projects. There are 6 stable core services and other optional/advanced services that extend OpenStack for specific use cases or some still in developmental maturity. The 6 core services are:
Nova : OpenStack compute
Neutron: Neutron connects the networks across other OpenStack services
Swift: object storage services
Cinder: persistent block storage
Keystone: authentication and authorization
Glance: Stores and retrieves VM disk images
IRONIC
Ironic is an optional though intergrated project. Ironic provisions and manages bare-metal machines instead of virtual machines. It may be used independently or as part of an OpenStack Cloud. It integrates with other projects, keystone (identity), nova (compute), neutron (network), glance (image) and swift (Object).
WHY PROVISION BARE METAL INSTEAD OF VMS
normally, OpenStack uses Nova to create virtual machines that run on top of a hypervisor. But in some cases you need direct access to the physical hardware and that's where ironic comes in. This has many advantages and some key are; single tenant, dedicated hardware for perfomance, some databases run poorly in a hypervisor, high-performance compute clusters, some computing tasks require access to hardware devices which can't be virtualized and lastly rapidly deploying cloud infra.
HOW IRONIC WORKS
The ironic service is composed of the following components.
- RESTful API service : this is the interface where other OpenStack services (eg Nova) send requests. The requests could be like "power off this node" , "show me available hardware" etc.
- A Conductor service: does most of the work. It receives the instructions from the API and performs real action. eg Boots the server. so basically, API says what to do, the conductor then does it.
- Drivers. So the hardware may be different brands and models for different users. The drivers are like plugins that know how to talk to different types of machines. Each driver translates ironic's commands for each specific machine.
- Message Queue. Instead of direct API calls between API service and Conductor, the messages are dropped into a shared place. This allows Ironic to handle many servers at once.
- Database: Storage space. Everything Ironic needs to remember eg server name, MAC, power state etc.
This can be described logically as:
A user wants to provision a bare metal instance.
So the user request is passed to the Nova Compute service via Nova API and Nova Scheduler. The Compute Services hands this to the Ironic Service through the Ironic API to the Conductor to a Driver that then provisions a physical server(node) for the user.
PHYSICAL MACHINE - NODE
In Ironic, a node represents a single physical machine (bare-metal server) that ironic manages.
it can be thought of as an object or record in Ironic's database that describes: what hardware, current state(available, deploying, active..) etc.
So basically each node stores metadata about the hardware and how to control it.
EXAMPLES OF THE METADATA
UUID/Name unique ID of the node eg "server01"
Driver eg "redfish" for
Power state eg "power off"
Provisoning state eg "available", "deploying", "active"
NODE LIFECYCLE
As shown so far, everything Ironic does (powering, deploying ..etc) happens through the node. In short the node is the unit of control.
STATE MACHINE DIAGRAM
This is a diagram that shows the provisioning state that an Ironic node goes through during the lifetime of a node. https://docs.openstack.org/ironic/latest/_images/states.svg.
The transitions can be summarised as:
"enroll" - node begins its lifecycle. Ironic basically just records the node's details but does not perform any action on it.
"manageable" - Ironic verifies it can talk to the node. like it has passes hardware inspection.
"available" - node is ready for deployment of an OS or workload.
"deploying" - user has requested a bare metal instance. Can be like OS image is being installed.
"active" - OS or workload has been successfully deployed. the node is now "available" for use.
"cleaning" - say like user is done. instance is deleted. Ironic performs automated cleaning to reset the node to a consistent state for next deployment.
These are just some of the states.
All of this activity, the node state changes, timestamps and outcomes is what give the "node deployment history".
NODE DEPLOYMENT HISTORY
With this users can view the lifecycle of their bare-metal machines just like VM logs.
Why this is important.
- Debugging and auditing - if something fails operators can check the history to see exactly eg where the node got stuck.
- Accountability - see who or what triggered actions.
- Automation and analytics - history data can help automate future actions. eg If 3 deployments fail alert.
EXTENDING IRONIC NODE DEPLOYMENT HISTORY API
The current existing ironic node deployment history might be missing some details or not allowing some filters or searching capabilities.
Extending the node deployment history means improving the way ironic records, stores and exposes life events of the nodes. This is by adding new data, filters and endpoints to make the history more complete and useful for users.
REFERENCES