Discussion Ideas and Topics

This document contains a list of topics for discussion regarding OChami and its design going forward and other considerations in the future. It is only meant to spark discussions and it not meant to be permenant and is subject to change. Some topics may eventually be removed or converted to its own RFD if needed.

Naming Nodes Within And Across Microservices #10
- See related RFD 10 in Roadmap.
- Could the mandatory xname check be made optional? That way, if the xname string is valid, it will follow the CSM path for handling them. Otherwise, it would probably make more sense to have a generalized naming convention.
Modularity between microservices
- For example, instead of sending Magellan's output to SMD, could we instead send it to BSS or any other microservice completely and have it do something with it instead? The data structures representing a Redfish endpoint and inventory could be standardized in a JSON format between microservices, and each microservice can handle data structure input in a way that is relevant to the functionality of the microservice (or do nothing at all).
Compatibility with existing CSM architecture
- There is interest within the CSM/HPC community to maintain some compatibility going forward with the current CSM software. Should there be an extended discussion about the specifics on what should be kept or how to proceed with implementing backwards compatible?
- Maintaining compatible creates an interesting dynamic between intentionally moving away from CSM distributed monolithic design of microserves keeping old
Changing how discovery/inventory tracking works
- SMD has a rediscovery feature that polls for inventory updates. Whenever a new Redfish endpoint is added, SMD will try to (re)discover new hardware and adds the hardware to the inventory tracking system (?)
- With a separate Redfish event listener microservice, discovery can be event driven and initiated whenever the event listener detects a change in inventory hardware instead of polling.
API contracts and boundaries #39
- The input and output API of each microservice should be clearly defined. Ideally, each microservice should be able to operate in isolation without a dependency on another microservice.
Rewrite VS Refactor
- Each microservice will likely require more or less time and effort to do either a rewrite or to refactor. Therefore, it may be beneficial to identify which microservices API would favor each.

Diagram showing microservices relationship (WIP)

The diagram is organized around functionality of microservices which serves as the main focus. It also shows the CSM microservice that is capable of providing functionality as well as an open-source alternative.
The diagrams shows the inputs for the microservice to work and outputs of each function

%%{
    init: {
        'theme':'forest',
        'title':'Node',
        'themeVariables': {
            'lineColor': 'green',
            'secondaryColor': '#006100',
            'tertiaryColor': '#fff',
            'fontSize': '26px',
            'background': '#000000',
            'nodeTextColor': '#ff0000'
        }
    }
}%%
flowchart LR;
    subgraph smd[SMD]
        discovery
        sm
        inventory
        rfe
    end

    subgraph bss[BSS]
        boot
    end
    subgraph discovery[Discovery of BMC nodes]
        direction LR
        discovery_alt[Magellan]
    end

    subgraph sm[State Management]
        direction LR
        sm_alt[N/A]
    end

    subgraph inventory[Inventory Tracking]
        direction LR
        inventory_alt[N/A]
    end

    subgraph rfe[Redfish Event Listener]
        direction LR
        rfe_alt[N/A]
    end

    subgraph boot[Boot Parameters and Config]
        direction LR
        bss_alt[N/A]
    end

    discovery -- output --> sm
    smd -- Components --> bss
    inventory --- sm
    rfe --- sm

OpenCHAMI / roadmap

[RFD] Architectural Choices #12

Discussion Ideas and Topics

Diagram showing microservices relationship (WIP)