Future Work - Enable asynchronous fault injection for shops managed by distinct agents.

[christianadriano]

Currently, mRubis forces all agents to operate within the same cycle of failure injection. This means that a new failure can only be injected to any shop after all existing failures had been fixed. While this is not a concern in a single agent architecture, with multi-agents this prevents the system from benefiting from agents that have higher failure fixing capabilities, i.e., can fix failures quicker. Because these high capability agents have to wait for the other agents to produce their fixes, the entire multi-agent system has to operate at the maximum speed of the slowest agent.

Note that an agent might be slower for many reasons, deployment hardware, number of shops being managed, or simply because the prediction models of an agent have low accuracy (produce wrong fixes).

Although low accuracy might be temporary because the shops of that agent suffered a perturbation (distribution shift), this slowdown will affect the entire system. Therefore, in the future, to demonstrate performance of MARL for the Self-healing scenario, this require will be fundamental.

[jocodeone]

To overcome this limitation we only have to make small changes. As the MultiAgentController is asking each agent to fix their shops although there might be no issues available (if this is the case, the shop will be skipped), we only have to change how the mrubisEnv is working. Currently, we only get new issues when all issues are solved. However, we could return new injected issues to the step method of our gym interface after one iteration. To wait at least one iteration is needed to detect that the change was successful and no issue is available anymore.

This future work scenario is therefore more an adaption of how the injection on the mrubis side works as the python side should be able to handle this without any changes.