9db3cd1e4d72462eb9303fd917f2d19a823cf4f0
Go to file
Dmitry Tantsur 9db3cd1e4d Graceful way for hardware managers to ignore certain devices
My use case for this feature is to exclude network devices that use
the cdc_ether driver. These USB network interfaces often cause all sorts
of issues. For example, some models have the same hardcoded MAC address,
which breaks inspection.
Currently, to exclude a certain device, a hardware manager must override
the entire listing function (in my case, list_interfaces). Not only is
it tedious, but it also requires constantly updating the hardware
managers to match the implementation in GenericHardware. Realistically,
it will cause hardware manager authors to inherit GenericHardware, which
is the opposite of how hardware managers should be written.
Note that the node-level skip list only affects root device selection
and cleaning for block devices. This feature affects everything that
uses list_block_devices and is applied before the node-level skip list.
This change adds a new hardware manager call filter_device. For each
network, block or USB device, it allows a hardware manager to do either
of four things:
1. Delegate the decision to a lower level hardware manager by raising
 IncompatibleHardwareMethodError
2. Remove the device by returning None
3. Change the device by returning a modified instance
4. Return the device unchanged to keep it in the listing.
Note that I'm removing debug logging when IncompatibleHardwareMethodError
is raised. Not only the log message is incorrect (the error does not
necessarily mean that the method is not implemented at all), it already
noticeable space in the logs, and with this change will become very
noisy.
Change-Id: I5437343af6c6157882bcf0600dd89bd20478c948
Signed-off-by: Dmitry Tantsur <dtantsur@protonmail.com>
2025年07月04日 16:31:02 +02:00
2025年03月18日 17:47:53 +00:00
2025年06月02日 12:30:42 -07:00
2025年02月10日 11:05:12 +00:00
2019年04月19日 19:48:56 +00:00
2025年01月29日 17:30:18 -05:00
2017年09月26日 09:23:53 -07:00
2025年02月07日 15:59:48 -08:00
2023年05月17日 15:38:57 -07:00
2013年09月17日 13:41:59 -07:00
2020年01月15日 12:44:31 +01:00
2025年01月29日 17:30:18 -05:00
2023年05月17日 15:38:57 -07:00
2025年03月26日 19:21:11 +00:00
2024年10月18日 12:14:45 -05:00
2024年04月30日 22:46:45 +09:00
2025年02月10日 11:05:12 +00:00

Ironic Python Agent

Team and repository tags

image

Overview

An agent for controlling and deploying Ironic controlled baremetal nodes.

The ironic-python-agent works with the agent driver in Ironic to provision the node. Starting with ironic-python-agent running on a ramdisk on the 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.

The ironic-python-agent may also be used with the original Ironic pxe drivers as of the Kilo OpenStack release.

Building the IPA deployment ramdisk

For more information see the Image Builder section of the Ironic Python Agent developer guide.

Using IPA with devstack

This is covered in the Deploying Ironic with DevStack section of the Ironic dev-quickstart guide.

Project Resources

Project bugs are tracked on Launchpad:

https://bugs.launchpad.net/ironic-python-agent/+bugs

Developer documentation can be found here:

https://docs.openstack.org/ironic-python-agent/latest/

Release notes for the project are available at:

https://docs.openstack.org/releasenotes/ironic-python-agent/

Source code repository for the project is located at:

https://opendev.org/openstack/ironic-python-agent/

IRC channel:

#openstack-ironic on irc.oftc.net

To contribute, start here: Openstack: How to contribute.

Description
A Python agent for provisioning and deprovisioning Bare Metal servers.
Readme 36 MiB
Languages
Python 99.9%
Shell 0.1%