Files
NetBox-Concept/README.md
T
MrBlakeandClaude Sonnet 5 17cf94ac0d Add netbox_rack_concept plugin: rack blueprint planning
Introduces a NetBox 4.6 plugin for planning rack layouts (RackConcept,
ConceptDevice) without creating real dcim.Rack/dcim.Device objects, so
blueprints never appear in rack/device lists, utilization reports, or
IPAM.

Features:
- Copy paths: real rack -> concept, concept -> concept (clone), and
  concept -> one or more real racks (deploy, with name patterning and
  dry-run support)
- Manual concept creation via a dedicated "Rack Concepts" nav menu
- Tenant and tenant group assignment on concepts and planned devices
- Partial-width device placement (1/1-1/4) with slot-based collision
  detection, matching netbox_utilities' partial-width feature
- Custom drag-and-drop elevation (netbox-reorder-rack operates on real
  Device querysets, which concepts don't have) with server-side
  validation of every move
- Full REST API, filtering, CSV import, bulk edit, search integration
- Optional, config-driven interop with netbox_utilities (partial-width
  field mapping) and netbox-reorder-rack, degrading gracefully when
  either plugin is absent

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
2026-09-16 09:00:26 +02:00

176 lines
6.3 KiB
Markdown
Raw Blame History

This file contains ambiguous Unicode characters
This file contains Unicode characters that might be confused with other characters. If you think that this is intentional, you can safely ignore this warning. Use the Escape button to reveal them.
# netbox-rack-concept
Rack-Blaupausen für NetBox 4.6. Ein „Rack Konzept" ist ein vollständig geplantes Rack
samt Einbauten — aber **kein** echtes Rack und **keine** echten Geräte. Konzepte tauchen
deshalb weder in der Rack-Liste noch in der Geräte-Liste auf, verfälschen keine
Auslastungs-Auswertungen und belegen keine Seriennummern oder IP-Adressen.
Wenn die Planung steht, wird das Konzept per Knopfdruck in echte NetBox-Objekte
überführt — ein Mal oder gleich zwanzig Mal.
## Was das Plugin kann
| Weg | Wo |
|---|---|
| Echtes Rack → Konzept | Button **„Copy to concept"** auf der Rack-Detailseite |
| Konzept → Konzept (Variante) | Button **„Clone concept"** auf der Konzept-Detailseite |
| Konzept → echte Racks (n-fach) | Button **„Deploy to NetBox"**, mit Namensschema `DC1-R{n:02d}` |
| Konzept von Hand anlegen | Menü **Rack Concepts → Rack Concepts → +** |
Dazu:
* **Elevation mit Drag & Drop** – Geräte per Maus verschieben, serverseitig validiert.
Ein ungültiger Zug wird abgelehnt und ändert nichts.
* **Teilbreiten** (1/1, 1/2, 1/3, 1/4 plus horizontale Slot-Position), passend zum
Teilbreiten-Feature von `netbox_utilities`.
* **Mandant und Mandantengruppe** an Konzept und an jedem geplanten Gerät.
* **Platzhalter ohne Gerätetyp** – reservierter Bauraum, nur mit Höhenangabe.
* Vollständige REST-API, Filter, CSV-Import/-Export, Bulk-Edit, Changelog, Journal,
Tags, Custom Fields und globale Suche — wie bei jedem Core-Objekt.
## Zusammenspiel mit den anderen Plugins
**netbox-reorder-rack (rackorder)** arbeitet auf `dcim.Device`-Querysets. Ein Konzept hat
per Definition keine, also bringt dieses Plugin eine eigene Drag-&-Drop-Elevation mit
(`static/netbox_rack_concept/elevation.js`). Sobald ein Konzept ausgerollt ist, ist das
Ergebnis ein ganz normales Rack — ab da greift reorder-rack wie gewohnt.
> Hinweis zur Version: `netbox-reorder-rack` **v1.1.5 setzt NetBox 4.7 voraus**. Für
> NetBox 4.6.8 die letzte 4.6-taugliche Version pinnen (`netbox-reorder-rack<1.1.5`).
**netbox_utilities** liefert die Teilbreiten für echte Geräte. Beim Ausrollen schreibt
dieses Plugin die Werte `width_fraction` und `horizontal_position` dorthin zurück; beim
Kopieren eines echten Racks liest es sie von dort. Da die Feldnamen von `netbox_utilities`
nicht öffentlich dokumentiert sind, stehen sie in `PLUGINS_CONFIG` (siehe unten) und
lassen sich ohne Code-Änderung anpassen. Ist `netbox_utilities` nicht installiert oder
passt das Mapping nicht, werden Teilbreiten schlicht nicht geschrieben — alles andere
funktioniert weiter, und es landet eine Warnung im NetBox-Log.
## Installation
```bash
source /opt/netbox/venv/bin/activate
pip install /pfad/zu/netbox-rack-concept
```
In `configuration.py`:
```python
PLUGINS = [
'netbox_rack_concept',
# optional, in beliebiger Reihenfolge:
'netbox_utilities',
'netbox_reorder_rack',
]
```
Dann:
```bash
cd /opt/netbox/netbox
python manage.py migrate
python manage.py collectstatic --no-input
sudo systemctl restart netbox netbox-rq
```
> Sollte `migrate` die mitgelieferte Migration nicht anwenden können, weil sich in eurer
> NetBox-Installation Basisfelder unterscheiden: `netbox_rack_concept/migrations/0001_initial.py`
> löschen und `python manage.py makemigrations netbox_rack_concept` laufen lassen.
> Die Migration ist von Hand geschrieben und gegen NetBox 4.6.8 erstellt, aber nicht in
> eurer Umgebung getestet.
## Konfiguration
Alle Werte sind optional; gezeigt sind die Defaults.
```python
PLUGINS_CONFIG = {
'netbox_rack_concept': {
# Vorbelegung beim Anlegen eines neuen Konzepts
'default_u_height': 42,
'default_width': 19,
# "Copy to concept"-Button auf der Rack-Seite anzeigen
'enable_rack_tab': True,
# Status der Objekte, die beim Ausrollen entstehen
'deployed_rack_status': 'planned',
'deployed_device_status': 'planned',
# Anbindung an die Teilbreiten von netbox_utilities.
# 'model' leer lassen, wenn netbox_utilities die Felder direkt an dcim.Device hängt.
'partial_width': {
'enabled': True,
'model': 'netbox_utilities.RackDevicePosition',
'device_field': 'device',
'fraction_field': 'width_fraction',
'position_field': 'horizontal_position',
},
}
}
```
## REST-API
Basis-Pfad: `/api/plugins/rack-concepts/`
| Methode | Endpunkt | Zweck |
|---|---|---|
| `GET/POST` | `concepts/` | Konzepte auflisten und anlegen |
| `GET/PATCH/DELETE` | `concepts/{id}/` | Einzelnes Konzept |
| `POST` | `concepts/copy-from-rack/` | Echtes Rack in ein Konzept kopieren |
| `POST` | `concepts/{id}/clone/` | Konzept duplizieren |
| `POST` | `concepts/{id}/deploy/` | Konzept ausrollen (`dry_run` möglich) |
| `GET` | `concepts/{id}/elevation/` | Berechnete Elevation als JSON |
| `GET/POST` | `devices/` | Geplante Geräte |
Beispiel — zehn Racks aus einem Konzept, erst als Trockenlauf:
```bash
curl -s -X POST https://netbox.example/api/plugins/rack-concepts/concepts/3/deploy/ \
-H "Authorization: Token $NETBOX_TOKEN" \
-H "Content-Type: application/json" \
-d '{
"name_pattern": "DC1-R{n:02d}",
"count": 10,
"start_index": 1,
"site": 4,
"location": 12,
"create_devices": true,
"device_name_pattern": "{rack}-{name}",
"dry_run": true
}'
```
Antwort:
```json
{
"dry_run": true,
"racks": ["DC1-R01", "…", "DC1-R10"],
"devices_per_rack": 7,
"total_devices": 70,
"warnings": ["Blindplatte 3 has no role. NetBox requires one, so it will not be created."]
}
```
`dry_run` auf `false` setzen, um es tatsächlich anzulegen. Das Ausrollen läuft in **einer**
Transaktion: schlägt ein Rack oder ein Gerät fehl, wird gar nichts angelegt.
## Was beim Ausrollen nicht mitkommt
Ein Konzept beschreibt Bauraum, keine Betriebsdaten. Bewusst **nicht** erzeugt werden:
Kabel, Interfaces jenseits der Device-Type-Templates, IP-Adressen, Seriennummern-Zwang,
Asset-Tags. Geplante Geräte ohne Rolle, ohne Gerätetyp oder ohne Position werden
übersprungen — welche das sind, zeigt die Bestätigungsseite vor dem Ausrollen an.
## Berechtigungen
Es gelten die normalen NetBox-Objektberechtigungen:
`netbox_rack_concept.view_rackconcept`, `add_`, `change_`, `delete_` — analog für
`conceptdevice`. Für das Ausrollen wird zusätzlich `dcim.add_rack` geprüft.
## Lizenz
MIT