DOCSEARCHbyAlgolia
Submit Docs

OpenStack Ironic

repository·master·Indexed 20 days ago

https://github.com/openstack/ironic

OpenStack Bare Metal Provisioning service for managing physical hardware. Features include node adoption for existing hardware, agent-based deployment without BMC credentials using the agent power interface, and OS deployment via the Anaconda deploy interface. Includes documentation on agent token authentication for securing communication between the Bare Metal Service and the ironic-python-agent.

Tokens
201.2K
Snippets
517
Records
884
Agent score
69%

What's inside Ironic

  1. Overview of Ironic Bare Metal Service

    master

    Ironic is a collection of components designed to manage and provision physical machines (bare metal). It provides an administrative API for hardware management and can be integrated with OpenStack Compute (Nova) to provide a user-facing API for instance management.

    Core Components

    • ironic-api: A RESTful API that processes application requests and sends them to the ironic-conductor via Remote Procedure Call (RPC). It can run via WSGI or as a standalone process.
    • ironic-conductor: The orchestration engine that adds, edits, or deletes nodes; manages power (via IPMI or vendor-specific protocols); and handles provisioning, deployment, and cleaning of bare metal nodes. It uses drivers to execute hardware-specific operations.
    • ironic-python-agent: A service running in a temporary ramdisk that provides the ironic-conductor with remote access, in-band hardware control, and hardware introspection.
    • ironic-novncproxy: A service that proxies graphical consoles using the NoVNC web browser interface.
    • ironic-networking: A service that interacts with network switches to configure switch ports. Nodes must be configured to use the ironic-networking interface and have appropriate attributes set on the Ironic port.

  2. Introduction to OpenStack Ironic

    master

    Ironic is an OpenStack project designed to provision bare metal machines. It provides a unified interface to manage a heterogeneous fleet of physical servers using common protocols like PXE and IPMI, as well as vendor-specific remote management protocols.

    Ironic can be used as a standalone service or integrated into an OpenStack Cloud environment, where it interfaces with:

    • Keystone: Identity service
    • Nova: Compute service (allowing physical servers to be managed as if they were virtual machines)
    • Neutron: Networking service
    • Glance: Image service
    • Swift: Object storage service

  3. Overview of the Ironic Bare Metal Service

    master
    Ironic is a collection of components designed to manage and provision physical machines (bare metal) within an OpenStack environment. It provides the orchestration layer necessary to treat physical hardware as cloud resources, similar to how Nova manages virtual machines.

  4. Overview of Ironic bare metal management

    master

    Ironic provides an API and a plugin-based architecture for managing and provisioning physical machines. It is designed to be security-aware and fault-tolerant.

    Key usage patterns include:

    • As a Nova hypervisor driver: Integrating with OpenStack Nova to provide bare metal instances.
    • As a standalone service: Managing physical machines directly via its own API.

    Ironic interacts with hardware using protocols like PXE and IPMI/Redfish. It also supports advanced boot operations such as HTTPBoot or Virtual Media via specific drivers (e.g., Redfish).

  5. Overview of OpenStack Ironic Bare Metal Service

    master

    Ironic is an OpenStack project designed to provision bare metal machines instead of virtual machines. It can be used as a standalone service or integrated into an OpenStack Cloud environment.

    Key integration points include:

    • Identity (Keystone): For authentication and authorization.
    • Compute (Nova): Allows provisioning both virtual and physical machines through the Compute API (though physical machines have limited instance actions, such as the inability to perform live migration).
    • Network (Neutron): For managing network connectivity.
    • Image (Glance): For managing machine images.
    • Object (Swift): For object storage.

    Ironic uses a pluggable driver architecture. The community provides reference drivers for technologies like PXE and IPMI, and hardware vendors can implement custom drivers to add functionality or improve performance.

  6. Alternative installation methods for Ironic

    master

    If you prefer not to perform a manual package installation, you can use several automated deployment projects:

    • Bifrost: Installs Ironic in standalone mode (without the rest of OpenStack).
    • Kolla: Installs Ironic in containers as part of a larger OpenStack deployment.
    • OpenStack-Ansible: Provides specific roles to install Ironic via Ansible.

  8. Access Ironic API, CLI, and Configuration References

    master

    Ironic provides several reference surfaces for developers and administrators:

    • Drivers, Hardware Types, and Hardware Interfaces: Details on how Ironic interacts with different hardware layers.
    • Configuration Reference: Documentation for ironic.conf and other configuration settings.
    • API Reference: The full REST API specification for interacting with the Ironic service.
    • CLI References: Documentation for the ironicclient and internal management tools like ironic-dbsync, ironic-status, and ironic-manage.
    • Trait Based Networking (TBN): Reference for TBN configuration files and filter expressions.

  9. Understand the Ironic release process and responsibilities

    master

    Ironic releases are managed by the OpenStack release team following the standard OpenStack release process.

    Responsibilities:

    • The current Project Team Lead (PTL) is ultimately responsible for ensuring code is released. They may delegate this to a liaison.
    • Anyone can submit a release request, but it must be approved (+1) by the PTL or the designated liaison.

    Release Models: Most Ironic deliverables follow the cycle-with-intermediary release model. Deliverables are categorized into several types:

    • Non-client libraries: e.g., sushy (released at R-6).
    • Client libraries: e.g., python-ironicclient (released at R-5).
    • Normal releases (Plugins/Tools): Includes Neutron plugins (networking-baremetal, networking-generic-switch), Horizon plugins (ironic-ui), Tempest plugins (ironic-tempest-plugin), and tools (ironic-python-agent-builder). These are released at R-5.
    • Services: bifrost, ironic, ironic-prometheus-exporter, and ironic-python-agent. These follow a stabilization phase with RCs at R-3 and a coordinated release at R+0.
    • Independent releases: sushy-tools and virtualbmc follow an independent model.
    • Not released: ironic-specs does not require a release.

  10. Understand Metal3 Continuous Integration for Ironic

    master

    Ironic uses three distinct Metal3-based jobs to validate its functionality within the Metal3 ecosystem:

    1. Metal3 Integration Job: Tests the complete Metal3 workflow, from cluster creation via Cluster API to node provisioning.
    2. Ironic Standalone Operator (IrSO) Functional Tests: Validates how Ironic is installed and managed within Metal3.
    3. Bare Metal Operator (BMO) Functional Tests: Validates various scenarios of interacting with Ironic through the Metal3 API.

    For development and troubleshooting, the metal3-integration job uses the metal3-dev-env workflow to deploy Kubernetes clusters on emulated bare metal nodes.

  11. What is an Agent Token and how does it work?

    master

    An Agent Token is a session identifier or authentication token used to verify the relationship between an operating deployment of the Bare Metal Service and an instance of the ironic-python-agent. It is primarily used to secure communication in untrusted environments, such as edge deployments.

    How it works

    1. Generation: Tokens are randomly generated using the Python secrets library (default length is 43 characters).
    2. Provisioning: Tokens are provided to the agent in one of two ways:
      • Pre-generated: Embedded into virtual media ISOs (read from a configuration file within the image).
      • One-time generated: Provided during the initial lookup of the node.
    3. Lifecycle: Once provided, the token cannot be retrieved or accessed again. It is stored in the memory of the ironic-python-agent and remains available to the conductors.
    4. Authentication:
      • The agent embeds the token in heartbeat operations sent to the Ironic API to authenticate the request.
      • Commands sent from the ironic-conductor to the ironic-python-agent include the token, allowing the agent to authenticate the caller.

    Note: As of the Victoria release, Agent Token usage is mandatory for all agents. The configuration require_agent_token has been removed.

    Warning: This does not eliminate the risk of man-in-the-middle attacks if TLS is not used for all communications.

  12. What is the Redfish Interoperability Profile?

    master

    The Ironic project provides a Redfish Interoperability Profile (located in the redfish-interop-profiles folder at the source code root). This profile is a JSON document designed to:

    1. Merge Requirements and Schema: It combines profile requirements with the Redfish schema into a single, human-readable document for developers and users.
    2. Enable Conformance Testing: It provides a structured format that allows conformance test utilities to verify if a Redfish Service implementation meets the profile's requirements.

    The JSON structure is designed to align with the JSON payloads retrieved from Redfish Service implementations to facilitate easy comparison and testing. Properties with common default values can be omitted from the document to maintain brevity.