MichaelRoeder
commented
3 years ago Common example of a situation in which this can help a lot: A user defines a new system, creates a system.ttl file and pushes the image of the system container. Since he has different versions of his system, he tags it with :1.0.0. When used in an experiment, the platform tries to pull the image, but since the user has not defined a version in the system.ttl file, :latest is added by default. This leads to an error since such an image does not exist.
Here, a better error message would help a lot in identifying the problem.
User story
As a user of the HOBBIT platform, it is crucial for me to understand the reasons that lead to failing experiments. Although I can download the logs of benchmark and system I still have to contact the HOBBIT support team to lookup what went wrong very often.
Examples:
Solution
The platform has a lot of information about why an experiment fails. It just has to bring this information to the UI. There are two ways:
Solution 1: more error codes
It would be possible to extent the existing list of errors with additional, fine-grained error codes that cover more situations.
Advantage: the user directly sees the explanation of the error.
Disadvantage: the error codes have to be maintained. Causes of errors may appear and disappear over time.
Solution 2: download platform logs
Offer a download of the platform logs of the time in which the experiment has been executed. There are again different ways to implement it.
Advantage: the user gets all information we have about their experiment.
Disadvantage: the selection of the log messages must be very strict to ensure that no unnecessary or private data can be downloaded. The GUI message have to be excluded. The same holds for messages that may contain user names. A selection of platform controller messages within the time of the experiment might be reasonable.