Add hardware meta data

[MichaelRoeder]

Description

As a developer of a system / benchmark, I would like to know the hardware on which the my system / benchmark is executed to decide how many instances I can deploy at runtime.

Solution

The platform should provide detailed information about the nodes for the system / benchmark. This can be done using an RDF model that is submitted as environmental variable.

In a first step, submitting the number of nodes, e.g., as an own environmental variable, would be sufficient. (Has high priority)

Tasks

• use Docker to automatically gain information about the hardware the platform is running on
• divide the hardware information into two categories: an RDF model for the system nodes and an RDF model for benchmark nodes
• give the information to every newly created container based on its type

[MichaelRoeder]

blocked by #100

[denkv]

Currently we have the following related information available from prometheus:

• number of CPU cores
• CPU frequency
• total memory amount
• total swap amount
• uname output (domain, arch, OS with version and release)

[denkv]

Currently we have the following in our example:

<http://example.org/ExampleHardware> a hobbit:Hardware ;
hobbit:hasModel "...." ;
  hobbit:hasProcessors "...." ;
  hobbit:hasMemory "...." ;
  hobbit:hasDisks "..." ;
  hobbit:hasNetworkAdapters "...." ;
  hobbit:hasOS "Linux .." ;
  hobbit:hasFileSystem "..." ;
  hobbit:hasCPUTypeCount "1"^^xsd:int ;
  hobbit:hasRAM "..." .

Can we improve that to clarify more what is expected? For example, for memory: amount, manufacturer, exact model?

[MichaelRoeder]

That is up to us. We can also reuse the MEX vocabulary which already defines some of these things (see hobbit-project/ontology#4).

[MichaelRoeder]

@denkv I think you list of available information is already sufficient. We just have to

• Implement to collect this information,
• Check the MEX vocabulary (or other related vocabularies) for properties or resources which can be reused and
• Implement the creation of the hardware model
• ... and add it to the result model of an experiment (should be part of the platform controller)

[denkv]

• Display hardware information in UI.