Version: v2.3.1Beta1/2004-10-19T08:53:51
Test Suite: ngamsArchiveCmdTest
Description:
Synopsis:
Test the ARCHIVE Command.
Description:
The Test Suite exercises the ARCHIVE Command. It tests the normal behavior,
but also more advanced features such as Back-Log Buffering.
Both Archive Push and Archive Pull is tested.
Test Case: test_ArchivePullReq_1
Description:
Synopsis:
Test Archive Pull Request/file:.
Description:
Files can be archived either via the Archive Push and Archive
Pull Technique. When using latter, a URL is specified where the
server will pick up the file.
Expected Result:
When issuing the file and specifying the URL (file:filename) the
Archive Pull Request should be handled as expected.
Test Steps:
- Start server.
- Archive file specifying the file URL pointing to it.
- Check the contents of the status returned if the file was properly
archived.
Remarks:
...
Test Case: test_ArchivePullReq_2
Description:
Synopsis:
Test Archive Pull Request/Retrieve Request
(http://:/RETRIEVE?file_id=).
Description:
When using the Archive Pull Technique, it is possible to archive a
file into an NGAS Node, by specifying its URL its URL in another
NGAS Node where the file was archived previously.
Expected Result:
When the file is archive into an NGAS Node by specifying it URL to
retrieve it from another, node, the archiving should take place as
usual for Archive Push/Pull Requests.
Test Steps:
- Create a simluated cluster with 2 nodes.
- Archive a file into one of the nodes.
- Re-archive on the other node via an Archive Pull Request (via HTTP)
into the other node.
- Check the contents of the NG/AMS Status Document returned.
Remarks:
...
Test Case: test_ArchivePushReq_1
Description:
Synopsis:
Test archiving of file URIs with equal signs in them (DFS01820).
Description:
The purpose of this Test Case is to check if the system can handle
archiving of files with equal signs in the name.
Expected Result:
When issuing a file with an equal sign in the URI, the archiving should
take place as normal.
Test Steps:
- Start server.
- Create test FITS file with equal signs in the name.
- Archive this.
- Check that the status (File Info) is as expected.
Remarks:
...
Test Case: test_ArchiveRobustness_01_01
Description:
Synopsis:
Spurios files found in Staging Area/Offline.
Description:
If Staging Files are found in a Staging Area something went wrong
during handling of an Archive Rerquest. Such files should be moved
to the Bad Files Area when the server goes Online/Offline.
Expected Result:
When the server goes online it should find the spurios files in a
Staging Area and move these to the Bad Files Area.
Test Steps:
- Start server.
- Create a set of spurios files in all Staging Areas.
- Stop server.
- Check that all files have been moved to the Bad Files Area.
Remarks:
...
Test Case: test_ArchiveRobustness_02_01
Description:
Synopsis:
Server dies before cleaning up the Staging Files.
Description:
This Test Case is similar to test_ArchiveRobustness_01_01 but
in this case it is a real test scenario.
Expected Result:
When the server is started up, it should find the Request Properties
File in a Staging Area and move this to the Bad Files Area.
Test Steps:
- Start server that crashes before cleaning up the Staging File(s).
- Archive file, the server should kill itself.
- Check that the Req. Props. File is in the Staging Area.
- Start the server.
- Check that the Req. Props. File is moved to the Bad Files Area.
Remarks:
...
Test Case: test_BackLogBuf_01
Description:
Synopsis:
Test handling of Back-Log Buffering (basic test).
Description:
The purpose of this test is to check the proper functioning of the
Back-Log Buffer Feature. In this case, the error ocurring is a
DB com. problem (NGAMS_ER_DB_COM).
Expected Result:
Staging File and Req. Props. File are stored in the Back-Log Buffer.
Test Steps:
- Start server with test configuration, which specifies a DAPI that
raises an exception forcing the server to Back-Log Buffer a file.
Janitor Thread Suspension Time = very long.
- Archive file.
- Check response that the file was Back-Log Buffered by the server.
- Check that the Staging File and the Req. Props. File are stored
in the Back-Log Buffer and that the contents is as expected.
- Stop the server.
- Start normal server + check that Back-Log Buffered file is archived.
Remarks:
...
Test Case: test_ErrHandling_1
Description:
Synopsis:
Test handling of illegal FITS Files.
Description:
The purpose of this test is to check if NG/AMS and the DAPI,
'ngamsFitsPlugIn', properly handle/detect the following improper FITS
Files/error conditions:
- Illegal size of FITS file (not a multiple of 2880).
- Missing CHECKSUM keyword.
- Illegal checksum in FITS file.
- Unknown mime-type.
- Illegal File URI at Archive Pull.
Expected Result:
In all of the cases above, NG/AMS or the DAPI should detect the problem
and return an error message to the client. The Staging Area should
be cleaned up.
Test Steps:
- Start server.
- Create test file (size!=2880) and archive this:
- Check the error response from the server.
- Check that the Staging Areas are cleaned up.
- Check that Bad Files Area is empty.
- Create file with no CHECKSUM keyword in it:
- Check the error response from the server.
- Check that the Staging Areas are cleaned up.
- Check that Bad Files Area is empty.
- Create FITS File with illegal CHECKSUM in the header:
- Check the error response from the server.
- Check that the Staging Areas are cleaned up.
- Check that Bad Files Area is empty.
- Create a file with an unknown mime-type:
- Check the error response from the server.
- Check that the Staging Areas are cleaned up.
- Check that Bad Files Area is empty.
- Issue an Archive Pull Request with an illegal URI:
- Check the error response from the server.
- Check that the Staging Areas are cleaned up.
- Check that Bad Files Area is empty.
Remarks:
...
Test Case: test_ErrHandling_2
Description:
Synopsis:
Problems creating Replication File.
Description:
This test exercises the handling of the situation where the Replication
File cannot be created, in this case due to that the Replication Area
is read-only.
Expected Result:
When failing in creating the Replication File, the NG/AMS Server
should detect this, and send back an Error Response to the client.
Test Steps:
- Start server.
- Make the target Replication Disk read-only.
- Archive file.
- An error message should be returned, check contents of this.
Remarks:
It could be considered if the NG/AMS Server should roll-back the
Main File, which was archived. This however, is not so easy to
implement. The most important is that the client is informed that
the archiving failed, and can re-submit the file. The operator
would need to intervene to rectify the problem.
Test Case: test_ErrHandling_3
Description:
Synopsis:
No free Storage Sets for mime-type.
Description:
The purpose of this Test Case is to check the handling of the situation
where there are no free Storage Sets for a given mime-type.
Expected Result:
The server should detect this and should send back an error message.
The Staging Areas and the Bad File Areas should be empty.
Test Steps:
- Start server.
- Mark all disks as completed in the DB.
- Archive a file.
- Check the contents of the error response from the server.
- Check that no files are found in the Staging Areas or in the
Bad Files Area.
Remarks:
...
Test Case: test_MainDiskSmallerThanRep_1
Description:
Synopsis:
Check usage of several Main Disks with one Rep. Disk (different sizes
of Main and Rep. Disks).
Description:
The purpose of this test is to verify that it is possible to use
several Main Disks together with one Replication Disk. This simulates
the operational scenario where e.g. 80 GB Main Disks are used together
with 200 GB Rep. Disks.
Expected Result:
When archiving onto the Mixed Disk Set, the Main Disk should become
completed, but the Rep. Disk not. After changing the Main Disk, it
should be possible to continue to archive onto the Disk Set until
either the Main Disk or the Rep. Disk gets completed.
Test Steps:
- Start server with following disk cfg.:
- Main
Test Case: test_NoDapi_01
Description:
Synopsis:
No DAPI installed to handled request/Archive Push/wait=1.
Description:
If the specified DAPI cannot be loaded during the Archive Request
handling it is not possible to handle the Archive Request and
the server must bail out.
Expected Result:
The Archive Request handling should be interrupted and an error
reply sent back to the client since wait=1. The files in connection
with the request should be removed from the Staging Area.
Test Steps:
- Start server with configuration specifying a non-existing DAPI
to handle FITS files.
- Archive FITS file (wait=1).
- Check error reply from server.
- Check that Staging Area is cleaned up.
- Check that no files were archived.
- Check that no files moved to Bad Files Area.
Remarks:
...
Test Case: test_NormalArchivePushReq_1
Description:
Synopsis:
Test handling of normal Archive Push Request/check that Disk
Change Notification Message is sent out.
Description:
This Test Case exercises the Archive Push Request. It is checked
that a disk change is done as expected and that an Email Notification
Message is sent out in this connection.
The contents of the DB should be updated (ngas_files, ngas_disks)
and the NgasDiskInfo file on the completed disk as well.
Expected Result:
After the first Archive Request, the first Target Disk Set should
be marked as completed and an Email Notification sent out
indicating this (Email Disk Change Notification).
The information about the Main and Rep. Files should be indicated
in the DB. The entry for that disk in ngas_disks should be updated.
The NgasDiskInfo file on the Target Disk Set, which is now completed,
should be updated with the newest information and marked as completed.
Test Steps:
- Start server setting Email Notification up to work on local host
and sending the emails to the user running the test + set the
amount of required, free space so high that an immediate Disk
Change will take place.
- Archive a file.
- Receive the Email Notification + check the contents of this.
- Dump the info for the Main and Rep. Disks and check these.
- Dump the info for the Main and Rep. Files and check these.
- Load the NgasDiskInfo files on the Target Disk Set disks and
check the contents of these.
Remarks:
Consider to re-implement this Text Case, using the simulated disks in
the form of file systems in files.
Test Case: test_NormalArchivePushReq_2
Description:
Synopsis:
Test handling of normal Archive Push Request/check that Disk Space
Notification Message is sent out.
Description:
Before a disks get classified as completed, a Disk Space Notification
Message can be sent out to prepare the operators that soon a Disk
Set will be full. This test checks if this message is sent out as
expected.
Expected Result:
After having issued an Archive Push Request the disk should
reach the thresshold value for sending out the Disk Space Notification
Email.
Test Steps:
- Start server with cfg. specifying test user at localhost as
receiver for the Disk Space Notification Messages + set the threshold
for sending out Disk Space Notification Messages so high, that this
will happen immediately.
- Archive a file (Archive Push).
- Receive the Notification Message and check the contents.
Remarks:
Consider to re-implement this Text Case, using the simulated disks in
the form of file systems in files.
Test Case: test_NormalArchivePushReq_4
Description:
Synopsis:
Test handling of normal Archive Push Request/no_versioning=1.
Description:
It is possible to indicate to the NG/AMS Server in connection with an
Archive Request, that no new version number should be allocated
(if this is supported by the DAPI). If this is the case a file
archived with the same File ID as a previous file archived will
overwrite this, at least the DB entry, possibly also the file on disk
if NGAS is still writing to the same disk.
Expected Result:
After archiving the file the 2nd time, the first entry should be
overwritten.
Test Steps:
- Start server.
- Issue Archive Push Request/no_versioning=1.
- Re-issue the same Archive Push Request/no_versioning=1.
- Check that the File Info is the same for the 2nd Archive Request
as for the first.
Remarks:
...