Story #3729
Updated by Chris Jones about 11 years ago
After gaining some experience with CN-based authority for system metadata, we've realized that there are many use cases that require system metadata to be managed by the MNs authoritatively, and by the CNs secondarily as a cached version. The main use case involves access control. When an ITK client creates an object through MN.create(), control of the system metadata is transferred to the CN once synchronization happens. After that point, the ITK client (and scientist) has to make CN.setAccessPolicy() calls to make any changes. If the MN is set to sync once a week, this is problematic.
Ultimately, the CN stores and manages system metadata in order to track replicas of an object, and to perform auditing on those replicas. This change would really just require that the CN remains the authority of the ReplicaList, whereas the MN would become the authority of all other fields. By doing so, ITK clients will be able to interact with their MN without delay, and the CNs will work off of cached versions of the system metadata (in Hazelcast and persisted in Metacat).
To effect these changes, specific sub tasks include:
1) Design of the system - sequence diagram and use case changes
2) Update architecture and guide docs to express that the MN is the authoritative source for system metadata
3) Ensure MN API calls reflect that the MN is responsible for incrementing serial version
3.1) Serial version will be used to track all fields except the ReplicaList
3.2) Consider adding an optional serialVersion attribute to a a ReplicaList, and use it to track versions of the list on the CN
4) Include a push notification of system metadata change (CN.systemMetadataChanged())
5) Change the CN stack to accommodate the MN-based authority
5.1) Replication
5.2) Synchronization
5.3) DAO layer for replication
6) Change all MN stacks to implement the new features (Metacat, GMN, Mercury, EDAC, Dryad, Merritt)
7) Add MN.updateSystemMetadata() interfaces (d1_common_{java|python}, d1_libclient_{java|python})
8) Refactor CN sysmeta methods to delegate to MN.
Ultimately, the CN stores and manages system metadata in order to track replicas of an object, and to perform auditing on those replicas. This change would really just require that the CN remains the authority of the ReplicaList, whereas the MN would become the authority of all other fields. By doing so, ITK clients will be able to interact with their MN without delay, and the CNs will work off of cached versions of the system metadata (in Hazelcast and persisted in Metacat).
To effect these changes, specific sub tasks include:
1) Design of the system - sequence diagram and use case changes
2) Update architecture and guide docs to express that the MN is the authoritative source for system metadata
3) Ensure MN API calls reflect that the MN is responsible for incrementing serial version
3.1) Serial version will be used to track all fields except the ReplicaList
3.2) Consider adding an optional serialVersion attribute to a a ReplicaList, and use it to track versions of the list on the CN
4) Include a push notification of system metadata change (CN.systemMetadataChanged())
5) Change the CN stack to accommodate the MN-based authority
5.1) Replication
5.2) Synchronization
5.3) DAO layer for replication
6) Change all MN stacks to implement the new features (Metacat, GMN, Mercury, EDAC, Dryad, Merritt)
7) Add MN.updateSystemMetadata() interfaces (d1_common_{java|python}, d1_libclient_{java|python})
8) Refactor CN sysmeta methods to delegate to MN.
