MNDeployment #3531: Gulf of Alaska Data Portal
Old Node ID recorded for origin, replicas on MN.
Noticed this while browsing PIDS on the GOA MN.
It appears the originMemberNode and some replica entries contain old node ids - that do not exist in production but were valid in stage/acceptance testing.
Issue appears to be limited to the MN, the CN do not appear to record the old node ids. So looks like issue could be corrected from the MN alone.
Issue does not appear to cause any errors for the CN infrastructure but may cause some questions/concerns from MN users.
A few examples:
http://goa.nceas.ucsb.edu/goa/d1/mn/v1/meta/df35a.22.8 (contains old origin and some odd replica entries)
https://cn.dataone.org/cn/v1/meta/df35a.22.8 (does not record the old origin or the odd replica entries, CN shows completely different replicas)
http://goa.nceas.ucsb.edu/goa/d1/mn/v1/meta/df35a.22.16 (another example of old origin member node)
https://cn.dataone.org/cn/v1/meta/df35a.22.16 (CN does not record old member node as origin, uses current node id)
http://goa.nceas.ucsb.edu/goa/d1/mn/v1/meta/df35a.22.5 (contains old origin and odd replica entries - cn-stage-2)
https://cn.dataone.org/cn/v1/meta/df35a.22.5 (CN version uses correct origin node id, does not record odd replicas)
#3 Updated by Lauren Walker almost 10 years ago
- Status changed from New to Closed
- translation missing: en.field_remaining_hours set to 0.0
I synced the access policies and updated the replication policy for all objects in the GOA MN, which in turn called dirtySysMeta to update the system metadata on the MN.