[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:
Backports
Depends
Related
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:

 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 –
For Cloud and Ops Manager autodiscovery purposes, when SSL is enabled, the config server collection "config.mongoS" and rs.status() should expose FQDNs instead or in addition of short hostnames.

This is a followup for the now closed ticket SERVER-2421 that added FQDNs to the serverStatus function. That is not sufficient since when using SSL you are not allowed to connect and get the serverStatus.advisoryHostFQDNs output using the shortname (hostname validation will fail).



 Comments   
Comment by Githook User [ 02/Jul/18 ]

Author:

{'username': 'devkev', 'name': 'Kevin Pulo', 'email': 'kevin.pulo@mongodb.com'}

Message: SERVER-25746 store advisoryHostFQDNs in config.mongos

(cherry picked from commit 75c8414afea212e79b27dae42cfd2930bdfd6eea)
Branch: v3.4
https://github.com/mongodb/mongo/commit/0d6a9242c11b99ddadcfb6e86a850b6ba487530a

Comment by Githook User [ 02/Jul/18 ]

Author:

{'username': 'devkev', 'name': 'Kevin Pulo', 'email': 'kevin.pulo@mongodb.com'}

Message: SERVER-25746 store advisoryHostFQDNs in config.mongos

(cherry picked from commit 75c8414afea212e79b27dae42cfd2930bdfd6eea)
Branch: v3.6
https://github.com/mongodb/mongo/commit/dac050cc1a69c6bfa5d1e59646b936c25f8e4fa1

Comment by Githook User [ 12/Feb/18 ]

Author:

{'email': 'kevin.pulo@mongodb.com', 'name': 'Kevin Pulo', 'username': 'devkev'}

Message: SERVER-25746 store advisoryHostFQDNs in config.mongos
Branch: master
https://github.com/mongodb/mongo/commit/75c8414afea212e79b27dae42cfd2930bdfd6eea

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?

Generated at Thu Feb 08 04:10:05 UTC 2024 using Jira 9.7.1#970001-sha1:2222b88b221c4928ef0de3161136cc90c8356a66.