Details
-
Bug
-
Resolution: Fixed
-
Critical
-
6.5.1, 6.6.0, 6.6.1, 6.5.0, 7.0.0-Beta1
-
Untriaged
-
1
-
No
Description
What's the issue?
There's two issue here which I'll explain individually.
The first issue being that It looks like 'cbbackupmgr' does not correctly support the alternative addressing mode. FWIW the REST clients themselves both correctly handle alternative addressing mode, however, it's never actually enabled when bootstrapping.
Below is an example of the output provided by the 'nodeServices' endpoint:
NodeServices |
{
|
"rev": 13,
|
"nodesExt": [
|
{
|
"services": {
|
"mgmt": 8091,
|
"mgmtSSL": 18091,
|
"kv": 11210,
|
"kvSSL": 11207,
|
"capi": 8092,
|
"capiSSL": 18092,
|
"projector": 9999
|
},
|
"thisNode": true,
|
"alternateAddresses": {
|
"external": {
|
"hostname": "somehostname",
|
"ports": {
|
"kv": 9000
|
}
|
}
|
}
|
}
|
],
|
"clusterCapabilitiesVer": [
|
1,
|
0
|
],
|
"clusterCapabilities": {
|
"n1ql": [
|
"enhancedPreparedStatements"
|
]
|
}
|
}
|
Below is the structure which is used to decode the output:
Node Structure |
type Node struct {
|
Hostname string `json:"hostname"`
|
Services NodeServices `json:"services"`
|
Alt *AlternateAddresses `json:"alternateAddresses,omitempty"`
|
}
|
The important thing to notice here, is that we're decoding the alternate address payload as 'alternateAddresses', however, it's actually under the path 'alternateAddresses.external'.
The second issue here, is that when bootstrapping against a single node cluster 'cbbackupmgr' will implicitly fill in the unknown hostname/address with the address which was used to bootstrap the client. This has the effect of forcing alternate addressing mode to never be triggered. The fix here will be to only set the unknown hostname/address if the bootstrap address is not equal to the nodes alternate address (this is know at bootstrap time via 'nodeServices'.
Attachments
Issue Links
- relates to
-
MB-32761 Tools support to use alternate address
- Closed