Skip to content

Latest commit

 

History

History
120 lines (66 loc) · 6.29 KB

File metadata and controls

120 lines (66 loc) · 6.29 KB
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
Loading

CodeBoardingDemoContact

Details

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.

FirmwareUpdate

Facade/orchestrator that parses module parameters, builds the firmware‑update payload, and drives the update workflow.

Related Classes/Methods:

RestOMEVV

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:

RestAPI

Base class that handles authentication (basic or session token), builds URLs, validates input and provides low‑level request helpers.

Related Classes/Methods:

OMEVVFirmwareUpdate

Utility that implements the concrete “firmware upload / job creation” API calls used by the wrapper.

Related Classes/Methods:

OMEVVInfo

Utility that queries OME‑VV for host‑ID resolution, compliance status and other read‑only data needed before a job.

Related Classes/Methods:

OMEVVBaselineProfile

Utility that creates baseline‑profile objects that the firmware job can reference (e.g., for scheduled updates).

Related Classes/Methods:

Dynamic inventory plug‑in

Plug‑in that discovers OME‑VV‑managed hosts for playbooks by calling the generic RestOME client.

Related Classes/Methods:

Test harness (unit)

Unit‑test suite that executes the FirmwareUpdate façade in isolation, mocking the REST client.

Related Classes/Methods:

  • tests.unit.modules.test_omevv_firmware

Test harness (integration)

Integration‑test suite that runs the full end‑to‑end flow against a real (or containerised) OME‑VV instance.

Related Classes/Methods:

Unclassified

Component for all unclassified files and utility functions (Utility functions/External Libraries/Dependencies)

Related Classes/Methods: None