Describe the bug
An age old problem we've seen are files & datasets from Galasa runs hanging around from old runs. It's not really been a big deal or priority, but the reason I've just spotted is probably obvious, and it should be fixed.
Looking at https://github.com/galasa-dev/galasa/blob/main/modules/managers/galasa-managers-parent/galasa-managers-zos-parent/dev.galasa.zosfile.zosmf.manager/src/main/java/dev/galasa/zosfile/zosmf/manager/internal/ZosmfZosFileHandlerImpl.java - a lot of our tests and managers come into this piece of code to create files and datasets.
It keeps an in-memory store of all the resources it creates, and cleans up on teardown.
However, if a test run aborts, the cleanup doesn't happen. Therefore there are orphaned files/datasets left on the machine.
Resource management solves this. A resource should probably be added to resource management at the point the file/dataset is actually "physically created" and only if the "shouldCleanup" switch is true.
The snag then is, when the resmon daemon picks up with resource because the test run is deemed stale, how does it delete it from the zOS machine?
I think this is something my team can work on and contribute back, however, I would immediately turn to the zOSmf code I put in place to kill orphaned CICS Regions, as it can delete resources also. Would this be the correct public solution for this though?
Steps to reproduce
- Run a test that creates loads of file/datasets
- kill the test halfway through
- observe the file/datasets still remain
Expected behavior
File/datasets from old runs should be deleted. We probably get around this, because a lot of our files/datasets are created within the test run dir/hlq and are indirectly deleted this way, but some aren't.
Additionally - some test run dirs/HLQ also don't get removed if tests are aborted, perhaps they should?
Describe the bug
An age old problem we've seen are files & datasets from Galasa runs hanging around from old runs. It's not really been a big deal or priority, but the reason I've just spotted is probably obvious, and it should be fixed.
Looking at https://github.com/galasa-dev/galasa/blob/main/modules/managers/galasa-managers-parent/galasa-managers-zos-parent/dev.galasa.zosfile.zosmf.manager/src/main/java/dev/galasa/zosfile/zosmf/manager/internal/ZosmfZosFileHandlerImpl.java - a lot of our tests and managers come into this piece of code to create files and datasets.
It keeps an in-memory store of all the resources it creates, and cleans up on teardown.
However, if a test run aborts, the cleanup doesn't happen. Therefore there are orphaned files/datasets left on the machine.
Resource management solves this. A resource should probably be added to resource management at the point the file/dataset is actually "physically created" and only if the "shouldCleanup" switch is
true.The snag then is, when the resmon daemon picks up with resource because the test run is deemed stale, how does it delete it from the zOS machine?
I think this is something my team can work on and contribute back, however, I would immediately turn to the zOSmf code I put in place to kill orphaned CICS Regions, as it can delete resources also. Would this be the correct public solution for this though?
Steps to reproduce
Expected behavior
File/datasets from old runs should be deleted. We probably get around this, because a lot of our files/datasets are created within the test run dir/hlq and are indirectly deleted this way, but some aren't.
Additionally - some test run dirs/HLQ also don't get removed if tests are aborted, perhaps they should?