graph LR
FirmwareUpdate["FirmwareUpdate"]
RestOMEVV["RestOMEVV"]
RestAPI["RestAPI"]
OMEVVFirmwareUpdate["OMEVVFirmwareUpdate"]
OMEVVInfo["OMEVVInfo"]
OMEVVBaselineProfile["OMEVVBaselineProfile"]
Dynamic_inventory_plug_in["Dynamic inventory plug‑in"]
Test_harness_unit_["Test harness (unit)"]
Test_harness_integration_["Test harness (integration)"]
Unclassified["Unclassified"]
FirmwareUpdate -- "Composition (uses)" --> RestOMEVV
FirmwareUpdate -- "Composition (delegates)" --> OMEVVInfo
FirmwareUpdate -- "Composition (delegates)" --> OMEVVBaselineProfile
RestOMEVV -- "Inheritance" --> RestAPI
RestAPI -- "Aggregation (creates)" --> OpenURLResponse
Dynamic_inventory_plug_in -- "Composition" --> RestOME
Test_harness_unit_ -- "Dependency (imports)" --> FirmwareUpdate
Test_harness_integration_ -- "Dependency (imports)" --> RestOMEVV
Test_harness_integration_ -- "Dependency (imports)" --> OMEVVInfo
Test_harness_integration_ -- "Dependency (imports)" --> OMEVVFirmwareUpdate
OME‑VV Firmware Management is a self‑contained sub‑system that enables Ansible users to upload firmware, create baseline profiles and schedule update jobs for Dell OpenManage Enterprise Virtual‑Volume (OME‑VV) clusters. The public entry‑point is the omevv_firmware module, which builds an OMEVVAnsibleModule argument spec and instantiates a RestOMEVV client. RestOMEVV inherits the generic RestAPI class, thereby re‑using the collection’s proven session‑and‑authentication handling without any additional composition. The FirmwareUpdate façade orchestrates the workflow: it resolves target host IDs via OMEVVInfo, prepares baseline objects with OMEVVBaselineProfile, and finally submits the firmware payload through OMEVVFirmwareUpdate. All HTTP interactions flow through the OME‑VV gateway, with the optional dynamic inventory plug‑in (ome_inventory) exposing OME‑VV‑managed hosts to Ansible playbooks. Unit and integration test suites validate the end‑to‑end behaviour, ensuring that the subsystem remains isolated from unrelated utilities such as logging handlers or documentation fragments.
Facade/orchestrator that parses module parameters, builds the firmware‑update payload, and drives the update workflow.
Related Classes/Methods:
REST client that sends OME‑VV‑specific HTTP calls (adds the x_omivv‑api‑vcenter‑identifier header) and inherits generic session handling from RestAPI.
Related Classes/Methods:
Base class that handles authentication (basic or session token), builds URLs, validates input and provides low‑level request helpers.
Related Classes/Methods:
Utility that implements the concrete “firmware upload / job creation” API calls used by the wrapper.
Related Classes/Methods:
Utility that queries OME‑VV for host‑ID resolution, compliance status and other read‑only data needed before a job.
Related Classes/Methods:
Utility that creates baseline‑profile objects that the firmware job can reference (e.g., for scheduled updates).
Related Classes/Methods:
Plug‑in that discovers OME‑VV‑managed hosts for playbooks by calling the generic RestOME client.
Related Classes/Methods:
Unit‑test suite that executes the FirmwareUpdate façade in isolation, mocking the REST client.
Related Classes/Methods:
tests.unit.modules.test_omevv_firmware
Integration‑test suite that runs the full end‑to‑end flow against a real (or containerised) OME‑VV instance.
Related Classes/Methods:
Component for all unclassified files and utility functions (Utility functions/External Libraries/Dependencies)
Related Classes/Methods: None