Difference between revisions of "Board Farm REST API"

From eLinux.org
Jump to: navigation, search
(Stuff needing to be done)
(Presentations: add links for presentation and video)
 
(6 intermediate revisions by the same user not shown)
Line 7: Line 7:
 
"This project proposes standard APIs between automated tests and board farm management
 
"This project proposes standard APIs between automated tests and board farm management
 
software. The idea is to allow a test to query the farm about available bus connections,
 
software. The idea is to allow a test to query the farm about available bus connections,
attached hardware and monitors, and other test installation infrastructure. The test
+
attached hardware and measurement devices, and other test installation infrastructure. The test
 
can then allocate and use that hardware, in a lab-independent fashion. The proposal calls
 
can then allocate and use that hardware, in a lab-independent fashion. The proposal calls
 
for a dual REST/command-line API, with support for discovery, control and operation of
 
for a dual REST/command-line API, with support for discovery, control and operation of
Line 20: Line 20:
  
 
= Status =
 
= Status =
 +
== March 2021 ==
 +
As of March 2021, work has started on a power management test.  Also, labcontrol now supports
 +
many of the device management APIs (but it's web interface is quite weak at the moment).
 +
 +
* The power-measurement APIs (in prototype form) were added to the labcontrol server and client.
 +
** This includes the get-resources API, and capture apis (start, stop, get_data, and delete)
 +
** a test was run on a board in Tim's lab, using the API for the power-measurement as part of the test
 +
 +
* The serial port APIs (in prototype form) were added to the labcontrol server and client
 +
** this added the set-config API
 +
** a test was run on a board in Tim's lab, using the API for serial operation as part of the test
 +
 +
Currently, there are two separate implementations:
 +
* TimeSys Embedded Board Farm
 +
** The server side of the implementation is an extension to LAVA (using python and Django)
 +
** The client side is the reference implementation of 'ebf' which is found here:
 +
*** https://github.com/TimesysGit/board-farm-rest-api/blob/main/cli/ebf
 +
* Tim's "LabControl" - python server and client
 +
** Found here: https://github.com/tbird20d/labcontrol
 +
** Currently, it requires manual insertion of users and manipulation of json files on the server for managing boards and resources
 +
*** That is, the web interface for managing the server is quite weak.
 +
 +
== October 2020 ==
 
In October, 2020, Harish Bansal of TimeSys and Tim Bird of Sony gave a presentation
 
In October, 2020, Harish Bansal of TimeSys and Tim Bird of Sony gave a presentation
 
about the API at Embedded Linux Conference Europe, 2020.
 
about the API at Embedded Linux Conference Europe, 2020.
Line 31: Line 54:
  
 
= Presentations =
 
= Presentations =
* [upload presentation and put link here]
+
* "Board FARM APIs for Automated Testing of Embedded Linux" by Tim Bird, Sony & Harish Bansal, Timesys, at ELC Europe 2020 (October 2020)
** [add link to video here when it is available]
+
** [[Media:ELC-Board-Farm-API-Sony-Timesys-2020-10-27.pdf | PDF]]
 +
** [https://www.youtube.com/watch?v=ePYHuWyb0uk Video]
  
 
= Project activity =
 
= Project activity =
Line 43: Line 67:
 
* Tim to finish initial LabControl implementation
 
* Tim to finish initial LabControl implementation
  
== Stuff needing to be done ==
+
== Stuff that nedds to be done ==
 
* Need to finish Fuego integration
 
* Need to finish Fuego integration
 
** Add 'ebf' installation to Dockerfile (curl and jq already added)
 
** Add 'ebf' installation to Dockerfile (curl and jq already added)
Line 50: Line 74:
 
*** Maybe just add tar, upload, untar operations into the ttc copy_to_cmd?  (Fuego never downloads multiple files)
 
*** Maybe just add tar, upload, untar operations into the ttc copy_to_cmd?  (Fuego never downloads multiple files)
 
** Maybe move API integration into Fuego overlay layer
 
** Maybe move API integration into Fuego overlay layer
 +
* Finalize gpio API, to allow for asking the LAB for the other endpoint GPIO number
 
* Resolve bugs and issues with ebf
 
* Resolve bugs and issues with ebf
 
* Set up an issue tracker for the project? (maybe just use github's?)
 
* Set up an issue tracker for the project? (maybe just use github's?)
Line 56: Line 81:
 
** audio/video capture
 
** audio/video capture
 
** netperf server management
 
** netperf server management
 +
* Start righting tests that use the API
 +
* Decide on parts of TimeSys implementation to upstream to LAVA

Latest revision as of 13:40, 15 April 2021

Introduction

In Fall of 2020, TimeSys and Sony proposed a "board farm REST API" for managing boards in a lab.

From the project README:

"This project proposes standard APIs between automated tests and board farm management software. The idea is to allow a test to query the farm about available bus connections, attached hardware and measurement devices, and other test installation infrastructure. The test can then allocate and use that hardware, in a lab-independent fashion. The proposal calls for a dual REST/command-line API, with support for discovery, control and operation of hardware and network resources. It is hoped that establishing a standard in this area will allow for the creation of an ecosystem of shareable hardware tests and board farm software."

Resources

Here is some information about the project:

Status

March 2021

As of March 2021, work has started on a power management test. Also, labcontrol now supports many of the device management APIs (but it's web interface is quite weak at the moment).

  • The power-measurement APIs (in prototype form) were added to the labcontrol server and client.
    • This includes the get-resources API, and capture apis (start, stop, get_data, and delete)
    • a test was run on a board in Tim's lab, using the API for the power-measurement as part of the test
  • The serial port APIs (in prototype form) were added to the labcontrol server and client
    • this added the set-config API
    • a test was run on a board in Tim's lab, using the API for serial operation as part of the test

Currently, there are two separate implementations:

  • TimeSys Embedded Board Farm
  • Tim's "LabControl" - python server and client
    • Found here: https://github.com/tbird20d/labcontrol
    • Currently, it requires manual insertion of users and manipulation of json files on the server for managing boards and resources
      • That is, the web interface for managing the server is quite weak.

October 2020

In October, 2020, Harish Bansal of TimeSys and Tim Bird of Sony gave a presentation about the API at Embedded Linux Conference Europe, 2020.

At that time, the following had been accomplished and demonstrated:

  • the API had been added to TimeSys' board farm server (https://bfc.timesys.com)
  • a command line tool called 'ebf' had been developed
  • support for ebf was added to the Fuego test framework
  • a test was developed which used the API to executed a test in a lab-independent fashion
  • the test had been executed on a board in the TimeSys board farm from a LAVA system and a Fuego system

Presentations

  • "Board FARM APIs for Automated Testing of Embedded Linux" by Tim Bird, Sony & Harish Bansal, Timesys, at ELC Europe 2020 (October 2020)

Project activity

TimeSys and Sony have been having regular teleconferences to coordinate work on the API. If you would like to join those teleconferences, please let Harish or Tim know.

To Do list

  • Someone to create mailing list
  • Someone to finish openapi documents for spec directory in git repository
  • Tim to finish initial LabControl implementation

Stuff that nedds to be done

  • Need to finish Fuego integration
    • Add 'ebf' installation to Dockerfile (curl and jq already added)
    • Need to resolve issue with transferring multiple files with a single upload command
      • Fuego uses put -r
      • Maybe just add tar, upload, untar operations into the ttc copy_to_cmd? (Fuego never downloads multiple files)
    • Maybe move API integration into Fuego overlay layer
  • Finalize gpio API, to allow for asking the LAB for the other endpoint GPIO number
  • Resolve bugs and issues with ebf
  • Set up an issue tracker for the project? (maybe just use github's?)
  • Define APIs for more lab hardware
    • power measurement
    • audio/video capture
    • netperf server management
  • Start righting tests that use the API
  • Decide on parts of TimeSys implementation to upstream to LAVA