Archive operation not permitted for V1 readonly MNs
While attempting to archive content for SEAD in the production environment using a CN certificate to authenticate:
d1_common.types.exceptions.ServiceFailure: name: ServiceFailure
description: Couldn't determine the authoritative member node storage version for the pid seadva-HsuLeslie029090a9-11b8-4fc1-bf76-bb5a8153363f
The request is authenticated OK, but fails when the CN attempts to determine the version of the Storage API provided by the MN.
In this case, the MN is a Tier 1 node using the V1 API.
The problem lies in: /edu/ucsb/nceas/metacat/dataone/CNodeService.java at around line 601.
If the returned version is null then the node does not implement the storage API. In this case, the CN should check the version of the read API. If that is version 1, then the archive request should proceed since the CN is authoritative for that sysmeta. If the read API is V2, then the request should fail because the MN is authoritative for the sysmeta.
PIDs to be archived include:
#2 Updated by Jing Tao over 7 years ago
For v1 read-only MNs, we can allow CNs to change the system metadata object. I can image a v2 read-only MN maybe needs us to help to archive an object as well. In this approach:
If the returned version is null then the node does not implement the storage API. In this case, the CN should check the version of the read API. If that is version 1, then the archive request should proceed since the CN is authoritative for that sysmeta. If the read API is V2, then the request should fail because the MN is authoritative for the sysmeta
CNs can't help it.
#4 Updated by Jing Tao over 7 years ago
have the same issue.
After I looked at code, I found we are using the version of "MNStorage" as the version of the MN. It seems wrong. We should just use "MNRead" to determine the version of the MN.
#8 Updated by Rob Nahf about 7 years ago
- Status changed from Closed to In Progress
- % Done changed from 100 to 30
This is not really a bug, because it is newly designed behavior when we implemented V2. Synchronization accepts system metadata changes from v1 read-only MNs as if they were V2 nodes, as was discussed and agreed upon. Checking for v1 MNStorage service was the correct way to do this.
If we want to be able to assist MNs who don't want to (or can't) make changes to their system metadata, we should limit this special access to only CN/MN administrators.
The v1.archive implementation is broken, however, in that it delegates authorization to the v2.archive implementation, which only allows CN and MN administrators. This effectively disallows object rightsHolders from updating their systemMetadata objects.
#9 Updated by Jing Tao about 7 years ago
The issue is how we determine the version of a member node. We used the storage version as the version of the member node. However, for read-only node which doesn't support the storage, the mechanism will fail since it doesn't have it. So we change to the version of the MN.READ which every member node should support.