DOCSEARCHbyAlgolia
Submit Docs

Ironic Source Code

website·Indexed 30 days ago

https://naskio.github.io/ironic

Python source code for Ironic, featuring modules for hardware drivers (including Redfish, SNMP, IPMI, and iLO), conductor task management, PXE filtering, and object serialization for node provisioning and deployment.

Tokens
638.1K
Snippets
3.4K
Records
4.7K
Agent score
74%

What's inside Ironic

  1. Overview of Ironic Node Servicing

    Node Servicing allows operators to modify nodes that are currently in the active provision state. Unlike standard deployment or automated cleaning workflows, service steps do not have an automatic execution model, meaning priority values are currently ignored. Operators can monitor the current step being executed via the node's service_step top-level field and view running steps in the driver_internal_info field under service_steps.

  2. Overview of Bare Metal (ironic) service components

    The Bare Metal service, codenamed ironic, manages and provisions physical machines using the following core components:

    • ironic-api: A RESTful API that processes application requests and forwards them to the ironic-conductor via RPC. It can run as a WSGI application or a separate process.
    • ironic-conductor: The primary worker process responsible for adding, editing, and deleting nodes; powering nodes on/off via IPMI or vendor-specific protocols; and provisioning, deploying, or cleaning bare metal nodes. It utilizes drivers to execute hardware operations.
    • ironic-python-agent: A Python service executed in a temporary ramdisk to provide the conductor and inspector services with remote access, in-band hardware control, and hardware introspection.

  3. Overview of the Ironic Conductor Manager

    The ironic.conductor.manager.ConductorManager is the primary class responsible for performing actions on bare-metal resources, including Chassis, Nodes, and Ports. It runs within the ironic-conductor process and receives commands via RPC.

    Key architectural details:

    • Driver Management: Drivers are loaded via entrypoints using ironic.common.driver_factory. Each driver is instantiated once at service start, allowing a single manager to handle heterogeneous hardware.
    • High Availability: Multiple ConductorManager instances can run on different hosts. They cooperatively manage nodes, using the ironic.conductor.task_manager.TaskManager to lock nodes during state-changing operations.
    • Node Distribution: A tooz.hashring.HashRing is used to distribute nodes across active conductors that support the required driver. Rebalancing the ring may trigger environment setup (e.g., TFTP) or Neutron notifications.

  4. Overview of the Ironic Ansible deploy interface

    The ansible deploy interface uses Ansible playbooks to define deployment logic. Unlike the Ironic Python Agent (IPA), it does not generally require IPA to be running in the deploy ramdisk. It provides high flexibility for adapting deployment logic without needing to rebuild the deploy ramdisk or restart the ironic-conductor service.

    Key Constraints:

    • Synchronous Execution: The driver is synchronous. A separate ansible-playbook process is spawned for each node, blocking one thread from the ironic-conductor thread pool until the task finishes or fails.
    • Heartbeat: The deploy ramdisk must call back to the Ironic API heartbeat endpoint. Only the first heartbeat is processed to signal the start of the ansible-playbook process.

  5. Overview of Ironic Python Agent (IPA)

    The Ironic Python Agent (IPA) is a Python-based agent that runs inside a ramdisk on bare metal nodes. It handles critical node actions including inspection, configuration, cleaning, and image deployment. For nodes using the Direct deploy interface, the conductor provides a Swift temporary URL or local HTTP URL, and IPA manages the download and installation of the image onto the machine.

  6. Overview of Ironic Boot Interfaces

    The boot interface manages the booting of both the deploy ramdisk and user instances on bare metal nodes. Ironic supports several types of boot interfaces:

    • PXE/iPXE: Generic network booting. PXE uses TFTP, while iPXE uses HTTP (often requiring PXE bootstrapping).
    • HTTP Boot: Based on UEFI standard v2.5, utilizing HTTP for the boot sequence. Available for ipmi and redfish hardware types.
    • Virtual Media: Vendor-specific implementations that push an ISO image to the management controller, bypassing the need for PXE/iPXE.

  8. Overview of OSProfiler trace points

    OSProfiler is an OpenStack cross-project profiling library that uses trace points consisting of start and stop messages. These messages are sent to a collector (typically Ceilometer, MongoDB, or Elasticsearch) with the following structure:

    • base_id: A UUID shared by all trace points in a single trace, used for easy retrieval.
    • parent_id: The UUID of the parent trace point.
    • trace_id: The UUID of the current trace point.
    • info: A dictionary containing user-provided information passed during the start() and stop() method calls.

  9. Overview of Ironic JSON RPC Server implementation

    The ironic.common.json_rpc.server module implements a subset of the JSON RPC 2.0 specification for communication between the API and conductors. It deviates from the full JSON RPC 2.0 specification in the following ways:

    • No support for batched requests.
    • No support for positional arguments passing.
    • No fallback to JSON RPC 1.0.

  10. Overview of Bare Metal Rescue Mode

    Rescue Mode allows booting a bare metal node into a rescue ramdisk, enabling the rescue user to access the node when the primary OS is inaccessible (e.g., for manual password resets or data recovery). This is supported for hardware types using ironic-python-agent with PXE or Virtual Media boot interfaces. Currently, rescue operations are only supported when tenant networks use DHCP to obtain IP addresses.

  11. Overview of other deploy interfaces

    Ironic provides several specialized deploy interfaces:

    • Anaconda: Used for highly customized deployments via the Anaconda installer.
    • Ramdisk: Used when the item to be deployed is itself a ramdisk.
    • Custom Agent: Allows operators to orchestrate image writing using in-band deploy steps (priorities 61-99) from a custom agent image.

  12. Overview of the Ironic PXE filter service

    The PXE filter service manages the dnsmasq instance used for unmanaged in-band inspection. It allows this dnsmasq instance to coexist with the OpenStack Networking service's DHCP server on the same physical network. It works via a periodic task that compares node IDs of nodes undergoing inspection against all ports, updating dnsmasq host files to allowlist nodes under inspection and denylist others. If any nodes are undergoing inspection, unknown MACs are also allowed; otherwise, they are denied.