Suggestion Description
This issues is made as a follow up to a discussion with @sbates130272.
Motivation
We need CI in hipObject. Finding real RNIC hardware is challenging. We want to exercise the separation between client and server object storage programs.
Technical Details
Stephen suggest that I try to experiment with creating a CI environment that consists of four containers:
- two containers running QEMU with different VMs (one running an object storage server, one running hipObject client code)
- two containers running QEMU with ernic exposing a different socket
Then use some form of inter-container communication like Docker's IPC method, or by using sockets.
Stephen has a stebates-ci-images repo with some of these images in development already.
At this point creating an environment like this will be experimental. Making this environment configurable for a CI matrix that may want to modify many elements, and providing a foundation for a configurable, observable, and reliable CI system in the future will be an extended effort that builds off of this. I'd love to invite any discussion about our CI early, so that anything I add doesn't become a pain in the future!
Scoping what needs to be made configurable is a related, or perhaps part of this issue.
e.g., what if we wanted to test different storage server backends in the future? different ROCm versions, different NIC drivers, different client/server distro configurations, or compilers?
Operating System
No response
GPU
No response
ROCm Component
No response
Suggestion Description
This issues is made as a follow up to a discussion with @sbates130272.
Motivation
We need CI in hipObject. Finding real RNIC hardware is challenging. We want to exercise the separation between client and server object storage programs.
Technical Details
Stephen suggest that I try to experiment with creating a CI environment that consists of four containers:
Then use some form of inter-container communication like Docker's IPC method, or by using sockets.
Stephen has a stebates-ci-images repo with some of these images in development already.
At this point creating an environment like this will be experimental. Making this environment configurable for a CI matrix that may want to modify many elements, and providing a foundation for a configurable, observable, and reliable CI system in the future will be an extended effort that builds off of this. I'd love to invite any discussion about our CI early, so that anything I add doesn't become a pain in the future!
Scoping what needs to be made configurable is a related, or perhaps part of this issue.
e.g., what if we wanted to test different storage server backends in the future? different ROCm versions, different NIC drivers, different client/server distro configurations, or compilers?
Operating System
No response
GPU
No response
ROCm Component
No response