The existing order of operations after restarting the share is:
1. mount share on ins-1
2. validate the test file on ins-1
3. mount share on ins-2
4. clear the test file using 'rm' on ins-1
5. write the test file on ins-1
6. read the test file on ins-2
The issue is that step 4. can result in a stale file handle on ins-2
which takes an unspecified amount of time to clear. Mounting the share
on ins-2 after the file is re-written does however work without a stale
file handle. The new order is:
1. mount share on ins-1
2. validate the test file on ins-1
3. clear the test file using 'rm' on ins-1
4. write the test file on ins-1
5. mount share on ins-2
6. read the test file on ins-2
Closes-Bug: #1107
In this change, a charm test that subclasses the ManilaBaseTest
class can also opt-in to re-validating a share after restarting
the share services by overriding the _restart_share_instance
method.
The current Manila Ganesha `test_manila_share` had a lot of
functionality that can be re-used to any configured Manila backend.
It's a good idea to have this functionality generalized into
`zaza.manila.tests.ManilaBaseTest`, which can be reused for any
tested Manila backend.
The manila charm contains a 'band-aid' for Bug #1706699 which relies
on update-status to bring up services if needed. When the tests run
an update-status hook might not have run so services may still be
stopped so force a hook execution.
Alex Kavanagh
Liam Young
FrancescoDeSimone
Gustavo Sanchez
Chris MacNaughton
Ionut Balutoiu
Chris MacNaughton