honeymoose/OpenSearch
1
0
Fork 0
mirror of https://github.com/honeymoose/OpenSearch.git synced 2025-02-17 02:14:54 +00:00
Code Issues Packages Projects Releases Wiki Activity

Update docs to refer to 6.8 instead of 6.7 (#43685)

Browse Source 
A few places in the documentation had mentioned 6.7 as the version to
upgrade from, when doing an upgrade to 7.0. While this is technically
possible, this commit will replace all those mentions to 6.8, as this is
the latest version with the latest bugfixes, deprecation checks and
ugprade assistant features - which should be the one used for upgrades.

Co-Authored-By: James Rodewig <james.rodewig@elastic.co>
This commit is contained in:
Alexander Reelsen 2019-07-02 09:06:14 +02:00
parent 1e8e85797d
commit ac7e1476a0
4 changed files with 12 additions and 12 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

14
docs/reference/mapping/removal_of_types.asciidoc
View File

@ -258,7 +258,7 @@ Elasticsearch 6.x::
* The `_default_` mapping type is deprecated.
* In 6.7, the index creation, index template, and mapping APIs support a query
* In 6.8, the index creation, index template, and mapping APIs support a query
string parameter (`include_type_name`) which indicates whether requests and
responses should include a type name. It defaults to `true`, and should be set
to an explicit value to prepare to upgrade to 7.0. Not setting `include_type_name`
@ -442,12 +442,12 @@ documents to it using typeless `index` calls, and load documents with typeless
Index creation, index template, and mapping APIs support a new `include_type_name`
URL parameter that specifies whether mapping definitions in requests and responses
should contain the type name. The parameter defaults to `true` in version 6.7 to
should contain the type name. The parameter defaults to `true` in version 6.8 to
match the pre-7.0 behavior of using type names in mappings. It defaults to `false`
in version 7.0 and will be removed in version 8.0.
It should be set explicitly in 6.7 to prepare to upgrade to 7.0. To avoid deprecation
warnings in 6.7, the parameter can be set to either `true` or `false`. In 7.0, setting
It should be set explicitly in 6.8 to prepare to upgrade to 7.0. To avoid deprecation
warnings in 6.8, the parameter can be set to either `true` or `false`. In 7.0, setting
`include_type_name` at all will result in a deprecation warning.
See some examples of interactions with Elasticsearch with this option set to `false`:
@ -717,12 +717,12 @@ indices.
[float]
==== Mixed-version clusters
In a cluster composed of both 6.7 and 7.0 nodes, the parameter
In a cluster composed of both 6.8 and 7.0 nodes, the parameter
`include_type_name` should be specified in indices APIs like index
creation. This is because the parameter has a different default between
6.7 and 7.0, so the same mapping definition will not be valid for both
6.8 and 7.0, so the same mapping definition will not be valid for both
node versions.
Typeless document APIs such as `bulk` and `update` are only available as of
7.0, and will not work with 6.7 nodes. This also holds true for the typeless
7.0, and will not work with 6.8 nodes. This also holds true for the typeless
versions of queries that perform document lookups, such as `terms`.

2
docs/reference/upgrade/cluster_restart.asciidoc
View File

@ -5,7 +5,7 @@ To upgrade directly to {es} {version} from versions 6.0-6.7, you must shut down
all nodes in the cluster, upgrade each node to {version}, and restart the cluster.
NOTE: If you are running a version prior to 6.0,
https://www.elastic.co/guide/en/elastic-stack/6.8/upgrading-elastic-stack.html[upgrade to 6.8]
{stack-ref-68}/upgrading-elastic-stack.html[upgrade to 6.8]
and reindex your old indices or bring up a new {version} cluster and
<<reindex-upgrade-remote, reindex from remote>>.

6
docs/reference/upgrade/reindex_upgrade.asciidoc
View File

@ -36,7 +36,7 @@ been deleted.
[[reindex-upgrade-inplace]]
=== Reindex in place
You can use the Upgrade Assistant in {kib} 6.7 to automatically reindex 5.x
You can use the Upgrade Assistant in {kib} 6.8 to automatically reindex 5.x
indices you need to carry forward to {version}.
To manually reindex your old indices in place:
@ -103,7 +103,7 @@ endif::include-xpack[]
You can use <<reindex-from-remote,reindex from remote>> to migrate indices from
your old cluster to a new {version} cluster. This enables you move to {version}
from a pre-6.7 cluster without interrupting service.
from a pre-6.8 cluster without interrupting service.
[WARNING]
=============================================
@ -196,4 +196,4 @@ monitor progress of the reindex job with the <<tasks,task API>>:
`30s` and `1`).
.. Once reindexing is complete and the status of the new index is `green`,
you can delete the old index.
you can delete the old index.

2
docs/reference/upgrade/rolling_upgrade.asciidoc
View File

@ -10,7 +10,7 @@ running the older version.
Rolling upgrades are supported:
* Between minor versions
* https://www.elastic.co/guide/en/elastic-stack/6.8/upgrading-elastic-stack.html[From 5.6 to 6.8]
* {stack-ref-68}/upgrading-elastic-stack.html[From 5.6 to 6.8]
* From 6.8 to {version}
Upgrading directly to {version} from 6.7 or earlier requires a