Pluggable bundle format extensions
Currently the LAVA dashboard bundle uses a very strict data schema. Any change to that schema needs to be carefully discussed, planned, coded and propagated through a number of systems. This makes the process long enough that we don't mess around with it often (which is a good thing in a certain way). It also prevents the format from becoming truly ubiquitous for data interchange among various peers that would otherwise have to map their problem space on to the current bundle format or convince us to extend the format for their specific needs.
To address this issue I'd like to propose bundle plugs, or smaller specifications that anyone can define and implement. The basic document would be composed of a few fixed elements and a collection of named plugs. Plug namespaces would prevent clashes and ensure forward compatibility. Current format would be transparently upgraded to a collection of common plugs.
I believe this would open a way to introduce domain-specific plugs without making the system a dumb shell for external attachments and custom data formats.
Blueprint information
- Status:
- Complete
- Approver:
- Paul Larson
- Priority:
- Low
- Drafter:
- Zygmunt Krynicki
- Direction:
- Needs approval
- Assignee:
- Zygmunt Krynicki
- Definition:
- Obsolete
- Series goal:
- None
- Implementation:
-
Unknown
- Milestone target:
- None
- Started by
- Completed by
- Michael Hudson-Doyle
Related branches
Related bugs
Sprints
Whiteboard
My initial ideas are as follows:
We retain the top-level "bundle" container.
We retain the collection of test runs but most of their attributes go away. The ones that would stay would help us to identify test runs (uuid).
We can convert the 'software context' into a plug
We can convert the 'hardware context' in to another plug
We can convert the 'software sources' into yet another plug
We can convert most of the current test result data into yet another plug.
* Plugs would be "mounted" under a well-known name that would also be the namespace for adding plugs as a third party.
* Plugs would have a well-known schema URL, consistent with the third draft of JSON schema spec ($ref). This would allow a validator to check any document for correctness without knowing about every possible plug format. See http://
* Plugs would have a version declaration that would be encoded in the schema URL
* Plugs should follow sensible version policy (x.y..z, TODO: pull the link from a sensbile/
Now for how rest of LAVA would work with this:
1) The dashboard would just parse specific plugs and deserialize them
2) I could see lava extensions declaring support for rendering a plug -> we could add vertical visualization tools that would "plug" right into the dashboard UI
3) Anything that produces older documents could keep producing them as they are now. Dashboard always accepts and will continue to accept old formats.
4) LAVA test will be upgraded to support new format. Test definitions will be unaffected by this
5) When running a test via lava-test a user may opt to use a specific plug, I could see this replace the current options not to probe software/hardware environment.
6) Certain plugs may be integrated directly into the test by an advanced parser. I could see this being used by tests that capture structured domain specific information, such as GPU performance traces, for example.
