Testing Blocker Tickets

  • ...

External Projects

Hydra

Project

Tested by

Success? RC-1

Notes

ActiveFedora

Adam Wead

Jennifer Smith

(tick)


CurationConcerns

Esmé Cowles

(tick)


Hyrax

Darren Weber

Jim Coble

Jennifer Smith

(tick)

(tick)

(tick)


Plum
Esmé Cowles


 (tick)
 
Sufia

Esmé Cowles

 (tick)
 

Islandora

 Project

Tested by

Success? RC-1

Notes

CLAW

Nick Ruest

(tick)#IslandoraCon demo works fine with 4.7.3-RC1

Testing Plan

git clone https://github.com/fcrepo4/fcrepo4
cd fcrepo4
git checkout <version>-RC

Sanity Builds

ProjectCommandPlatformTested bySuccess?Notes
fcrepo4mvn clean install

linux

 Andrew Woods

(tick)  
fcrepo4mvn clean install mac Jared Whiklo (tick)  
fcrepo4mvn clean installwindowsAaron Birkland (tick)  
fcrepo-module-auth-rbaclmvn clean installlinux

Andrew Woods 

(tick)  
fcrepo-module-auth-rbaclmvn clean install mac Jared Whiklo(tick)  
fcrepo-module-auth-rbaclmvn clean installwindows

Aaron Birkland 

(tick)  
fcrepo-module-auth-xacmlmvn clean install linux

Andrew Woods 

(tick)  
fcrepo-module-auth-xacmlmvn clean install macJared Whiklo (tick)  
fcrepo-module-auth-xacmlmvn clean installwindows

 Aaron Birkland

(tick)  
fcrepo-module-auth-webacmvn clean install linux

Andrew Woods 

(tick)  
fcrepo-module-auth-webacmvn clean install mac

Jared Whiklo 

(tick)  
fcrepo-module-auth-webacmvn clean installwindows

Aaron Birkland 

(tick)  
fcrepo-mintmvn clean install linux

Andrew Woods 

(tick)  
fcrepo-mintmvn clean install mac

 Jared Whiklo

(tick)  
fcrepo-mintmvn clean installwindowsAaron Birkland (tick)  
fcrepo-auditmvn clean install linux

Andrew Woods 

(tick)  
fcrepo-auditmvn clean install mac

 Jared Whiklo

(tick)  
fcrepo-auditmvn clean installwindows

Aaron Birkland 

(tick) 
fcrepo-webapp-plusmvn clean install linux

Andrew Woods 

(tick)  
fcrepo-webapp-plusmvn clean install mac

Jared Whiklo 

(tick)  
fcrepo-webapp-plusmvn clean install windows

 Aaron Birkland

(tick) 
fcrepo-webapp-plusmvn clean install -Pwebac linux

Andrew Woods 

(tick) 

 

fcrepo-webapp-plusmvn clean install -Pwebac mac

 Jared Whiklo

 (tick) 
fcrepo-webapp-plusmvn clean install -Pwebac windows

 Aaron Birkland

(tick) 
fcrepo-webapp-plusmvn clean install -Pauditlinux

 Andrew Woods

(tick) 

 

fcrepo-webapp-plusmvn clean install -Paudit mac

Jared Whiklo 

 (tick) 
fcrepo-webapp-plusmvn clean install -Paudit windows

 Aaron Birkland

 (tick) 
fcrepo-webapp-plusmvn clean install -P\!webac,\!auditlinux

 Andrew Woods

(tick)  
fcrepo-webapp-plusmvn clean install -P\!webac,\!audit mac

Jared Whiklo 

 (tick) 
fcrepo-webapp-plusmvn clean install -P\!webac,\!audit windows

 Aaron Birkland

 (tick) 

One-Click Run

cd fcrepo-webapp; mvn clean install -Pone-click
CommandPlatform Tested bySuccess? Notes
java -jar fcrepo-webapp-<version>-SNAPSHOT-jetty-console.jarLinux

Andrew Woods

Nick Ruest

(tick)
(tick)		 
java -jar fcrepo-webapp-<version>-SNAPSHOT-jetty-console.jarMac Youn Noh      (tick)Namespace prefix bindings in transactions that are rolled back persist.

java -jar fcrepo-webapp-<version>-SNAPSHOT-jetty-console.jar

Windows

 Aaron Birkland

(tick) 

Manual Tests

All of the below should take place in the HTML UI and non-vagrant tests should run against fcrepo-webapp-plus.

  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)

DatabasePlatformTested bySuccess?Notes
MySQLMacOSX 10.11.6
MySQL 5.7.17

 Jared Whiklo

 (tick)

 

PostgreSQLMacOSX 10.12.5
PostgreSQL 9.4.5		Esmé Cowles(tick)

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?

Notes                  

Andrew Woods

LinuxJettyfile-simple4.7.24.7.310010032-M(tick)plantpatents dataset

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 stepsTested bySuccess?Notes

FEDORA_AUTH=true
FEDORA_AUDIT=true

Ben Pennell

Andrew Woods

(tick)

(tick)

 

FEDORA_AUTH=false
FEDORA_AUDIT=true

Ben Pennell

Andrew Woods

(tick)

(tick)

 

FEDORA_AUTH=true
FEDORA_AUDIT=false

Ben Pennell

Andrew Woods

(tick)

(tick)

 

FEDORA_AUTH=false
FEDORA_AUDIT=false

Ben Pennell

Andrew Woods

(tick)

(tick)

 

Manual Tests

Same as above, plus:

  1. Verify audit events are in triplestore (tick)
  2. Verify resources are in triplestore (tick) (Note: indexing works very poorly when using the testing scripts because rapidly adding and then removing items causes the message queue to get very backed up)
  3. Verify resources are in Solr (tick)
  4. Verify authorization works for the two auth-enabled configurations (tick)
  5. Verify reindexing to triplestore works (tick) (tested by looking in fuseki after each step: adding a resource, adding a dc:title, removing dc:title, deleting resource.  Did not test the camel separate reindexing feature.)

4.7.0 - 4.7.2 Upgrade Testing

Tests to verify if 4.7.3 resolves errors seen with upgrading from 4.7.0 to 4.7.2

  1. 4.7.2
    1. Start 4.7.0 with a new data directory
    2. Create a resource with SKOS namespace

      1. curl -X POST -d "<> a <http://www.w3.org/2004/02/skos/core#Concept>; <http://www.w3.org/2004/02/skos/core#prefLabel> 'foo' ." -H "Content-type: text/turtle" -D - http://localhost:8080/rest/

    3. Stop 4.7.0
    4. Start 4.7.2 with the same data directory – should start successfully
    5. Stop and start 4.7.2 with the same data directory – should display error on startup
  2. 4.7.3
    1. Repeat 1. with a clean data directory, but deploying 4.7.3 instead of 4.7.2 and verifying that the error does not occur
Tested bySuccess?Notes

Andrew Woods

(tick)




[1] Testing scripts

[2] Fedora 4 Release Test Suite

  • No labels

11 Comments

  1. Aaron Birkland

    just reporting out that I have not been able to reproduce a 4.7.0→4.7.2 upgrade problem.

    I tried:

    • various permutations of levelDB, PostgreSQL, and LevelDB with no differences observed between them
    • Adding a mixture of objects, some using exclusively "built-in" namespaces, some with namespaces (such as SKOS) that were added later to the CND file in 4.7.1, and some with custom namespaces (e.g. <http://example.org/test#>
    • Using different classes of namespaces (custom, updated-in-4.7.2, built-in) together, in various positions (predicates vs objects)


    In all cases, creating these objects in 4.7.0, shutting down Fedora, and dropping 4.7.2 in its place did not cause any errors.  To verify, I

    • Started Fedora to see if there were any errors upon startup
    • Viewed each object with GET
    • Updated each object with PATCH.


    So I have not been able to confirm the working theory that modifying the CND file between releases causes any problems per se, and have not been able to confirm that reverting the CND file in 4.7.3 represents a fix 

    1. Andrew Woods

      I am able to reproduce the error and the fix with the following steps:

        • Using tomcat8 and mysql
      JAVA_OPTS="${JAVA_OPTS} -Dfcrepo.modeshape.configuration=classpath:/config/jdbc-mysql/repository.json"
      1. Ensure mysql is clean... meaning there is no existing Fedora data
      2. Deploy 4.7.0

      3. Create new object with obj.ttl

        curl -i -XPUT -H"Content-Type: text/turtle" --data-binary @obj.ttl localhost:8080/fcrepo/rest/obj

      4. Stop tomcat and remove exploded war

      5. Deploy 4.7.3-RC - all is well
      6. Restart 4.7.3-RC - all is well
      7. Stop tomcat and remove exploded war
      8. Deploy 4.7.2 - all is well
      9. Restart 4.7.2 - BOOM!

      Note: once we are in the BOOM state, it is not clear how to get out of it.

      1. Andrew Woods

        Update: I have also demonstrated the same behavior as noted above with the "file-simple" configuration:

        JAVA_OPTS="${JAVA_OPTS} -Dfcrepo.modeshape.configuration=classpath:/config/file-simple/repository.json"

        1. Andrew Woods

          Update: I have also demonstrated the same behavior as noted above with the "one-click".

          Steps:

          1. Place all three versions of the one-click in the same directory (4.7.0, 4.7.2, 4.7.3-RC)

          2. Start the 4.7.0 one-click

            java -jar fcrepo-webapp-4.7.0-jetty-console.jar --headless

          3. Create new object with obj.ttl

            curl -i -XPUT -H"Content-Type: text/turtle" --data-binary @obj.ttl localhost:8080/rest/obj

          4. Stop the 4.7.0 one-click

          5. Start the 4.7.3-RC one-click - all is well
          6. Stop/Start the 4.7.3-RC one-click - all is well
          7. Stop the 4.7.3-RC one-click
          8. Start the 4.7.2 one-click - all is well
          9. Stop/Start the 4.7.2 one-click - BOOM!

          1. Jim Coble

            Replicated Andrew Woods results from above.

          2. Aaron Birkland

            Ok, I've reproduced the issue following the above steps.  It seems like the re-start is somehow important

            1. Esmé Cowles

              I was also able to reproduce using these steps — and I do not see the error when I repeat the steps using 4.7.3rc1.

              1. Aaron Birkland

                Agreed  I see:

                4.7.0→ 4.7.2: error

                4.7.0→4.7.3: no error

                4.7.2→4.7.3: no error

      2. Aaron Birkland

        Well that's interesting.  I just re-started the instance I had up from the other day (running 4.7.2 now).  no BOOM.  Let me start over and use the exact data you are

  2. Aaron Birkland

    It looks 4.7.1 and 4.7.2 make the fatal error of removing the ns00* namespaces from the modeshape node that defines namespaces.  This happens for all ns00* URIs that were not defined in 4.7.0's CND file, but are defined in 4.7.1, 4.7.2.  Otherwise, all data seems to be intact. 

    Taking a backup (fcr:backup) from 4.7.1, 4.7.2 (if it's still running, and hasn't already seen the error) results in an unrestorable backup, since it's missing the ns00* namespaces.

    I found that by manually editing the json in the backup, the backup can then be used just fine.

    In particular, suppose that 4.7.0 used ns001: for http://www.w3.org/2004/02/skos/core#.  Fedora 4.7.1 and 4.7.2 want to call it skos:, and remove ns001 from the namespace definition node.

    The namespaces node can be found by digging through the json of a backup.  Edit it it in order to add in the ns00* namespaces:

    {
      "metadata": {
        "id": "a9789f6317f1e7mode:namespaces"
      },
      "content": {
        "key": "a9789f6317f1e7mode:namespaces",
        "parent": "a9789f6317f1e7jcr:system",
        "properties": {
          "http://www.jcp.org/jcr/1.0": {
            "primaryType": {
              "$name": "mode:namespaces"
            }
          }
        },
        "children": [
          {
            "key": "a9789f6317f1e7mode:namespaces-http://www.jcp.org/jcr/1.0",
            "name": "jcr"
          },  .... {
            "key": "a9789f6317f1e7mode:namespaces-http://www.w3.org/2004/02/skos/core#",
            "name": "skos"
          },
          {
            "key": "a9789f6317f1e7mode:namespaces-http://www.w3.org/2004/02/skos/core#",
            "name": "ns001"
          },

    That seems to be restorable into 4.7.3 via fcr:restore.  So it seems that there's a path forward to fixing repositories that have been affected by the underling issue.

  3. Aaron Birkland

    Here is a google doc containing potential release notes on how to identify and fix the corruption problem, for those who are running an affected 4.7.1 or 4.7.2 instance:  https://docs.google.com/document/d/1Dk2V2hqVyKs0V_70lAIObXT3_EjDIh8YxoZtdKnDdWU/edit?usp=sharing 

All content on the LYRASIS Wiki is licensed under the CC BY (Attribution) license, unless otherwise noted.