Story #3548
CN Read-only mode implementation
100%
Description
CNCore & CNRead always up
reserveIdentifier operation must also be available.reserveIdentifier operation
How to transfer reserveIdentifiers when other CN's come back into the mix. We will often split the CNs while upgrading. We will need a journal of transactions to replay on the other machines.
reserveIdentifier operation
This should be separate from LDAP (in some way) such that in read-only mode reserveIdentifiers are not lost, but also do not corrupt LDAP.
Maybe test the problem with ldap such that duplicate identifiers are merged. How much of a problem does this cause?
Subtasks
Related issues
History
#1 Updated by Robert Waltz about 11 years ago
- Target version changed from 2013.6-Block.1.3 to 2013.14-Block.2.3
- Due date changed from 2013-02-06 to 2013-04-13
#2 Updated by Robert Waltz almost 11 years ago
- Due date changed from 2013-04-13 to 2013-07-20
- Milestone changed from CCI-1.1.1 to CCI-1.1.3
- Target version changed from 2013.14-Block.2.3 to 2013.28-Block.4.2
#3 Updated by Dave Vieglais over 10 years ago
- Target version changed from 2013.28-Block.4.2 to 2013.35-Block.5.1
- Due date changed from 2013-07-20 to 2013-09-07
#4 Updated by Robert Waltz over 10 years ago
- Due date changed from 2013-09-07 to 2013-10-05
- Target version changed from 2013.35-Block.5.1 to 2013.39-Block.5.3
#5 Updated by Robert Waltz over 10 years ago
- Milestone changed from CCI-1.1.3 to CCI-1.3
- Start date deleted (
2013-02-06) - Target version deleted (
2013.39-Block.5.3) - Due date deleted (
2013-10-05) - Product Version set to 1.3.0
#6 Updated by Chris Jones over 10 years ago
- Assignee changed from Robert Waltz to Rob Nahf
#7 Updated by Rob Nahf over 10 years ago
- Status changed from New to In Progress
code is committed to trunk, and branched (D1CN_SERVICE_v1.3)
I had trouble creating a unit test for CNRepliationController - something with the spring injection, so that's not committed, but the other methods passed tests, so I'm not worried.
#8 Updated by Rob Nahf over 10 years ago
- Status changed from In Progress to Closed
successfully deployed as part of CCI 1.2.4 to STAGE-2 and SANDBOX.
tested the cn.storage.readOnly property via curl to both CN machines (only one was disabled)
$ curl -X PUT https://cn-stage-orc-2.test.dataone.org/cn/v1/owner/abcde
<?xml version="1.0" encoding="UTF-8"?>
This CN instance has temporarily disabled methods that modify content
$ curl -X PUT https://cn-stage-unm-2.test.dataone.org/cn/v1/owner/abcde
<?xml version="1.0" encoding="UTF-8"?>
The 'serialVersion' must be provided as a parameter and was not.
$ curl -X GET https://cn-stage-orc-2.test.dataone.org/cn/v1/object/abcde
<?xml version="1.0" encoding="UTF-8"?>
No system metadata could be found for given PID: abcde
#9 Updated by Chris Jones over 10 years ago
- Target version set to 2014.2-Block.1.1
- Start date set to 2014-01-05
- Due date set to 2014-01-18
- Status changed from Closed to In Progress
Re-opening this ticket. While performing the CCI 1.2.4 upgrade, I switched cn-ucsb-1 into read-only mode in node.properties. In doing so, content in ONEMercury, while searchable, was not available via CN.resolve(). Likewise, the CN.listNodes() returns a service failure, so the ONEMercury UI wasn't able to populate the Member Node list control. Ultimately, it looks like the implementation disabled all services, rather than allowing CNCore and CNRead methods, and disabling other methods that write to the CNs.
#10 Updated by Chris Jones over 10 years ago
- Status changed from In Progress to Closed
Issue #4215 is resolved.
