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

Abort wrapper improvements #25

Open
mthuurne opened this issue Sep 5, 2019 · 0 comments
Open

Abort wrapper improvements #25

mthuurne opened this issue Sep 5, 2019 · 0 comments
Labels
enhancement New feature or request

Comments

@mthuurne
Copy link
Member

mthuurne commented Sep 5, 2019

An abort wrapper is a dedicated optional wrapper that can be run if its associated execution run is to be aborted.

There are two known scenarios in which an abort wrapper is useful:

  • when killing an execution run's processes isn't enough to return the system to a neutral state in which the system can be idle or used for the next task run
  • for duration tests that are either aborted by the task timeout feature of the Control Center or are aborted by the user (for example when the test equipment is needed for other tests)

The abort wrapper currently logs to wrapper_log.txt, the same log as used for the execution run. This is confusing, since it's not easy to see which log entries originate from which wrapper. Now that we have flexible log tabs, it would be better to have a separate log for the abort wrapper. However, implementing this is not trivial, since the abort wrapper's thread skips a lot of the code that other wrapper types use. Among the skipped code is the code that creates log files and uploads artifacts.

It would be useful if, when an abort wrapper is run, to have the abort wrapper produce a results file instead of the execution wrapper. Or at least to have the option of doing that. Implementing this runs into the same issues as separating the log file, being that an abort wrapper skips several steps that are essential to make this work, such as uploading artifacts and making the TaskDone call to the CC.

There are also some questions related to how abort wrappers interact with other wrappers that don't have firm anwsers yet (and tentative answers might not agree with the implementation):

  • should an abort wrapper be run inside a process wrapper? if future process wrappers start containers or VMs, an abort wrapper that is isolated in that way cannot perform many types of cleanup
  • if the requirements for aborting duration tests and cleaning up are significantly different, should there be two separate types of wrappers for them? if so, it might be a good idea to run the cleanup wrapper after every execution, whether it was aborted or exited normally
@mthuurne mthuurne added the enhancement New feature or request label Sep 5, 2019
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
None yet
Development

No branches or pull requests

1 participant