This change adds a new introspection data field 'configuration' with two lists: managers and collectors. Change-Id: Ice0d7e6ecff3f319bc3a4f41617059fd6914e31c
8.7 KiB
How it works
Integration with Ironic
Compatible Deploy Drivers
Agent Deploy Driver
IPA works with the agent Deploy driver in Ironic to provision nodes. Starting with ironic-python-agent running on a ramdisk on an unprovisioned node, Ironic makes API calls to ironic-python-agent to provision the machine. This allows for greater control and flexibility of the entire deployment process.
PXE Deploy Driver
IPA may also be used with the original Ironic pxe driver as of the Kilo OpenStack Ironic release.
Configuring Deploy Drivers
For information on how to install and configure Ironic drivers, including drivers for IPA, see the Ironic drivers documentation1.
Lookup
On startup, the agent performs a lookup in Ironic to determine its
node UUID by sending a hardware profile to the Ironic lookup endpoint:
/v1/lookup
.
Heartbeat
After successfully looking up its node, the agent heartbeats via
/v1/heartbeat/{node_ident}
every N seconds, where N is the
Ironic conductor's agent.heartbeat_timeout value multiplied by a number
between .3 and .6.
For example, if your conductor's ironic.conf contains:
[agent]
heartbeat_timeout = 60
IPA will heartbeat between every 20 and 36 seconds. This is to ensure jitter for any agents reconnecting after a network or API disruption.
After the agent heartbeats, the conductor performs any actions needed against the node, including querying status of an already run command. For example, initiating in-band cleaning tasks or deploying an image to the node.
Inspection
IPA can conduct hardware inspection on start up and post data to the
Ironic
Inspector. Edit your default PXE/iPXE configuration or IPA options
baked in the image, and set ipa-inspection-callback-url
to
the full endpoint of Ironic Inspector, for example:
ipa-inspection-callback-url=http://IP:5050/v1/continue
Make sure your DHCP environment is set to boot IPA by default.
For the cases where the infrastructure operator and cloud user are
the same, an additional tool exists that can be installed alongside the
agent inside a running instance. This is the
ironic-collect-introspection-data
command which allows for
a node in ACTIVE
state to publish updated introspection
data to ironic-inspector. This ability requires ironic-inspector to be
configured with [processing]permit_active_introspection
set
to True
. For example:
ironic-collect-introspection-data --inspection_callback_url http://IP:5050/v1/continue
Alternatively, this command may also be used with multicast DNS functionality to identify the Ironic Inspector service endpoint. For example:
ironic-collect-introspection-data --inspection_callback_url mdns
An additional daemon mode may be useful for some operators who wish
to receive regular updates, in the form of the
[DEFAULT]introspection_daemon
boolean configuration option.
For example:
ironic-collect-introspection-data --inspection_callback_url mdns --introspection_daemon
The above command will attempt to connect to introspection and will
then enter a loop to publish every 300 seconds. This can be tuned with
the [DEFAULT]introspection_daemon_post_interval
configuration option.
Inspection Data
As part of the inspection process, data is collected on the machine and sent back to Ironic Inspector for storage. It can be accessed via the introspection data API.
The exact format of the data depends on the enabled
collectors, which can be configured using the
ipa-inspection-collectors
kernel parameter. Each collector
appends information to the resulting JSON object. The in-tree collectors
are:
default
-
The default enabled collectors. Collects the following keys:
inventory
- Hardware Inventory.root_disk
- The default root device for this machine, which will be used for deployment if root device hints are not provided.configuration
- Inspection configuration, an object with two keys:collectors
- List of enabled collectors.managers
- List of enabledHardware Managers
: items with keysname
andversion
.
boot_interface
- Deprecated, use theinventory.boot.pxe_interface
field.
logs
-
Collect system logs. To yield useful results it must always go last in the list of collectors. Provides one key:
logs
- base64 encoded tarball with various logs.
pci-devices
-
Collects the list of PCI devices. Provides one key:
pci_devices
- list of objects with keysvendor_id
andproduct_id
.
extra-hardware
-
Collects a vast list of facts about the systems, using the hardware library, which is a required dependency for this collector. Adds one key:
data
- raw data from thehardware-collect
utility. Is a list of lists with 4 items each. It is recommended to use this collector together with theextra_hardware
processing hook on the Ironic Inspector side to convert it to a nested dictionary in theextra
key.If
ipa-inspection-benchmarks
is set, the corresponding benchmarks are executed and their result is also provided.
dmi-decode
-
Collects information from
dmidecode
. Provides one key:dmi
DMI information in three keys:bios
,cpu
andmemory
.
numa-topology
-
Collects NUMA topology information. Provides one key:
numa_topology
with three nested keys:ram
- list of objects with keysnuma_node
(node ID) andsize_kb
.cpus
- list of objects with keyscpu
(CPU ID),numa_node
(node ID) andthread_siblings
(list of sibling threads).nics
- list of objects with keysname
(NIC name) andnuma_node
(node ID).
Hardware Inventory
IPA collects various hardware information using its Hardware Managers <../contributor/hardware_managers>
,
and sends it to Ironic on lookup and to Ironic Inspector on Inspection.
The exact format of the inventory depends on the hardware manager used. Here is the basic format expected to be provided by all hardware managers. The inventory is a dictionary (JSON object), containing at least the following fields:
cpu
-
CPU information:
model_name
,frequency
,count
,architecture
andflags
. memory
-
RAM information:
total
(total size in bytes),physical_mb
(physically installed memory size in MiB, optional).Note
The difference is that the latter includes the memory region reserved by the kernel and is always slightly bigger. It also matches what the Nova flavor would contain for this node and thus is used by the inspection process instead of
total
. bmc_address
-
IPv4 address of the node's BMC (aka IPMI v4 address), optional.
bmc_v6address
-
IPv6 address of the node's BMC (aka IPMI v6 address), optional.
disks
-
list of disk block devices with fields:
name
,model
,size
(in bytes),rotational
(boolean),wwn
,serial
,vendor
,wwn_with_extension
,wwn_vendor_extension
,hctl
andby_path
(the full disk path, in the form/dev/disk/by-path/<rest-of-path>
). interfaces
-
list of network interfaces with fields:
name
,mac_address
,ipv4_address
,lldp
,vendor
,product
, and optionallybiosdevname
(BIOS given NIC name). If configuration optioncollect_lldp
is set to True thelldp
field will be populated by a list of type-length-value(TLV) fields retrieved using the Link Layer Discovery Protocol (LLDP). system_vendor
-
system vendor information from SMBIOS as reported by
dmidecode
:product_name
,serial_number
andmanufacturer
. boot
-
boot information with fields:
current_boot_mode
(boot mode used for the current boot - BIOS or UEFI) andpxe_interface
(interface used for PXE booting, if any). hostname
-
hostname for the system
Note
This is most likely to be set by the DHCP server. Could be localhost if the DHCP server does not set it.
References
Enabling Drivers - https://docs.openstack.org/ironic/latest/admin/drivers/ipa.html↩︎