Testing Container Orchestration for Parallel BMC Image Testing
Find Innovative SolutionsGenerate Solutions
Solution Overview
Problem
Existing BMC image testing is inefficient and prone to erratic environment-induced failures, requiring lengthy test cycles and hindering development processes.
Innovation Solution
A method and cluster for orchestration that assigns multiple testing containers to pods across nodes, allowing parallel execution and rerunning failed tests on different pods to enhance efficiency and reproducibility.
Engineering Contradictions & Design Principles
Engineering Contradiction Analysis
1Productivity
If a single hardware entity is used for BMC image testing, then testing simplicity is maintained, but testing throughput is slow and test cycles take several days
Solution Approach 1:
The testing system is segmented into multiple independent testing containers, each capable of executing tests in parallel. This segmentation enables concurrent test execution across multiple hardware entities, dramatically increasing testing throughput while maintaining individual container simplicity
Solution Approach 2:
The testing container is designed as a universal platform that can execute on various hardware entities (different nodes, pods, and containers). This multi-functionality allows the same testing framework to operate across diverse environments, scaling from single to multiple hardware entities without redesign
2Reliability
If a single hardware entity is used for testing, then hardware consistency is maintained, but erratic environment issues cause failures that are difficult to duplicate
Solution Approach 1:
The system creates testing environments with deliberately different local qualities by distributing tests across multiple hardware entities with varying characteristics (temperature, humidity, power supply voltage, fan speed). This allows identification of whether failures are environment-specific or test-specific by comparing results across different local conditions
Solution Approach 2:
The testing container is copied and deployed to multiple hardware entities, creating identical test executions in different environments. This copying approach enables replication of test conditions across diverse hardware, facilitating failure duplication and verification while isolating environment-specific issues
3Productivity
If thousands of test passes are run sequentially on a single hardware entity, then comprehensive testing is achieved, but test cycles take several days to complete
Solution Approach 1:
The test suite is segmented into multiple testing containers that execute in parallel across different hardware entities. This segmentation transforms a sequential single-threaded testing process into a parallel multi-threaded system, reducing test cycle duration from several days to hours while maintaining comprehensive test coverage
Solution Approach 2:
The system adds a spatial dimension to test execution by distributing testing across multiple hardware entities simultaneously. Instead of executing tests in a single time dimension (sequentially), the system utilizes the spatial dimension (multiple concurrent execution environments) to accelerate test completion while maintaining thoroughness
Data Source
AI summary
A method and a cluster for testing orchestration are provided. The method comprises: assigning a plurality of testing containers each including a specification file to provide testing details and stored in a repository of a control plane, by a testing controller of the control plane, to a plurality of pods each including at least one storage volume configured to store the assigned testing containers; dispatching the plurality of pods, by a scheduler of the control plane through an application program interface (API) server of the control plane, to at least one node; running the plurality of pods, by the at least one node, to execute the assigned testing containers, until all the assigned testing containers stored in the at least one storage volume have been finished; reporting execution results of the finished testing containers to the API server; and if any execution result indicates a failure, assigning the corresponding testing container again to a different pod.


