[SERVER-25746] Store advisoryHostFQDNs data in config.mongos collections Created: 23/Aug/16 Updated: 02/Jul/18 Resolved: 12/Feb/18 |
|
| Status: | Closed |
| Project: | Core Server |
| Component/s: | Sharding |
| Affects Version/s: | None |
| Fix Version/s: | 3.4.16, 3.6.6, 3.7.2 |
| Type: | Improvement | Priority: | Major - P3 |
| Reporter: | Emilio Scalise | Assignee: | Kevin Pulo |
| Resolution: | Done | Votes: | 1 |
| Labels: | neweng | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Issue Links: |
|
||||||||||||
| Backwards Compatibility: | Fully Compatible | ||||||||||||
| Backport Requested: |
v3.6, v3.4
|
||||||||||||
| Sprint: | Sharding 2018-01-29, Sharding 2018-02-12, Sharding 2018-02-26 | ||||||||||||
| Participants: | |||||||||||||
| Case: | (copied to CRM) | ||||||||||||
| Description |
|
When OpsManager is monitoring router (mongos) processes that it did not provision itself, it relies on the contents of the config.mongos collection on the config servers to enumerate all of the mongos processes. This ticket is to have the router processes include the information they provide in the advisoryHostFQDNs field of their serverStatus command responses when they self-report their identities by writing to config.mongos. In addition to the other fields in a config.mongos document, mongos servers should add an advisoryHostFQDNs section identical to the one reported in serverStatus, to facilitate discovery by the OpsManager monitoring service. – original description – This is a followup for the now closed ticket |
| Comments |
| Comment by Githook User [ 02/Jul/18 ] |
|
Author: {'username': 'devkev', 'name': 'Kevin Pulo', 'email': 'kevin.pulo@mongodb.com'}Message: (cherry picked from commit 75c8414afea212e79b27dae42cfd2930bdfd6eea) |
| Comment by Githook User [ 02/Jul/18 ] |
|
Author: {'username': 'devkev', 'name': 'Kevin Pulo', 'email': 'kevin.pulo@mongodb.com'}Message: (cherry picked from commit 75c8414afea212e79b27dae42cfd2930bdfd6eea) |
| Comment by Githook User [ 12/Feb/18 ] |
|
Author: {'email': 'kevin.pulo@mongodb.com', 'name': 'Kevin Pulo', 'username': 'devkev'}Message: |
| Comment by Kaloian Manassiev [ 04/Oct/17 ] |
|
Currently the config.mongos documents contain an _id with the hostname of the node as returned by gethostname. The way I understand this ticket is that we should extend the config.mongos document with an additional field advisoryHostFQDNs, which contains the host's latest obtained FQDNs as returned by mongo::getHostFQDNs. The collection will still be indexed by the hostname as it is now. This field may not be present, if the node was unable to resolve any FQDNs or if some of the mongos nodes have not been upgraded to the latest version to contain that. Also the value of the field may change across refreshes. |
| Comment by Andy Schwerin [ 23/Aug/16 ] |
|
The config.mongos collection is maintained by the individual mongos nodes, so if I'm right about replSetGetStatus working as desired, this can go to the sharding backlog. I'll move it there, for now. If the problem is about knowing the host name associated with the X.509 certificate for the mongos, maybe we should just report that when it's available? |