What is FC?
FC (Framework Coordinator), is an open source coordinator service among different embeded frameworks. It’s built using the same principles as Mesos, provides different frameworks (e.g., LAVA, Labgrid) with API’s for resource management and scheduling across entire board farms.
Background
There are many different systems in embedded test community, see this. They are good at different scenarios, e.g.
Test automation:
LAVA, Fuego, autotest, avocado, TI VATF, U-Boot test tool, CI-RT R4D, Baylibe Lab in a Box……
Development automation:
Labgrid……
Let’s take a look at why FC is useful by going back in time.
Traditional deployment era: Early on, as nearly all above systems require dedicated control of the board resources, organizations have to afford multiple series of hardware to meet the requirements of different frameworks, which leads to resource waste when leverage different systems.
FC deployment era: As a solution, FC was introduced. It allows different frameworks could share same series of hardware, move resources between systems seamlessly. Different systems will continue work without aware existence of other systems. So, FC could be treat as “scheduler’s scheduler”. The initial idea comes from Jan’s proposal to move boards between LAVA and labgrid on ATS2019, we realized the FC based on that thought (Thanks community to inspire the idea).
Compared to other resource management system, it has low invasion to frameworks. This means: unlike mesos which you should write your mesos scheduler for your framework & inject it into your framework code, FC won’t change your framework code, it tries to adapt to your framework. But still, your framework need next two features:
Your framework needs to have a job queue which FC could monitor.
Your framework needs to have ways to let FC control resource’s availability, temporary connect/disconnect from your framework.
Supported frameworks
FC is designed as a plugin system to support different frameworks, it currently supports:
LAVA: use it for test automation
Labgrid: use it for development automation
But, it not limits to above two, you could write your own plugins to support other framework.
For more detail, move your steps to FC home page.
1 maintainer
Metadata
1 maintainer
Release files for fc-server 0.9.8
For a detailed explanation of source distributions (sdists) and built distributions (wheels), please see the package formats documentation.
Source distribution (sdist)
| File | Size | Uploaded | Provenance | |
|---|---|---|---|---|
| fc_server-0.9.8.tar.gz | 215.7 kB | Without provenance | Details |
Release files / fc_server-0.9.8.tar.gz
| Download URL | fc_server-0.9.8.tar.gz |
|---|---|
| Size | 215.7 kB |
| Tags | Source |
|
SHA-256 checksum How to use checksums |
c18a56231d282abdb0fce4792591081a5a494a7d058a873bfd18d16e4d8f9da3
|
|
BLAKE2b-256 checksum How to use checksums |
95cfe77b425aa23a1b5a1b182d19d5829b44418a32695369e02222484135971a
|
| Upload date | |
|
Uploaded using Trusted Publishing? What is trusted publishing? |
No |
| Uploaded via |
twine/6.2.0 CPython/3.9.2
|
Security for fc-server 0.9.8
Provenance
Provenance describes where a file came from. On PyPI, provenance is shared via attestations, which provide a verifiable record of the build or publishing details. View details, limitations and caveats.
No provenance found
None of the files in this release were uploaded with provenance metadata.
A note on package security
PyPI is a repository for distributing packages, not a service for auditing them. While third-party security researchers and our staff do their best to detect and remove malicious packages, PyPI cannot guarantee the quality, security or suitability of any given package.
