Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Open
m8pple opened this issue Jul 14, 2022 · 1 comment

Comments

@m8pple
Copy link
Contributor

m8pple commented Jul 14, 2022

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
Copy link
Contributor

I like this idea.

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants