Refactor internals and expose websocket interface

[cjh1]

Checklist

• My code follows the style guidelines of this project
• I have added/updated comments where needed
• I have added tests that prove my fix is effective or my feature works
• I have run make test (or equivalent) locally and all tests pass
• DCO Sign-off: All commits are signed off (git commit -s) with my real name and email
• REUSE Compliance:
  • Each new/modified source file has SPDX copyright and license headers
  • Any non-commentable files include a <filename>.license sidecar
  • All referenced licenses are present in the LICENSES/ directory

Description

This refactor restructures the existing conman based
service into a more testable and maintainable form.
It builds on changes in SMD to provide console configuration
in a vendor agnostic way. A new websocket interface is
established to allow access to the console without using
conman directly. Having this interface could potentially
allow us to swap out conman for some other approach in
the future. These changes at a high level include:

• Splitting functionality into well defined packages
  each with their own configuration. Providing better
  separation of concerns and testability.
• Restructure cmd/remote-console into config/service/command
  layers that use the newly established packages.
• Added some unit tests for the newly established packages.
• Added a websocket endpoint to allow interactive and tail
  mode console sessions.
• Added a comprehensive integration test suite using
  testcontainers. This uses an IPMI simulator and a set of
  SSH containers to act as mock consoles.
• Remove dependency on HPE node type to determine how to
  connect to consoles. This is now done using information
  in the redfish endpoints provided by SMD.
  Fixes #(issue)

Type of Change

• Bug fix
• New feature
• Breaking change
• Documentation update

---

For more info, see Contributing Guidelines.

[cjh1]

Given the number of changes here are few pointers for reviewers

The new package structure is as follows:

• internal/conman/ - manages conman configuration and interaction.
• internal/console/ - this is where the new websocket endpoint are implemented allowing interaction with the console.
• internal/creds/ - manages credentials for connecting to the console, monitors for changes and triggers conman updates.
• internal/logs/ - manages the logrotate configuration and interaction with logrotate.
• internal/nodes/ - manages the integration with SMD to get the console configuration.

Most of the code in these package is derived from the original with the exception of internal/console.

Outline of a review order

• Start by looking in cmd/remote-console/
  • config.go - the configuration options are defined ( rather than having inline configuration hardcoded throughout the code ). This is also how the command line options are defined.
  • service.go - this where the functions that are run as goroutine are defined to run the various monitoring loops. They in turn use the new packages to perform the specific functionality. I would use these as jumping off points to trace the logic down into the various internal/ packages.
• Secondly I would look at internal/console/ which defines the websocket endpoints for interacting with the consoles, router.go is a good starting point.
• Lastly I would look at the integration tests ( test/ ) They provide an idea of how the components work together and probably the best way to try things out.

The redfish and IPMI emulators can be largely ignore:

• test/redfish-emulator-mocks/
• ipmi_sim

[rainest]

Chris and I conducted a review over a call and that led to the comment/changes above ^

this is a not-review alongside a proper github request for review from me that acknowledges that happened; Chris beat me to writing the acknowledgement of out-of-band review happened with the response to it

also circulating this in another out-of-band channel for some other OpenCHAMI-interested staff at NERSC who I know have interest in remote-console, but are even less active on GitHub than I often am. ALSO here but I expect the GitHub notifications may get lost in email purgatory:

Tagging @jstile-lbl, who's worked with the older console service code previously and is likely interested to test this, now that it should address some of the shortcomings he encountered.

@dfox-lbl also maybe.

[rainest]

integration_tests failed with a possible flake condition. Not sure exactly what led https://github.com/OpenCHAMI/remote-console/actions/runs/21964590784/job/63450933946 to time out, but looks like hung test containers that refuse to exit?

Re-running since I don't think newer changes since earlier had enough impact on code/test run strategy since the successful one in https://github.com/OpenCHAMI/remote-console/actions/runs/21960205519/job/63435294660

Wanna try and confirm if that's a flake or consistent timeout. Both are things we'd want to address, but are things that we'd want to address different ways, and I lack enough familiarity with the test internals yet to guess at which is more likely, so moar datas 🤖 🔄 🔴 🟢 who knows yet.

[cjh1]

integration_tests failed with a possible flake condition. Not sure exactly what led https://github.com/OpenCHAMI/remote-console/actions/runs/21964590784/job/63450933946 to time out, but looks like hung test containers that refuse to exit?

Re-running since I don't think newer changes since earlier had enough impact on code/test run strategy since the successful one in https://github.com/OpenCHAMI/remote-console/actions/runs/21960205519/job/63435294660

Wanna try and confirm if that's a flake or consistent timeout. Both are things we'd want to address, but are things that we'd want to address different ways, and I lack enough familiarity with the test internals yet to guess at which is more likely, so moar datas 🤖 🔄 🔴 🟢 who knows yet.

Very strange, was working fine! Will take a look.

[cjh1]

OK, fixed, adding a license header to a test script broke things! Moved the shebang line back up to the top.