Testing Tickets

• RC-1
  • blocker -  Unable to locate Jira server for this macro. It may be due to Application Link configuration.
  • non-blocker -  Unable to locate Jira server for this macro. It may be due to Application Link configuration.
  • non-blocker -  Unable to locate Jira server for this macro. It may be due to Application Link configuration.
• RC-2
  • blocker - Unable to locate Jira server for this macro. It may be due to Application Link configuration.

External Projects

Hydra (instructions)

Project	Tested by	Success? RC-1	Success RC-2	Notes
ActiveFedora	Esmé Cowles Stuart Kenny
Hyrax	Esmé Cowles
Sufia	Jennifer Smith			Tested 7.3-stable branch
Valkyrie	Esmé Cowles Stuart Kenny
Avalon 6.0

Islandora

Project	Tested by	Success? RC-1	Success? RC-2	Notes
CLAW	Jared Whiklo

API-X

Project	Tested by	Success? RC-1	Success? RC-2	Notes
fcrepo-api-x-integration	Aaron Birkland
fcrepo-api-x-demo (Docker)

Testing Plan

git clone https://github.com/fcrepo4/fcrepo4
cd fcrepo4
git checkout 4.7.5-RC

Sanity Builds

Scripts

https://github.com/awoods/fcrepo-build-scripts

Project	Command	Platform	Tested By	RC 1	RC 2	Notes
fcrepo4	mvn clean install	linux	Andrew Woods		Jared Whiklo
fcrepo4	mvn clean install	mac	Joshua Westgard Danny Bernstein (rc-2)			Frequent warning: "Unable to update victims database! Your CVE records might be out of date."
fcrepo4	mvn clean install	windows	Ben Pennell Aaron Birkland			I wasn't able to perform a sanity build in Windows 10 due to some integration tests in fcrepo-kernel-modeshape failing.  A few of them were failing because the last modified date for binaries was not updating all of the time (tests were flapping). Unable to locate Jira server for this macro. It may be due to Application Link configuration. Danny Bernstein: NB - apparently this has been an ongoing issue. Apparently Windows 10 on hyper-v works, but is failing/flapping on direct windows install. Aaron Birkland and Yinlin Chen worked on resolving this a while back but did not crack it.
fcrepo-module-auth-rbacl	mvn clean install	linux	Andrew Woods		Jared Whiklo
fcrepo-module-auth-rbacl	mvn clean install	mac	Peter Eichman Danny Bernstein(rc2)			Frequent warning: "Unable to update victims database! Your CVE records might be out of date."
fcrepo-module-auth-rbacl	mvn clean install	windows	Aaron Birkland
fcrepo-module-auth-xacml	mvn clean install	mac	Peter Eichman Danny Bernstein (rc2)	???		No 4.7.5-RC branch or tag
fcrepo-module-auth-xacml	mvn clean install	windows
fcrepo-module-auth-webac	mvn clean install	linux	Andrew Woods		Jared Whiklo
fcrepo-module-auth-webac	mvn clean install	mac	Peter Eichman Danny Bernstein (rc2)			Frequent warning: "Unable to update victims database! Your CVE records might be out of date."
fcrepo-module-auth-webac	mvn clean install	windows	Aaron Birkland
fcrepo-mint	mvn clean install	linux	Andrew Woods		Jared Whiklo
fcrepo-mint	mvn clean install	mac	Peter Eichman Danny Bernstein (rc-2)			Frequent warning: "Unable to update victims database! Your CVE records might be out of date."
fcrepo-mint	mvn clean install	windows	Aaron Birkland
fcrepo-audit	mvn clean install	linux	Andrew Woods		Jared Whiklo
fcrepo-audit	mvn clean install	mac	Peter Eichman Danny Bernstein (rc-2)			Frequent warning: "Unable to update victims database! Your CVE records might be out of date."
fcrepo-audit	mvn clean install	windows	Aaron Birkland
fcrepo-webapp-plus	mvn clean install	linux	Andrew Woods		Jared Whiklo
fcrepo-webapp-plus	mvn clean install	mac Danny Bernstein (rc-2)	Peter Eichman			Frequent warning: "Unable to update victims database! Your CVE records might be out of date."
fcrepo-webapp-plus	mvn clean install	windows	Aaron Birkland
fcrepo-webapp-plus	mvn clean install -Pwebac	linux	Andrew Woods		Jared Whiklo
fcrepo-webapp-plus	mvn clean install -Pwebac	mac Danny Bernstein (rc-2)	Peter Eichman			Frequent warning: "Unable to update victims database! Your CVE records might be out of date."
fcrepo-webapp-plus	mvn clean install -Pwebac	windows	Aaron Birkland

Note (18 January 2018): The victims database warnings are due to the victi.ms site currently returning a 503 error. Jared Whiklo has reported this issue upstream: https://github.com/victims/victims-web/issues/155

One-Click Run

cd fcrepo-webapp; mvn clean install -Pone-click

Command	Platform	Tested By	RC-1	RC-2	Notes
java -jar fcrepo-webapp-<version>-SNAPSHOT-jetty-console.jar	Linux	Andrew Woods Jared Whiklo (RC 2)
java -jar fcrepo-webapp-<version>-SNAPSHOT-jetty-console.jar	Mac	Joshua Westgard Danny Bernstein (rc2)
java -jar fcrepo-webapp-<version>-SNAPSHOT-jetty-console.jar	Windows	Aaron Birkland

Manual Tests

1. Create nested containers
2. Create binary resources
3. Run fixity on binary
4. Update Properties:  Perform SPARQL-Update on container
5. Update Properties:  Perform SPARQL-Update on binary
6. Delete container
7. Delete binary
8. Use transactions
9. Create versions
10. View versions
11. Rollback versions

Database Tests

With Tomcat7 deployment, run above manual tests with alternate backend databases (Configuring JDBC Object Store)

Database	Platform	Tested by	Success RC1?	Success RC2?	Notes
MySQL	osx	Danny Bernstein Joshua Westgard			Danny Bernstein: Restoring v1 after creating v2 does not seem to work: Steps to reproduce: 1. Create a binary with fileA.jpg 2. Create version v1. 3. Update binary with fileB.jpg 4. Create version v2. 5. Click on versions link and click on v1 link. 6. Click "Revert to this Version" 7. Return to binary resource metadata page. Notice the file associated with the version fileB.jpg rather than the expected fileA.jpg. It does not appear that the version was reverted. Joshua Westgard: Hey Danny Bernstein, when I tested the versioning I was just making changes to metadata not binaries and didn't notice any problems; after seeing your note, however, I tried with a binary and did notice that the browser cached the previous version, so after restoring it was still displaying the previous data, but upon refreshing the resource page the restored version was visible as expected. Any chance this is the same problem you were seeing? Joshua Westgard: could be, though I thought I did a hard refresh. I'll try it again to conf hirm. Joshua Westgard: I must not have done a hard refresh. So yes after a hard refresh it worked. I wonder if it should be a logged as a bug nevertheless. Ideally any refresh would not be required at all. A Command-R refresh doesn't refresh the page. Only Command-Shift-R. It seems like it could be a source of confusion. Perhaps a JIRA is warranted. Here it is: Unable to locate Jira server for this macro. It may be due to Application Link configuration.
PostgreSQL	osx	Joshua Westgard	config successful; testing in progress
PostgreSQL	linux	Kevin Ford			Tests were performed against fcrepo-webapp-4.7.5-RC not fcrepo-webapp-plus-4.7.5-RC.
MySQL5.6	linux	Kevin Ford			Tests were performed against fcrepo-webapp-4.7.5-RC not fcrepo-webapp-plus-4.7.5-RC.
PostgreSQL	linux	Kevin Ford			Tests were performed against fcrepo-webapp-plus-4.7.5-RC.
MySQL5.6	linux	Kevin Ford			Tests were performed against fcrepo-webapp-plus-4.7.5-RC.

fcr:backup/fcr:restore Functionality

These tests are designed to ensure the proper function of the 'fcr:backup/fcr:restore' features by testing them against various Fedora configurations.  The validity of the 'restore' can only be determined by crawling the repository and verifying the successful retrieval of the repository's content.

If the anticipated Fedora release is not backwards compatible with the previous version of Fedora, then the "From Fedora Version" should be the previous version.  Otherwise, it is sufficient to test the fcr:backup/fcr:restore functionality using the same version.

See: RESTful HTTP API - Backup and Restore

# Backup
curl -X POST localhost:8080/rest/fcr:backup
 
# Restore
curl -X POST -d "/path/to/backup/directory" localhost:8080/rest/fcr:restore

Resources

• These python scripts - fcrepo-testing - can be used to load RDF content and binary content to a Fedora repository and verify the integrity of the loaded resources.  Output from the load process can be used to verify the integrity of a 'restored' repository.  See the README for more info.
• This script can be used to walk your repository, failing if a non-success response is encountered.

Tested by	Platform	Container (Tomcat/Jetty)	Database Backend	From Fedora Version	To Fedora  Version	Number of RDF Resources	Number of Binaries	Size of Backup (du -h .)	Success RC1?	Success RC2?	Notes
	Linux	Jetty	File-simple	4.7.5	4.7.5		100
Kevin Ford	Linux	Tomcat	Postgres	4.7.1	4.7.5-RC	6400	6400	6.7 G			Performed a GET test on all resources in 4.7.5 RC1 before /fcr:restore, thereby mimicking an 'in place upgrade.'  All succeeded. RC2 test used backup of 471 from RC1 test.
Kevin Ford	Linux	Tomcat	Postgres	4.7.3	4.7.5-RC	6400	6400	6.7 G			Performed a GET test on all resources in 4.7.5 RC1 before /fcr:restore, thereby mimicking an 'in place upgrade.'  All succeeded. RC2 test used backup of 473 from RC1 test.
Kevin Ford	Linux	Tomcat	Postgres	4.7.4	4.7.5-RC	6400	6400	6.7 G			Performed a GET test on all resources in 4.7.5 RC1 before /fcr:restore, thereby mimicking an 'in place upgrade.'  All succeeded. RC2 test used backup of 474 from RC1 test.
Michael Durbin	Linux	Tomcat	Mysql	4.7.4	4.7.5-RC-1	79456	11969	96G			Performed an fcr:export from 4.7.4.  Performed an fcr:import to 4.7.5-RC-1.  Performed a reindex using camel (to walk all RDF resources).  I did not test every binary.
Kevin Ford	Linux	Tomcat	Mysql 5.6	4.7.5	4.7.5-RC-1	6400	6400	6.7 G			Performed a GET test on all resources in 4.7.5 RC1 before /fcr:restore, as verification. All succeeded. For RC2 test, the back up that was restored in this test was actually created from a postgres backend repo.
Kevin Ford	Linux	Tomcat	Postgres	4.7.5	4.7.5-RC	6400	6400	6.7 G			Performed a GET test on all resources in 4.7.5 RC2 before /fcr:restore, as verification. All succeeded. For RC1 test, the back up that was restored in this test was actually created from a mysql backend repo.

NB: "Success" is measured not by receiving a "204 No Content" message after the 'fcr:restore' command, but by performing a GET on every resource in the repository and receiving "200 OK" messages. 

Vagrant Tests

vagrant destroy
vagrant up

Test steps	Tested By	Success RC2?	Notes
FEDORA_AUTH=true FEDORA_AUDIT=false	Bethany Seeger		auth working audit disabled triplestore is staying in sync solr triplestore reindexing
FEDORA_AUTH=false FEDORA_AUDIT=false	Danny Bernstein		auth (disabled as expected) audit disabled triplestore is staying in sync solr triplestore reindexing
FEDORA_AUTH=true FEDORA_AUDIT=true	Danny Bernstein		Triple Store Auth Reindexing Solr (after a "vagrant box update" and "vagrant destroy" it seems to work now). However: if I add an RDF triple to a node (in my case <> dc:title "blah") , I'm am not seeing the change reflected in solr. The triple is however present in fuseki. Is this expected behavior? ie are only some triples propagated to solr? The above turns out not to be an issue. Updates to solr are collected and then execute in batch operations. I just needed to wait a few seconds. Audit events: with this caveat I am seeing this stacktrace in the karaf logs upon adding a resource. Not sure if it is a problem. Audit events are being logged properly as far as I can tell in /audit and fuseki is also receiving the audit triples. sudo tail -f /opt/karaf/data/log/karaf.log: Stacktrace --------------------------------------------------------------------------------------------------------------------------------------- org.fcrepo.client.FcrepoOperationFailedException: HTTP operation failed invoking info:fedora/audit with statusCode: -1 and message: URI does not specify a valid host name: info:fedora/audit at org.fcrepo.client.FcrepoClient.executeRequest(FcrepoClient.java:218)[152:org.fcrepo.client.fcrepo-java-client:0.2.1] at org.fcrepo.client.FcrepoClient.executeRequest(FcrepoClient.java:204)[152:org.fcrepo.client.fcrepo-java-client:0.2.1] at org.fcrepo.client.RequestBuilder.perform(RequestBuilder.java:77)[152:org.fcrepo.client.fcrepo-java-client:0.2.1] at org.fcrepo.camel.FcrepoProducer.getMetadataUri(FcrepoProducer.java:251)[201:org.fcrepo.camel.fcrepo-camel:4.5.0] at org.fcrepo.camel.FcrepoProducer.getUri(FcrepoProducer.java:225)[201:org.fcrepo.camel.fcrepo-camel:4.5.0] at org.fcrepo.camel.FcrepoProducer.doRequest(FcrepoProducer.java:194)[201:org.fcrepo.camel.fcrepo-camel:4.5.0] at org.fcrepo.camel.FcrepoProducer.process(FcrepoProducer.java:156)[201:org.fcrepo.camel.fcrepo-camel:4.5.0] at org.apache.camel.util.AsyncProcessorConverterHelper$ProcessorToAsyncProcessorBridge.process(AsyncProcessorConverterHelper.java:61)[58:org.apache.camel.camel-core:2.18.0] at org.apache.camel.processor.SendProcessor.process(SendProcessor.java:145)[58:org.apache.camel.camel-core:2.18.0] at org.apache.camel.management.InstrumentationProcessor.process(InstrumentationProcessor.java:77)[ I confirmed that this behavior exists in in the 4.7.4
FEDORA_AUTH=false FEDORA_AUDIT=true	Danny Bernstein

Manual Tests

Same as above, plus:

(for reference: https://docs.google.com/presentation/d/1aU-qRVmU0lB18ywepk2AGYEmRe-HfIwhUaofHgathGQ/edit#slide=id.g11caa1fd99_0_0)

1. Verify audit events are in triplestore
2. Verify resources are in triplestore
3. Verify resources are in Solr
4. Verify authorization works for the two auth-enabled configurations

5. Verify reindexing to triplestore works

   vagrant ssh
   sudo service tomcat7 stop
   sudo rm -rf /etc/fuseki/databases/test_data/*
   sudo service tomcat7 start
   curl -XPOST localhost:9080/reindexing/ -H"Content-Type: application/json" -d '["activemq:queue:triplestore.reindex"]'

Backwards Compatibility Tests

1. Start 4.7.4 one-click
2. Load sample datasets via /fcr:restore
3. Run test scripts on 4.7.4
4. Stop 4.7.4
5. Start RC one-click
6. Run test scripts on RC
7. ReStart RC
8. Run test scripts on RC

Tested by	Success RC1	Success RC2	Notes
Kevin Ford			Did not run camel_toolbox_tests or authz_tests.
Danny Bernstein

Resources

[1] Testing scripts

[2] Fedora 4 Release Test Suite