# napalm-redfish

NAPALM driver for server **baseboard management controllers (BMCs)** over
[DMTF Redfish](https://www.dmtf.org/standards/redfish), with a read-only IPMI fallback for
boards that predate Redfish. Built on
[napalm-device-types](https://git.netork.io/NAPALM/napalm-device-types). Written for netOrk.

**Status: early development.** The `redfish` driver (`napalm_redfish.RedfishDriver`, a
`ManagementControllerDriver` from napalm-device-types) implements the NAPALM getters and
the role methods in [docs/redfish-map.md](docs/redfish-map.md), tested end to end against
DMTF mockups. It has not yet run against real hardware; the first test device is a
Supermicro X10DRL-i (BMC firmware 3.91, Redfish). The `ipmi` fallback does not exist yet.

## Why Redfish, and why not one driver per vendor

Redfish is the DMTF's REST API for management controllers. Supermicro (X10 with Redfish
firmware, X11 and later), Dell iDRAC, HPE iLO and Lenovo XCC all implement it. One driver
with small vendor quirk modules covers all of them; a `napalm-supermicro-ipmi` would cover
one.

IPMI over LAN stays a **read-only fallback** for boards without Redfish. Its IPMI 2.0
RAKP handshake hands the password hash to anyone who asks (CVE-2013-4786), so netOrk should
not depend on it. Finding IPMI over LAN enabled is itself worth reporting, see
[docs/security.md](docs/security.md).

## Layout (planned)

| Entry point | Transport | Scope |
|---|---|---|
| `redfish` | HTTPS, Redfish REST (session token or basic auth) | Read, plus power control and BMC reset |
| `ipmi` | IPMI 2.0 over LAN (UDP 623) via `pyghmi` | Read-only: facts, sensors, power state, SEL |

Vendor quirks (Supermicro, Dell, HPE, Lenovo) live in one module per vendor, selected from
the service root's `Vendor`/`Oem` data and `Manager.Model`. No separate entry point per
vendor.

## Documents

- [docs/role.md](docs/role.md): the role base this needs in napalm-device-types (draft)
- [docs/redfish-map.md](docs/redfish-map.md): getters mapped to Redfish resources
- [docs/supermicro-x10.md](docs/supermicro-x10.md): first test device, its Redfish level, IPMI
- [docs/security.md](docs/security.md): credentials, IPMI over LAN, power control
- [docs/testing.md](docs/testing.md): DMTF mockups, emulators, fixtures to record
- [docs/references.md](docs/references.md)

## Building without hardware

Unlike most drivers in this organisation, much of this one can be built and tested
without a device: the DMTF publishes complete mockups of Redfish services (DSP2043), and
both the DMTF Redfish-Mockup-Server and OpenStack's sushy-tools serve them over HTTP.
Recorded output from the X10DRL-i then covers what the mockups do not: an old Redfish 1.0.x
implementation and Supermicro's quirks.

## Conventions

These follow the other drivers in the `NAPALM` organisation:

- Role bases declare, they never implement. Generic logic goes into napalm-device-types,
  vendor mechanics stay here.
- Parsing lives in pure functions, tested on recorded responses under
  `tests/fixtures/<vendor>-<model>-<firmware>/`, with a `COMMANDS.txt` (here: the request
  paths) listing what produced each file.
- `napalm-device-types` is not on PyPI: install it from
  `git+https://git.netork.io/NAPALM/napalm-device-types.git` before this package.

## Usage

```python
import napalm

driver = napalm.get_network_driver("redfish")
with driver("bmc01.example.net", "netork", "secret",
            optional_args={"verify_ssl": "/etc/netork/bmc-ca.pem"}) as bmc:
    bmc.get_facts()           # the BMC: firmware as os_version, its ports
    bmc.get_power_state()     # the server: {"state": "On", "actions": [...]}
    bmc.get_hardware_inventory()
```

Optional args: `port` (443), `verify_ssl` (`True`, `False` or a CA file path; default
`True`), `auth` (`auto`, `session` or `basic`; `auto` uses a Redfish session and falls back
to basic auth only if the service cannot create sessions), `retries` (1).

`reboot_host` restarts the BMC, never the server; the server is switched through
`set_power_state`. `get_config` is not implemented: a BMC has no configuration file.

## Development

```bash
python -m venv .venv && . .venv/bin/activate
pip install git+https://git.netork.io/NAPALM/napalm-device-types.git
pip install -e '.[test]'
pytest
```

Fixtures from the DMTF mockups live under `tests/fixtures/dmtf-<mockup>/`, unmodified, with
the DMTF license and a `COMMANDS.txt` naming the source commit and request paths.

## License

Apache License 2.0, see [LICENSE](LICENSE).