Story #2720
KNB, LTER, PISCO, ESA, SANPARKS roll out
100%
Description
Here's the current plan of attack for upgrading all our MNs for the production release:
0. Stop traditional Metacat replication among MNs that will participate.
1a. Update existing access rules to only use 'allowFirst' - see sql script in Metacat project. This is a manual process and requires the admin to evaluate existing access blocks that might be using deny rules for some specific purpose. Analysis on the KNB shows that there are no meaningful rules used on that particular Metacat instance.
1b. Configure DOI prefixes for KNB, LTER, PISCO where appropriate. KNB will have entries for all three, LTER will have an entry for itself and for the KNB. PISCO need only have a DOI prefix for itself. (TBD: LTER needs to know about PISCO even though it has no direct replication relationship)
1c. This will generate DOIs for appropriate records (applies to KNB, LTER, and PISCO)
2. Upgrade Metacat 1.9.5 to 2.0.0 using the admin screens on each MN
2a. Generate SM for objects that originated on that MN (localhost/serverid=1 on the replication admin panel)
2b. Ensure replication policy for generated SM does not allow replication (numer_replicas = 0 is the default in metacat.properties)
3. Register the MNs with the CN. Only D1 synchronization will be running, not DataONE replication
3a. Wait for synchronization to complete for additional MNs that come on line (could be weeks)
4. When former replication partner MNs come online with their original content synched to the CNs we can set replication policies to allow replication for those objects (now that the known replicas are registered correctly with the CNs).
5. Generate SystemMetadata for objects that did not originate on the source MN (e.g., KNB can then generate SM for records that it houses from PISCO)
6. Audit task will eventually make sure MN SystemMetadata for replicas is updated to match the SM housed on the CN (with correct authoritatve MN information)
Please note that with this plan, MN system metadata will become stale when we set replication policy on the CN. We can call MN.systemMetadataChanged() for all ids when we are sure replication has processed all the objects.
Subtasks
Related issues
History
#1 Updated by Matthew Jones over 12 years ago
- Category set to Support Operations
- Status changed from New to In Progress
- Target version set to Sprint-2012.23-Block.3.4
#2 Updated by Dave Vieglais over 12 years ago
- Position set to 1
- Target version changed from Sprint-2012.23-Block.3.4 to Sprint-2012.25-Block.4.1
#3 Updated by Dave Vieglais over 12 years ago
- Milestone changed from CCI-1.0.0 to CCI-1.0.2
- Target version changed from Sprint-2012.25-Block.4.1 to Sprint-2012.27-Block.4.2
#4 Updated by Dave Vieglais over 12 years ago
- Position set to 1
- Position deleted (
9)
#5 Updated by Dave Vieglais over 12 years ago
- Milestone changed from CCI-1.0.2 to CCI-1.0.3
#6 Updated by Ben Leinfelder over 12 years ago
- Position deleted (
5) - Position set to 1
- Target version changed from Sprint-2012.27-Block.4.2 to Sprint-2012.29-Block.4.3
#7 Updated by Dave Vieglais over 12 years ago
- Milestone changed from CCI-1.0.3 to CCI-1.0.4
#8 Updated by Chris Jones about 12 years ago
- Target version changed from Sprint-2012.29-Block.4.3 to Sprint-2012.37-Block.5.3
#9 Updated by Chris Jones about 12 years ago
- Position deleted (
8) - Position set to 1
- Target version changed from Sprint-2012.37-Block.5.3 to Sprint-2012.35-Block.5.2
#10 Updated by Ben Leinfelder about 12 years ago
- Status changed from In Progress to Closed
finally closing -- subtasks are all complete or moved to separate tickets.