Bug #2356
No NodeId for the virtual CN represented by the RR DNS entry for CNs
100%
Description
During synchronization a entry is made for science metadata content indicating that the content has been replicated to a Coordinating Node. However, since the content is actually replicated to all CNs within the environment only a single entry is made. The nodeId for this replica is undefined since it should refer to the "virtual" CN indicating by the RR DNS entry for the environment so that the object can be retrieved from any CN. However, there is no nodeID that corresponds to the RR DNS entry.
See #2355 for example.
Possible resolutions:
1. Create a new nodeID that refers to the RR DNS entry
2. Use a "magic" value for nodeID that is interpreted by the resolve() method to mean any CN
3. Use the nodeID of the CN where synchronization was made
4. Add entries for each CN holding the object.
Option 4 is perhaps most appropriate, and the entry should be made when the object appears on the respective CN.
Option 3 is the simplest fix that will enable resolve() to function correctly.
Option 2 is a hack, and may have consequences for replica management.
Option 1 is probably asking for trouble.
Suggestion is to modify synchronization to use the current nodeId (i.e. option 3) until a better solution is determined.
Related issues
History
#1 Updated by Robert Waltz about 12 years ago
- Status changed from New to In Progress
#2 Updated by Dave Vieglais about 12 years ago
- Target version changed from Sprint-2012.07-Block.1.4 to Sprint-2012.09-Block.2.1
- Position set to 37
#3 Updated by Robert Waltz about 12 years ago
- Status changed from In Progress to Closed
Actually Option #1 is what we decided to do a few months ago and what has been implemented. I never populated the nodelist until now because we didn't have round robin.
We need to be able to access the RR DNS entry from the libclient packages, so we have to have it in the node list regardless.
We can change the entry pretty easily through the postinst scripts if we need to implement option 3.
Option 4 would be very easy to implement as well and would need no configuration changes. The issue with #4 is when we add a new CN. We would then have to modify all systemMetadata to include the new CN as an entry.
Having the round robin entry as the node ensures that a client can retrieve the data from any CN.
