[EXPERIMENTAL] Reduce SMD microservice scope to focus on core functionality and API

[alexlovelltroy]

The goal of this task is to understand how much time and effort is required to simplify a microservice down to only what’s needed and to have a microservice that is focused and easier to manage/maintain.

The monolithic design of SMD makes it difficult to modify the code to add or remove features, which also makes slimming down SMD functionality a challenge. SMD contains multiple features that can be decoupled and separated into other confined microservices. These features are listed in the SMD repository’s README file and need to be identified in the code.

Each feature to change should be evaluated to make sure that modification will not break a dependency whether internal or external to the microservice.

SMD is a part of CSM collection and is designed to be integrated with other CSM-based microservices. The coupling between the microservices means that making changes in one microservice may break how another one interacts with it.

Some of SMD features listed in README

• Inventory discovery of Mounter/River controller systems
• Tracks hardware state and other component data
• Creation of component groups and partitions
• Stores Redfish endpoint and component data via inventory discovery
• Learns, stores, and tracks detailed hardware inventory data

SMD API Endpoints of Interest

• Booting/Ochami Demo
  • Magellan
  • …/hsm/v2/Inventory/RedfishEndpoints
  • BSS
  • …/hsm/v2/Inventory/RedfishEndpoints
  • …/hsm/v2/Inventory/ComponentEndpoints
  • …/hsm/v2/State/Components
• Supercomputing Institute
  • SMD (authentication/authorization)
  • ../groups/*
  • ../partitions/*

[davidallendj]

Possibly related to PR #12

[synackd]

Closing this since it has been marked as done.