Versions Compared

Old Version 1

changes.mady.by.user Danny Bernstein

Saved on

compared with

New Version 2

changes.mady.by.user Danny Bernstein

Saved on

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

...

Project

Tested by

Success? RC-1

Success RC-2

Notes






Islandora

Success? RC-2

 Project

Tested by

Success? RC-1

Notes

CLAW?





API-X

Success? RC-2

 Project

Tested by

Success? RC-1

Notes

fcrepo-api-x-integration




fcrepo-api-x-demo (Docker)


...

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                  


LinuxJettyFile-simple4.7.54.7.5100







Kevin Ford

LinuxTomcatPostgres4.7.14.7.5-RC640064006.7 G(tick)

(tick)

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

LinuxTomcatPostgres







4.7.34.7.5-RC640064006.7 G(tick)

(tick)

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

LinuxTomcatPostgres4.7.44.7.5-RC640064006.7 G(tick)

(tick)

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

LinuxTomcatMysql4.7.44.7.5-RC-1794561196996G(tick)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

LinuxTomcatMysql 5.64.7.54.7.5-RC-1640064006.7 G(tick)(tick)

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

LinuxTomcatPostgres4.7.54.7.5-RC640064006.7 G(tick)(tick)

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. 

...

(tick) auth working(tick) audit disabled

(tick) triplestore is staying in sync

(tick) solr

(tick) triplestore reindexing

Test stepsTested BySuccess RC2?Notes

FEDORA_AUTH=true
FEDORA_AUDIT=false

Bethany Seeger

(tick)




FEDORA_AUTH=false
FEDORA_AUDIT=false

Danny Bernstein

(tick)

 (tick) auth (disabled as expected)

(tick) audit disabled

(tick) triplestore is staying in sync

(tick) solr

(tick) triplestore reindexing




FEDORA_AUTH=true
FEDORA_AUDIT=true

Danny Bernstein

(tick)

(tick) Triple Store

(tick) Auth

(tick) Reindexing

(tick) Solr (after a "vagrant box update" and "vagrant destroy" it seems to work now).

(warning)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.

(tick) Audit events: with this caveat

(warning) 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)[

(info) I confirmed that this behavior exists in in the 4.7.4




FEDORA_AUTH=false
FEDORA_AUDIT=true

Danny Bernstein

(tick)(tick)




Manual Tests

Same as above, plus:

...

Backwards Compatibility Tests

  1. Start 45.70.4 0 one-click
  2. Load sample datasets via /fcr:restore
  3. Run test scripts on 45.70.40
  4. Stop 45.70.40
  5. Start RC one-click
  6. Run test scripts on RC
  7. ReStart RC
  8. Run test scripts on RC
Success RC2(tick)
Tested bySuccess RC1Notes

Kevin Ford

(tick)(tick)Did not run camel_toolbox_tests or authz_tests.

Danny Bernstein







Resources

[1] Testing scripts

...