342690142f
Currently DC orchestration divides the subclouds in stages and the stage size is defined by the max_parallel_subclouds parameter or by the size set for the group. Once a stage start being orchestrated, it will wait for all subclouds of that stage to finish before starting the next stage, causing the orchestrator to wait for slower subclouds. The change is to remove the division by stage and keep adding a new subcloud as soon as one finishes its orchestration in order to improve the orchestrator speed. Test Plan: PASS: Create and apply a strategy with a specific subcloud and verify that the orchestration finishes successfully. PASS: Create and apply a strategy with a group of subclouds and verify that the orchestrator uses the max_parallel_subclouds of that group. PASS: Create and apply a strategy with max_parallel_subclouds parameter and verify that the orchestrator uses that parameter. PASS: Create and apply a strategy with stop_on_failure parameter and verify that the orchestrator doesn't add any subclouds after the failure is identified. PASS: Create and apply a kubernetes strategy and verify that the orchestration finishes successfully. PASS: Create and apply a rootca strategy and verify that the orchestration finishes successfully. PASS: Create and apply a firmware strategy and verify that the orchestration finishes successfully. PASS: Create and apply a upgrade strategy and verify that the orchestration finishes successfully. PASS: Create and apply a patch with 100 subclouds in parallel strategy and verify that the orchestration finishes successfully. PASS: Create and apply a strategy with a group that has more subclouds than the max_parallel_subclouds value and verify that once a subcloud has been processed, another subcloud from "unprocessed pool" takes its place. PASS: Create and apply a strategy without specifying --max_parallel_subclouds value having subclouds from different groups that are elegible and verify that the orchestration finishes successfully. Story: 2010798 Task: 48417 Signed-off-by: Christopher Souza <Christopher.DeOliveiraSouza@windriver.com> Change-Id: Ie8e8a62ce1314706fb359c1349ab09bc853d0e4a |
||
|---|---|---|
| .. | ||
| centos | ||
| dccommon | ||
| dcdbsync | ||
| dcmanager | ||
| dcorch | ||
| debian | ||
| etc | ||
| files | ||
| ocf | ||
| .coveragerc | ||
| .coveragerc_xml | ||
| .testr.conf | ||
| LICENSE | ||
| MANIFEST.in | ||
| README.rst | ||
| __init__.py | ||
| babel.cfg | ||
| pylint.rc | ||
| requirements.txt | ||
| setup.cfg | ||
| setup.py | ||
| test-requirements-debian.txt | ||
| test-requirements.txt | ||
| tox.ini | ||
README.rst
DistributedCloud
Wind River's Distributed Cloud system supports an edge computing solution by providing central management and orchestration for a geographically distributed network of Titanium Cloud systems.