Elasticsearch-js: Client cloud id needs the correct usage sample

[aimyth]

🐛 Bug Report

First, thanks for the fabulous client, just the initial setup of the client has some documentation or code missing for the cloud id.
Client Cloud Link

To Reproduce

Steps to reproduce the behavior:

const client = new Client({     
  cloud: {    
    id: 'name:bG9jYWxob3N0JGFiY2QkZWZnaA=='      
  },      
  auth: {  
    username: 'elastic',  
    password: 'changeme'  
  }  
})

Here the id entered has a base64 encoded string. The document doesn't call this out.
The actual return from the cloud instance response is

{
  "name": "instance-0000000001",
  "cluster_name": "{{cloudname}}",
  "cluster_uuid": "{{uuidvalue}}",
  "version": {
    "number": "7.4.0",
    "build_flavor": "default",
    "build_type": "tar",
    "build_hash": "22e1767283e61a198cb4db791ea66e3f11ab9910",
    "build_date": "2019-09-27T08:36:48.569419Z",
    "build_snapshot": false,
    "lucene_version": "8.2.0",
    "minimum_wire_compatibility_version": "6.8.0",
    "minimum_index_compatibility_version": "6.0.0-beta1"
  },
  "tagline": "You Know, for Search"
}

If you provide just the cluster_name without the base64 encoded value.
You get the following error
TypeError [ERR_INVALID_URL]: Invalid URL: https://undefined.somevalue
and the process aborts.

if you provide the base64 encoded value, the process starts but gets the following error when accessing the cloud server {{base64encodedvalueof cluster_name_value}}

error: Error: ConnectionError: getaddrinfo ENOTFOUND undefined.cluster_name undefined.cluster_name:443
This also has a cosmetic bug. If in the elastic response this value is called cluster_name why in the id we specify "name:cluster_name_value" instead of "cluster_name:cluster_name_value"

If we now provide the entire cluster Id namely
cluster_name.us-east-1.aws.found.io:9243 as base64 encoded value then we get the following error.

error: Error: ConnectionError: Hostname/IP does not match certificate's altnames: Host: undefined.cluster_name.us-east-1.aws.found.io. is not in the cert's altnames: DNS:.us-east-1.aws.found.io, DNS:.foundcluster.com .

Not sure where is the undefined before the cluster name coming from

I also looked at the unit test
https://github.com/elastic/elasticsearch-js/blob/master/test/unit/client.test.js

test('Elastic cloud config', t => {
  t.test('Basic', t => {
    t.plan(5)
    const client = new Client({
      cloud: {
        // 'localhost$abcd$efgh'
        id: 'name:bG9jYWxob3N0JGFiY2QkZWZnaA==',
        username: 'elastic',
        password: 'changeme'
      }
    })

Here the test doesn't actually connect to a cloud id instance but instead does a test with a dummy localhost$abcd$efgh converted to the base64 which is the comment, which is partially true.

Expected behavior

Please let us know what needs to be the correct id passed here for the client.

Your Environment

• node version: 10.16
• @elastic/elasticsearch version: >=7.4
• os: Mac
• any other relevant information

[delvedor]

Hello! Thank you for the nice words :)
Regarding your issue, probably there is a misunderstanding of what the Cloud ID is.
The Cloud ID is a string value provided inside the Elastic Cloud UI, you can find it in the initial page of your deployment (is inside the red box in the image below):

The client then accepts that string value, and it will load the cluster URL from that.
So for example, if your Cloud ID is my-deployment:base64ecodedstring==, then you should use it as follows:

const { Client } = require('@elastic/elasticsearch')
const client = new Client({
  cloud: {
    id: 'my-deployment:base64ecodedstring=='
  },
  auth: {
    username: 'username',
    password: 'password'
  }
})

You shouldn't use any other value, only the Cloud ID is accepted there :)

[aimyth]

Thanks for the clarification. Works like a charm. It would help if this documentation is present in the client link too on how to get the cloud id. Client samples
Once documentation is updated you can close this issue.

[stale[bot]]

We understand that this might be important for you, but this issue has been automatically marked as stale because it has not had recent activity either from our end or yours.
It will be closed if no further activity occurs, please write a comment if you would like to keep this going.

Note: in the past months we have built a new client, that has just landed in master. If you want to open an issue or a pr for the legacy client, you should do that in https://github.com/elastic/elasticsearch-js-legacy