[SERVER-4784] replSetInitiate without arguments breaks when hostname isn't resolvable Created: 26/Jan/12 Updated: 06/Dec/22 Resolved: 22/Feb/18 |
|
| Status: | Closed |
| Project: | Core Server |
| Component/s: | Replication |
| Affects Version/s: | 2.0.2 |
| Fix Version/s: | None |
| Type: | Improvement | Priority: | Minor - P4 |
| Reporter: | Richard Kreuter (Inactive) | Assignee: | Backlog - Replication Team |
| Resolution: | Done | Votes: | 0 |
| Labels: | None | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Environment: |
MacOSX, but generally anywhere the hostname resolution behavior is screwy. |
||
| Attachments: |
|
||||||||||||
| Issue Links: |
|
||||||||||||
| Assigned Teams: |
Replication
|
||||||||||||
| Participants: | |||||||||||||
| Description |
|
replSetInitiate with no arguments doesn't work when the mongod's host's name isn't resolvable. (This is the default behavior on MacBooks, The trouble is I'm not sure what the bug is: (1) File this as a documentation bug and say that a no-arg initiate doesn't work if your hosts don't know their own names. (We probably don't really want people deploying onto hosts with dodgy hostname resolution behaviors anyway, i.e., say that a good DNS configuration is a prerequisite like NTP is.) This is a principled position, but it means we will continue not to have an easy way to initiate a replica set in these cases. (2) Otherwise, to support a simple way to initiate even in these cases, let the user give just a "hostname:port" or "hostip:port" string. Patch attached. Strictly speaking, (2) is an incompatible change, since replSetInitiate currently ignores any non-document argument. (Probably it should have ignored only null arguments, but oh well.) So there's some quibbling possible about whether to do (2). |