Skip to Content
ReferenceReferenz

Referenz

Technische Referenz für die öffentliche OpenFactory-Plattform. Konsole und API-Antworten sind maßgeblich für den Zustand eines konkreten Builds.

ReferenzBeschreibung
MCP-IntegrationMCP-Client an OpenFactory anbinden
Rezept-SchemaKanonische BuildRecipe-Felder
Assertion-TypenAusführbare VM-Test-Assertions
ServiceNow-IntegrationOptionale, standardmäßig deaktivierte ITSM-Hooks

Build-Records haben getrennte Ergebnisse

Leiten Sie Verifikation nicht allein aus dem Image-Build-Status ab. Ein Build-Record verfolgt mindestens drei getrennte Aspekte:

AspektTypische WerteBedeutung
Image-Buildqueued, planning, configured, building, finalizing, completed/built, failedOb Image-Produktion ein terminales Ergebnis erreichte
Testsnot_run, running, passed, failed, error oder skippedOb der angehängte Verifikationslauf ausgeführt wurde und was er fand
Zertifizierungcertified, uncertified, repairing oder ein anderer expliziter Gate-ZustandOb das Artefakt den aktuellen Zertifizierungsvertrag erfüllte

Ein abgeschlossenes Image mit failed, errored, skipped oder fehlenden Tests ist kein zertifiziertes Image. Nutzen Sie alle drei Felder bei Automatisierung von Promotion- oder Download-Entscheidungen.

Build-Ausgaben

Ausgaben hängen vom Build-Target und davon ab, welche Stages abgeschlossen wurden. Ein Record kann ISO oder Disk-Image, normalisiertes Rezept, Build-Logs und Test-Nachweis liefern. Behandeln Sie ein Element als verfügbar nur, wenn die Build-Response Artefakt- Metadaten liefert und der Download-Endpoint erfolgreich ist.

Zone-2-Snapshots in der VM-Verwaltung erfassen das governed persistent overlay. Sie sind keine vollständigen libvirt Memory-and-Disk-Snapshots und keine Build-Artefakte.

Base Images

Wählbare Versionen wechseln mit Upstream-Quellen und OpenFactory-Adaptern. Nutzen Sie den aktuellen Base-Image-Picker der Konsole oder die validierte Rezept-Response, nicht eine kopierte Versionsliste, wenn Sie automatisieren. Siehe Base Images für Auswahl und Grenzen.

Support