Add support of slow drive

[dboltovskyi]

This PR adds support of the drive with slow writing speed.
It's required for the ATF scripts for SDL-0117 Configurable time before shutdown feature published in LuxoftSDL/sdl_atf_test_scripts#129

Notes:

• Since implementation utilizes docker functionality feature is implemented only for local parallel mode of ATF;
• Tool losetup which is used to create loop device requires root permissions. In order to get rid of a corresponding message the command may be run on a host machine:
  • for Ubuntu 18.04: sudo chmod u+s /sbin/losetup
  • for Ubuntu 20.04: sudo chmod u+s /usr/sbin/losetup

This one time action needs to be done before running the tests for the first time.

[yang1070]

how slow drive is used? is it used for all ATF test scripts? or is it only used by a small set of test scripts related to "Configurable time before shutdown". Will adding a slow drive slow down running the atf test suites?

[dboltovskyi]

@yang1070 Please notice this specific ATF branch mostly required for scripts related to SDL-0117 feature.
It is not recommended to use it for other scripts. Even though other scripts wouldn't be slow down however there could be an issues with loop devices which would be created and deleted for each script run.

This and some other issues are the reasons why this ATF branch is not part of delivery and should only be used for testing the feature.

[yang1070]

@dboltovskyi are you saying that this change will not be merged into the release branch even if after the review and the SDL-0117 feature is completed ? otherwise it will impact the performance or stability of existing ATF tests?
is it possible to add some parameters to control the docker run so that for some test cases a slow disk is set up and for most test cases no slow disk created?

[yang1070]

@@dboltovskyi my concern is this change will cause the all other atf test cases takes a longer time to run

[dboltovskyi]

@yang1070 Please find the following updates:

• ATF: 765a952
• Scripts: LuxoftSDL/sdl_atf_test_scripts@33ac041

These changes allow ATF to create loop device only if it's required by script.
I did test them within new and existing scripts and they work fine.

Even though these changes work pretty stable I would think that loop device possibility requires a separate proposal.

Current solution has a few drawbacks:

• Pure flexibility. Now it's supported only write rate for a loop device. In case if we need to use other restrictions ATF would require an update. (e.g. drive size, read speed etc.) Though we can quite simply add a few more prospective options in a current implementation.
• ATF runner (before executing the script) fetches script's content to obtain loop device options ( e.g. config.isLoopDeviceRequired and config.loopDeviceWriteRate parameters). I guess this is not the best approach and there may be better one.
• There is a limit on number of available loop devices. It should correlate with the number of parallel workers. Issue would occur when total number of scripts currently assigned to the workers which require loop device exceeds number of available loop devices (in the system). This number is variable and depends on environment.
• Fault tolerance and error handling needs to be improved for the cases when loop device can't be created.

From other hand current solution is workable and we spent some amount of time to implement it. It might be not a good option to leave it in a specific branch.

We can fix some of the issues and try to push this PR into Open as part of feature implementation. Then to see what Project Maintainers think about it.

I would appreciate your feedback what do you think would be the best option here.