Nodes Info API does not include version qualifier for version

[tylersmalley]

Elasticsearch version (bin/elasticsearch --version): 7.0.0-alpha2

Description of the problem including expected versus actual behavior:

Currently, the Nodes Info API excludes the qualifier which was used to build the release.

Related to the changes in #35172 cc: @atorok

Steps to reproduce:

1. Use a build candidate of 7.0.0-alpha2 or a build created with a version qualifier -Dbuild.version_qualifier=foo
2. Check nodes info API: http://localhost:9200/_nodes?filter_path=nodes.*.version&pretty

Provide logs (if relevant):

Response I am seeing:

{
  "nodes" : {
    "w50PwaNiRxO3HBqGidJGsw" : {
      "version" : "7.0.0"
    }
  }
}

Currently, this is causing an ES node mismatch warning in the Kibana logs when running Kibana 7.0.0-alpha2

log [18:07:06.989] [warning] You're running Kibana 7.0.0-alpha2 with some different versions of Elasticsearch. Update Kibana or Elasticsearch to the same version to prevent compatibility issues: v7.0.0 @ 127.0.0.1:9200 (127.0.0.1)

[elasticmachine]

Pinging @elastic/es-core-features

[elasticmachine]

Pinging @elastic/es-core-infra

[alpar-t]

I added the team-discuss label. When we read and write NodeInfo we only include the version ID which no longer purposefully include the build qualifier. That's why we did the changes in #35172 so that we don't have to change code in order to change the build qualifier. So there's now a version specific to the build which is a string and includes the qualifier, red from jar meta data, and there's the version class which only includes what matters from a bwc point of view. I'm not sure we should include the fully qualified version for the Nodes API as it's the Version class that encodes which nodes are compatible among their-self.
@jasontedor any thaughts ?

[danielmitterdorfer]

We discussed this in this week's core/infra sync and decided to add a new field to the node stats API that provides the version including the qualifier as Kibana might want to show the full version to the user. Note that we do not provide any compatibility across pre-release versions (i.e. there are no guarantees that 7.0.0-alpha2 is compatible with 7.0.0-beta1) and it's only the version that is relevant for determining compatibility.

We did not settle on a name though for this new field and I think we should align / and /_nodes. For 7.0.0-alpha2 we see the following response in / (shortened):

{
  "version" : {
    "number" : "7.0.0-alpha2",
    "build_flavor" : "default",
    "build_type" : "tar",
    "build_hash" : "a30e8c2",
    "build_date" : "2018-12-17T12:33:32.311168Z",
    "build_snapshot" : false,
    "lucene_version" : "8.0.0",
    "minimum_wire_compatibility_version" : "6.6.0",
    "minimum_index_compatibility_version" : "6.0.0-beta1"
  }
}

/_nodes shows:

{
  "nodes" : {
    "7mvHxWJDRHO2OSR7daP-FA" : {
      "version" : "7.0.0",
      "build_flavor" : "default",
      "build_type" : "tar",
      "build_hash" : "a30e8c2"
    }
  }
}

[mark-vieira]

@rjernst do we have any plans to change the behavior of this endpoint?

[elasticsearchmachine]

Pinging @elastic/es-core-infra (Team:Core/Infra)

[elasticsearchmachine]

Pinging @elastic/es-delivery (Team:Delivery)

[rjernst]

We don't have any plans to make this change. It would be quite invasive on existing callers of the node info API. If we were to add it, it would be in a new field, but as noted earlier, we intentionally omit the qualifier since it should not be used for compatibility comparisons.

[mark-vieira]

Sounds like this is not planned to change then so I'm closing this issue.