1. Refactoring the LAVA dispatcherNeil Williams & Tyler Baker, LCU14LCU14 BURLINGAME

2. Agenda - Refactoring the LAVA dispatcher Old Design Why change? Flaws New design Requirements Feedback Discussion Use cases Q/A 3. Why refactor? Current design was grown organically Features have been bolted on Layers of hacks Seven different ways to run a shell command Lots of code duplication Testability Much of the code does not even have a unit test Difficult to test without hardware Speed Due to the size of the project its slow compared to other boot strapping projects Reliability Failures are hard to diagnose 4. Flaws Test job failures are not reliably categorised Test writers have little assurance that a test failed as a result of a broken build of thetest or a bug in the result parser or test definition YAML Test jobs which do not run due to a test failure are not identifiable The dispatcher does not currently have a reliable way of returning the number of testruns defined in the result bundle, only the number which ran. Loopback support failures Timeout uncertainties Special case code in general case classes The base classes and structures in lava-dispatcher have not been able to maintain aclear separation between code which is only required for a specific device type or asmall group of device types from code which is used on all devices. 5. Flaws Text-only logs Sections are not identifiable in logs Timezone unaware logs The current logs are not storing any information regarding the current timezone of thedispatcher that does produce the logs. Its then difficult to know the real date of eachfate of each log line. 6. New Design Requirements Error identification All errors and failures are tracked as discrete types Cleanup Each action within a test job is entirely responsible for identifying, resolving andaccurately reporting every error and failure during the operation of that action. Retry Explicit support for retrying specific actions. Diagnostics The action can invoke handler code to output debug information specific to that error toassist in determining the cause of the error. Pipeline Actions will be structured within a pipeline and actions can contain internal pipelineswith more actions. 7. New Design Requirements Idempontency All errors and failures are tracked as discrete types Simulation The pipeline can be asked to output a full simulation of the entire test job including allactions, all commands and all parameters. Speed More flexible deployments and removal of reliance on SD means that tests can befaster to start up and can use faster media like SATA. Security Only particular elements of the dispatcher code will run as root More requirements listed in the white paper https://docs.google.com/a/linaro.org/document/d/17wjThA69fteT85q0D_cmzyGqQjaaH6OCKtN3qXGkvWw/edit?pli=1# 8. New Design Requirements Feedback Are we missing requirements? 9. Discussion Use Cases What use cases are required to be support? 10. Questions? 11. More about Linaro Connect: connect.linaro.orgLinaro members: www.linaro.org/membersMore about Linaro: www.linaro.org/about/