search

POETSII / Orchestrator

The Orchestrator is the configuration and run-time management system for POETS platforms.
1 stars 1 forks source link

Printed location of microlog usually has a relative offset. Make it absolute? #327

Open m8pple opened 2 years ago

m8pple commented 2 years ago

This is a more a quality of life thing, but something that I find occurs when using the orchestrator in it's intended interactive mode (well, and also in batch mode), is that the printed location of the microlog in the output stream of the orchestrator has an offset from the directory that the user (or operator) is currently in.

For example, if I am in the orchestrator directory:

dt10@byron:~/Orchestrator$ Tests/ReferenceXML/run_app_standard_outputs.exp /home/dt10/graph_schema/apps/tests/supervisors/test_supervisor_100dev_to_sup_bcast_overload.xml
...
POETS> 03:26:50.02:  20(I) The microlog for the command 'load /engine = "../Config/POETSHardwareOneBox.ocfg"' will be written to '../Output/Microlog/Microlog_2022_07_14T03_26_50p0.plog'.
....

But ../Output from the current directory doesn't exist.

I don't think it matters which current directory the orchestrator is started from, though I could be wrong. For the above example, if I change to my home directory then the same thing still happens, with the microlog prefix as '../Output/Microlog`, regardless of user location.

I can see the potential benefit of locating the logs relative to the binary installation, sort of. However, having the relative path that is not relative to where the "operator" is makes things more complicated, as the user needs to edit the path before opening it in a view or editor to find out what the errors were.

It might be more user-friendly to just print the absolute path of the microlog, so that it can be passed to less or cat, and/or to allow ctrl-click to open in other editors.

Alternatively, if relative paths are preferred as they are shorter, printing out the relative path compared to the user's cwd would make things better for the operator, as then they would see paths relative to where they are, rather than relative to where the orchestrator happens to be installed.

Another approach would be to put the logs relative to the input xml, but this seems full of unintended consequences.

I realise this can be controlled by the user through (greps documentation) path /ulog:, but it requires the user to work out how to set that and to know that it exists.

Given the output of the orchestrator is quite verbose, printing absolute paths would not add much, but would make it much easier to look at micrologs.

mvousden commented 2 years ago

I like this idea.

For reference, ../Output is relative to bin/, which is where root, logserver etc. are executed from. Could be better.