fixed typo

added data streams

.gitignore

@@ -4,3 +4,4 @@ _site
 .DS_Store
 Gemfile.lock
 .idea
+.jekyll-cache

_clients/java-rest-high-level.md

@@ -0,0 +1,124 @@
+---
+layout: default
+title: Java high-level REST client
+nav_order: 97
+---
+
+# Java high-level REST client
+
+The Elasticsearch OSS Java high-level REST client allows you to interact with your OpenSearch clusters and indices through Java methods and data structures rather than HTTP methods and JSON.
+
+You submit requests to your cluster using request objects, which allows you to create indices, add data to documents, or complete other operations with your cluster. In return, you get back response objects that have all of the available information, such as the associated index or ID, from your cluster.
+
+## Setup
+
+To start using the Elasticsearch OSS Java high-level REST client, ensure that you have the following dependency in your project's `pom.xml` file:
+
+```
+<dependency>
+  <groupId>org.elasticsearch.client</groupId>
+  <artifactId>elasticsearch-rest-high-level-client</artifactId>
+  <version>7.10.2</version>
+</dependency>
+```
+
+You can now start your OpenSearch cluster. The 7.10.2 high-level REST client works with the 1.x versions of OpenSearch.
+
+## Sample code
+
+```java
+import org.apache.http.HttpHost;
+import org.apache.http.auth.AuthScope;
+import org.apache.http.auth.UsernamePasswordCredentials;
+import org.apache.http.client.CredentialsProvider;
+import org.apache.http.impl.client.BasicCredentialsProvider;
+import org.apache.http.impl.nio.client.HttpAsyncClientBuilder;
+import org.elasticsearch.action.admin.indices.delete.DeleteIndexRequest;
+import org.elasticsearch.action.delete.DeleteRequest;
+import org.elasticsearch.action.delete.DeleteResponse;
+import org.elasticsearch.action.get.GetRequest;
+import org.elasticsearch.action.get.GetResponse;
+import org.elasticsearch.action.index.IndexRequest;
+import org.elasticsearch.action.index.IndexResponse;
+import org.elasticsearch.action.support.master.AcknowledgedResponse;
+import org.elasticsearch.client.RequestOptions;
+import org.elasticsearch.client.RestClient;
+import org.elasticsearch.client.RestClientBuilder;
+import org.elasticsearch.client.RestHighLevelClient;
+import org.elasticsearch.client.indices.CreateIndexRequest;
+import org.elasticsearch.client.indices.CreateIndexResponse;
+import org.elasticsearch.common.settings.Settings;
+import org.elasticsearch.common.xcontent.XContentType;
+
+import java.io.IOException;
+import java.util.HashMap;
+
+public class RESTClientSample {
+
+  public static void main(String[] args) throws IOException {
+
+    //Point to keystore with appropriate certificates for security.
+    System.setProperty("javax.net.ssl.trustStore", "/full/path/to/keystore");
+    System.setProperty("javax.net.ssl.trustStorePassword", password-to-keystore);
+
+    //Establish credentials to use basic authentication.
+    //Only for demo purposes. Do not specify your credentials in code.
+    final CredentialsProvider credentialsProvider = new BasicCredentialsProvider();
+
+    credentialsProvider.setCredentials(AuthScope.ANY,
+      new UsernamePasswordCredentials("admin", "admin"));
+
+    //Create a client.
+    RestClientBuilder builder = RestClient.builder(new HttpHost("localhost", 9200, "https"))
+      .setHttpClientConfigCallback(new RestClientBuilder.HttpClientConfigCallback() {
+        @Override
+        public HttpAsyncClientBuilder customizeHttpClient(HttpAsyncClientBuilder httpClientBuilder) {
+          return httpClientBuilder.setDefaultCredentialsProvider(credentialsProvider);
+            }
+          });
+    RestHighLevelClient client = new RestHighLevelClient(builder);
+
+    //Create a non-default index with custom settings and mappings.
+    CreateIndexRequest createIndexRequest = new CreateIndexRequest("test-index");
+
+    createIndexRequest.settings(Settings.builder() //Specify in the settings how many shards you want in the index.
+      .put("index.number_of_shards", 4)
+      .put("index.number_of_replicas", 3)
+      );
+    //Create a set of maps for the index's mappings.
+    HashMap<String, String> typeMapping = new HashMap<String,String>();
+    typeMapping.put("type", "integer");
+    HashMap<String, Object> ageMapping = new HashMap<String, Object>();
+    ageMapping.put("age", typeMapping);
+    HashMap<String, Object> mapping = new HashMap<String, Object>();
+    mapping.put("properties", ageMapping);
+    createIndexRequest.mapping(mapping);
+    CreateIndexResponse createIndexResponse = client.indices().create(createIndexRequest, RequestOptions.DEFAULT
+
+    //Adding data to the index.
+    IndexRequest request = new IndexRequest("custom-index"); //Add a document to the custom-index we created.
+    request.id("1"); //Assign an ID to the document.
+
+    HashMap<String, String> stringMapping = new HashMap<String, String>();
+    stringMapping.put("message:", "Testing Java REST client");
+    request.source(stringMapping); //Place your content into the index's source.
+    IndexResponse indexResponse = client.index(request, RequestOptions.DEFAULT);
+
+    //Getting back the document
+    GetRequest getRequest = new GetRequest("custom-index", "1");
+    GetResponse response = client.get(getRequest, RequestOptions.DEFAULT);
+
+    System.out.println(response.getSourceAsString());
+
+    //Delete the document
+    DeleteRequest deleteDocumentRequest = new DeleteRequest("custom-index", "1"); //Index name followed by the ID.
+    DeleteResponse deleteResponse = client.delete(deleteDocumentRequest, RequestOptions.DEFAULT);
+
+    //Delete the index
+    DeleteIndexRequest deleteIndexRequest = new DeleteIndexRequest("custom-index"); //Index name.
+    AcknowledgedResponse deleteIndexResponse = client.indices().delete(deleteIndexRequest, RequestOptions.DEFAULT);
+
+    client.close();
+  }
+}
+```

_dashboards/install/tls.md

@@ -0,0 +1,41 @@
+---
+layout: default
+title: Configure TLS
+parent: Install OpenSearch Dashboards
+nav_order: 40
+---
+
+# Configure TLS for OpenSearch Dashboards
+
+By default, for ease of testing and getting started, OpenSearch Dashboards runs over HTTP. To enable TLS for HTTPS, update the following settings in `opensearch_dashboards.yml`.
+
+Setting | Description
+:--- | :---
+opensearch.ssl.verificationMode | This setting is for communications between OpenSearch and OpenSearch Dashboards. Valid values are `full`, `certificate`, or `none`. We recommend `full` if you enable TLS, which enables hostname verification. `certificate` just checks the certificate, not the hostname, and `none` performs no checks (suitable for HTTP). Default is `full`.
+opensearch.ssl.certificateAuthorities | If `opensearch.ssl.verificationMode` is `full` or `certificate`, specify the full path (e.g. `[ "/usr/share/opensearch-dashboards-1.0.0/config/root-ca.pem" ]` to the certificate authority for your OpenSearch cluster.
+server.ssl.enabled | This setting is for communications between OpenSearch Dashboards and the web browser. Set to true for HTTPS, false for HTTP.
+server.ssl.certificate | If `server.ssl.enabled` is true, specify the full path (e.g. `/usr/share/opensearch-dashboards-1.0.0/config/my-client-cert.pem` to a valid client certificate for your OpenSearch cluster. You can [generate your own]({{site.url}}{{site.baseurl}}/security-plugin/configuration/generate-certificates/) or get one from a certificate authority.
+server.ssl.key | If `server.ssl.enabled` is true, specify the full path (e.g. `/usr/share/opensearch-dashboards-1.0.0/config/my-client-cert-key.pem` to the key for your client certificate. You can [generate your own]({{site.url}}{{site.baseurl}}/security-plugin/configuration/generate-certificates/) or get one from a certificate authority.
+opensearch_security.cookie.secure | If you enable TLS for OpenSearch Dashboards, change this setting to `true`. For HTTP, set it to `false`.
+
+This `opensearch_dashboards.yml` configuration shows OpenSearch and OpenSearch Dashboards running on the same machine with the demo configuration:
+
+```yml
+opensearch.hosts: ["https://localhost:9200"]
+opensearch.ssl.verificationMode: full
+opensearch.username: "kibanaserver"
+opensearch.password: "kibanaserver"
+opensearch.requestHeadersWhitelist: [ authorization,securitytenant ]
+server.ssl.enabled: true
+server.ssl.certificate: /usr/share/opensearch-1.0.0/config/client-cert.pem
+server.ssl.key: /usr/share/opensearch-1.0.0/config/client-cert-key.pem
+opensearch.ssl.certificateAuthorities: [ "/usr/share/opensearch-1.0.0/config/root-ca.pem" ]
+opensearch_security.multitenancy.enabled: true
+opensearch_security.multitenancy.tenants.preferred: ["Private", "Global"]
+opensearch_security.readonly_mode.roles: ["kibana_read_only"]
+opensearch_security.cookie.secure: true
+```
+
+If you use the Docker install, you can pass a custom `opensearch_dashboards.yml` to the container. To learn more, see the [Docker installation page]({{site.url}}{{site.baseurl}}/opensearch/install/docker/).
+
+After enabling these settings and starting OpenSearch Dashboards, you can connect to it at `https://localhost:5601`. You might have to acknowledge a browser warning if your certificates are self-signed. To avoid this sort of warning (or outright browser incompatibility), best practice is to use certificates from trusted certificate authority.

_opensearch/aggregations.md

@@ -1,7 +1,7 @@
 ---
 layout: default
 title: Aggregations
-nav_order: 13
+nav_order: 14
 has_children: true
 ---
 

_opensearch/data-streams.md

@@ -0,0 +1,301 @@
+---
+layout: default
+title: Data streams
+nav_order: 13
+---
+
+# Data streams
+
+If you're ingesting continuously generated time-series data such as logs, events, and metrics into OpenSearch, you're likely in a scenario where:
+
+- You’re ingesting documents that grow rapidly.
+- You don’t need to update older documents.
+- Your searches generally target the newer documents.
+
+A typical workflow to manage time-series data is as follows:
+
+- To split your data into an index for each day, use the rollover operation.
+- To perform searches on a virtual index name that gets expanded to the underlying indices, create an [index alias]({{site.url}}{{site.baseurl}}/opensearch/index-alias/).
+- To perform a write operation on an index alias, configure the latest index as the write index.
+- To configure new indices, extract common mappings and settings into an [index template]({{site.url}}{{site.baseurl}}/opensearch/index-templates/).
+
+Even after you perform all these operations, you’re still not enforcing the best practices when dealing with time-series data. For example, you can modify the indices directly. You’re able to ingest documents without a timestamp field, which might result in slower queries.
+
+Data streams abstract the complexity and enforce the best practices for managing time-series data.
+
+With data streams, you can store append-only time-series data across multiple indices with a single endpoint for ingesting and searching data. It replaces index aliases for time-series data.
+
+## About data streams
+
+A data stream consists of one or more hidden auto-generated backing indices. These backing indices are named using the following convention:
+
+```
+.ds-<data-stream-name>-<generation-id>
+```
+
+For example, `.ds-logs-redis-000003`, where generation-id is a six-digit, zero-padded integer that acts as a cumulative count of the data stream’s rollovers, starting at `000001`.
+
+The most recently created backing index is the data stream’s write index. You can’t add documents directly to any of the backing indices. You can only add them via the data stream handle:
+
+![data stream indexing diagram]({{site.url}}{{site.baseurl}}/images/data_stream_indexing.png)
+
+The data stream routes search requests to all of its backing indices. It uses the timestamp field to intelligently route search requests to the right set of indices and shards:
+
+![data stream indexing diagram]({{site.url}}{{site.baseurl}}/images/data_stream_searching.png)
+
+The following operations are not supported on the write index because they might hinder the indexing operation:
+
+- close
+- clone
+- delete
+- shrink
+- split
+
+## Get started with data streams
+
+### Step 1: Create an index template
+
+To create a data stream, you first need to create an index template that configures a set of indices as a data stream. The `data_stream` object indicates that it’s a data stream and not a regular index template. The index pattern matches with the name of the data stream:
+
+```json
+PUT _index_template/logs-template
+{
+  "index_patterns": [
+    "my-data-stream",
+    "logs-*"
+  ],
+  "data_stream": {},
+  "priority": 100
+}
+```
+
+In this case, each ingested document must have an `@timestamp` field.
+You also have the ability to define your own custom timestamp field as a property in the `data_stream` object. You can also add index mappings and other settings here, just as you would for a regular index template.
+
+```json
+PUT _index_template/logs-template-nginx
+{
+  "index_patterns": "logs-nginx",
+  "data_stream": {
+    "timestamp_field": {
+      "name": "request_time"
+    }
+  },
+  "priority": 200,
+  "template": {
+    "settings": {
+      "number_of_shards": 1,
+      "number_of_replicas": 0
+    }
+  }
+}
+```
+
+In this case, `logs-nginx` index matches both the `logs-template` and `logs-template-nginx` templates. When you have a tie, OpenSearch selects the matching index template with the higher priority value.
+
+### Step 2: Create a data stream
+
+After you create an index template, you can create a data stream.
+You can use the data stream API to explicitly create a data stream. The data stream API initializes the first backing index:
+
+```json
+PUT _data_stream/logs-redis
+PUT _data_stream/logs-nginx
+```
+
+You can also directly start ingesting data without creating a data stream.
+
+Because we have a matching index template with a data_stream object, OpenSearch automatically creates the data stream:
+
+```json
+POST logs-staging/_doc
+{
+  "message": "login attempt failed",
+  "@timestamp": "2013-03-01T00:00:00"
+}
+```
+
+To see information about a specific data stream:
+
+```json
+GET _data_stream/logs-nginx
+```
+
+#### Sample response
+
+```json
+{
+  "data_streams" : [
+    {
+      "name" : "logs-nginx",
+      "timestamp_field" : {
+        "name" : "request_time"
+      },
+      "indices" : [
+        {
+          "index_name" : ".ds-logs-nginx-000001",
+          "index_uuid" : "-VhmuhrQQ6ipYCmBhn6vLw"
+        }
+      ],
+      "generation" : 1,
+      "status" : "GREEN",
+      "template" : "logs-template-nginx"
+    }
+  ]
+}
+```
+
+You can see the name of the timestamp field, the list of the backing indices, and the template that's used to create the data stream. You can also see the health of the data stream, which represents the lowest status of all its backing indices.
+
+To see more insights about the data stream, use the `_stats` endpoint:
+
+```json
+GET _data_stream/logs-nginx/_stats
+```
+
+#### Sample response
+
+```json
+{
+  "_shards" : {
+    "total" : 1,
+    "successful" : 1,
+    "failed" : 0
+  },
+  "data_stream_count" : 1,
+  "backing_indices" : 1,
+  "total_store_size_bytes" : 208,
+  "data_streams" : [
+    {
+      "data_stream" : "logs-nginx",
+      "backing_indices" : 1,
+      "store_size_bytes" : 208,
+      "maximum_timestamp" : 0
+    }
+  ]
+}
+```
+
+### Step 3: Ingest data into the data stream
+
+To ingest data into a data stream, you can use the regular indexing APIs. Make sure every document that you index has a timestamp field. If you try to ingest a document that doesn't have a timestamp field, you get an error.
+
+```json
+POST logs-redis/_doc
+{
+  "message": "login attempt",
+  "@timestamp": "2013-03-01T00:00:00"
+}
+```
+
+### Step 4: Searching a data stream
+
+You can search a data stream just like you search a regular index or an index alias.
+The search operation applies to all of the backing indices (all data present in the stream).
+
+```json
+GET logs-redis/_search
+{
+  "query": {
+    "match": {
+      "message": "login"
+    }
+  }
+}
+```
+
+#### Sample response
+
+```json
+{
+  "took" : 514,
+  "timed_out" : false,
+  "_shards" : {
+    "total" : 5,
+    "successful" : 5,
+    "skipped" : 0,
+    "failed" : 0
+  },
+  "hits" : {
+    "total" : {
+      "value" : 1,
+      "relation" : "eq"
+    },
+    "max_score" : 0.2876821,
+    "hits" : [
+      {
+        "_index" : ".ds-logs-redis-000001",
+        "_type" : "_doc",
+        "_id" : "-rhVmXoBL6BAVWH3mMpC",
+        "_score" : 0.2876821,
+        "_source" : {
+          "message" : "login attempt",
+          "@timestamp" : "2013-03-01T00:00:00"
+        }
+      }
+    ]
+  }
+}
+```
+
+### Step 5: Rollover a data stream
+
+A rollover operation creates a new backing index that becomes the data stream’s new write index.
+
+To perform manual rollover operation on the data stream:
+
+```json
+POST logs-redis/_rollover
+```
+
+#### Sample response
+
+```json
+{
+  "acknowledged" : true,
+  "shards_acknowledged" : true,
+  "old_index" : ".ds-logs-redis-000001",
+  "new_index" : ".ds-logs-redis-000002",
+  "rolled_over" : true,
+  "dry_run" : false,
+  "conditions" : { }
+}
+```
+
+If you now perform a `GET` operation on the `logs-redis` data stream, you see that the generation ID is incremented from 1 to 2.
+
+You can also set up an [Index State Management (ISM) policy]({{site.url}}{{site.baseurl}}/ism/policies/) to automate the rollover process for the data stream.  
+The ISM policy is applied to the backing indices at the time of their creation. When you associate a policy to a data stream, it only affects the future backing indices of that data stream.
+
+You also don’t need to provide the `rollover_alias` setting, because the ISM policy infers this information from the backing index.
+
+### Step 6: Manage data streams in OpenSearch Dashboards
+
+To manage data streams from OpenSearch Dashboards, open **OpenSearch Dashboards**, choose **Index Management**, select **Indices** or **Policy managed indices**.
+
+You see a toggle switch for data streams that you can use to show or hide indices belonging to a data stream.
+
+When you enable this switch, you see a data stream multi-select dropdown menu that you can use for filtering data streams.
+You also see a data stream column that shows you the name of the parent data stream the index is contained in.
+
+![data stream toggle]({{site.url}}{{site.baseurl}}/images/data_streams_toggle.png)
+
+You can select one or more data streams and apply an ISM policy on them. You can also apply a policy on any individual backing index.
+
+You can performing visualizations on a data stream just like you would on a regular index or index alias.
+
+### Step 7: Delete a data stream
+
+The delete operation first deletes the backing indices of a data stream and then deletes the data stream itself.
+
+To delete a data stream and all of its hidden backing indices:
+
+```json
+DELETE _data_stream/<name_of_data_stream>
+```
+
+You can use wildcards to delete more than one data stream.
+
+We recommend deleting data from a data stream using an ISM policy.
+
+You can also use [asynchronous search]({{site.url}}{{site.baseurl}}/async/index/) and [SQL]({{site.url}}{{site.baseurl}}/sql/index/) and [PPL]({{site.url}}{{site.baseurl}}/ppl/index/) to query your data stream directly. You can also use the security plugin to define granular permissions on the data stream name.

_opensearch/index-templates.md

@@ -1,7 +1,7 @@
 ---
 layout: default
 title: Index templates
-nav_order: 14
+nav_order: 15
 ---
 
 # Index templates

_opensearch/install/compatibility.md

@@ -0,0 +1,19 @@
+---
+layout: default
+title: Compatibility
+parent: Install OpenSearch
+nav_order: 2
+---
+
+# Operating system and JVM compatibility
+
+- We recommend installing OpenSearch on RHEL- or Debian-based Linux distributions that use [systemd](https://en.wikipedia.org/wiki/Systemd), such as CentOS, Amazon Linux 2, and Ubuntu (LTS). OpenSearch should work on many Linux distributions, but we only test a handful.
+- The OpenSearch tarball ships with a compatible version of Java in the `jdk` directory. To find its version, run `./jdk/bin/java -version`. For example, the OpenSearch 1.0.0 tarball ships with Java 15 (non-LTS).
+
+{% comment %}`./jdk/bin/java -version` doesn't work on macOS with zsh at the moment, and I have no idea why. Maybe we need a macOS artifact. Regardless, the command works on Amazon Linux 2 with bash and presumably other distros. - aetter{% endcomment %}
+
+  To use a different Java installation, set the `OPENSEARCH_JAVA_HOME` environment variable to the Java install location. We recommend Java 11 (LTS), but OpenSearch also works with Java 8.
+
+OpenSearch version | Compatible Java versions | Recommended operating systems
+:--- | :--- | :---
+1.x | 8, 11 | Red Hat Enterprise Linux 7, 8; CentOS 7, 8; Amazon Linux 2; Ubuntu 16.04, 18.04, 20.04

_opensearch/install/docker.md

@@ -2,7 +2,7 @@
 layout: default
 title: Docker
 parent: Install OpenSearch
-nav_order: 1
+nav_order: 3
 ---
 
 # Docker image
@@ -16,7 +16,7 @@ docker pull opensearchproject/opensearch-dashboards:{{site.opensearch_version}}
 
 To check available versions, see [Docker Hub](https://hub.docker.com/u/opensearchproject).
 
-OpenSearch images use `centos:7` as the base image. If you run Docker locally, we recommend allowing Docker to use at least 4 GB of RAM in **Preferences** > **Resources**.
+OpenSearch images use `amazonlinux:2` as the base image. If you run Docker locally, set Docker to use at least 4 GB of RAM in **Preferences** > **Resources**.
 
 
 ---

_opensearch/logs.md

@@ -11,7 +11,7 @@ The OpenSearch logs include valuable information for monitoring cluster operatio
 - On Docker, OpenSearch writes most logs to the console and stores the remainder in `opensearch/logs/`. The tarball installation also uses `opensearch/logs/`.
 - On most Linux installations, OpenSearch writes logs to `/var/log/opensearch/`.
 
-Logs are available as `.log` (plain text) and `.json` files.
+Logs are available as `.log` (plain text) and `.json` files. Permissions for the OpenSearch logs are `-rw-r--r--` by default, meaning that any user account on the node can read them. You can change this behavior _for each log type_ in `log4j2.properties` using the `filePermissions` option. For example, you might add `appender.rolling.filePermissions = rw-r-----` to change permissions for the JSON server log. For details, see the [Log4j 2 documentation](https://logging.apache.org/log4j/2.x/manual/appenders.html#RollingFileAppender).
 
 
 ## Application logs

_opensearch/rest-api/document-apis/bulk.md

@@ -1,8 +1,9 @@
 ---
 layout: default
 title: Bulk
-parent: REST API reference
-nav_order: 5
+parent: Document APIs
+grand_parent: REST API reference
+nav_order: 20
 ---
 
 # Bulk
@@ -32,7 +33,7 @@ POST _bulk
 POST {index}/_bulk
 ```
 
-Specifying the index in the path means you don't need to include it in the [request body](#request-body).
+Specifying the index in the path means you don't need to include it in the [request body]({{site.url}}{{site.baseurl}}/opensearch/rest-api/document-apis/bulk/#request-body).
 
 OpenSearch also accepts PUT requests to the `_bulk` path, but we highly recommend using POST. The accepted usage of PUT---adding or replacing a single resource at a given path---doesn't make sense for bulk requests.
 {: .note }

_opensearch/rest-api/document-apis/get-documents.md

@@ -0,0 +1,77 @@
+---
+layout: default
+title: Get document
+parent: Document APIs
+grand_parent: REST API reference
+nav_order: 5
+---
+
+# Get document
+
+After adding a JSON document to your index, you can use the get document API operation to retrieve the document's information and data.
+
+## Example
+
+```json
+GET sample-index1/_doc/1
+```
+
+## Path and HTTP methods
+
+```
+GET <index>/_doc/<_id>
+HEAD <index>/_doc/<_id>
+```
+```
+GET <index>/_source/<_id>
+HEAD <index>/_source/<_id>
+```
+
+## URL parameters
+
+All get document URL parameters are optional.
+
+Parameter | Type | Description
+:--- | :--- | :---
+preference | string | Specifies a preference of which shard to retrieve results from. Available options are `_local`, which tells the operation to retrieve results from a locally allocated shard replica, and a custom string value assigned to a specific shard replica. By default, OpenSearch executes get document operations on random shards.
+realtime | boolean | Specifies whether the operation should run in realtime. If false, the operation waits for the index to refresh to analyze the source to retrieve data, which makes the operation near-realtime. Default is true.
+refresh | boolean | If true, OpenSearch refreshes shards to make the operation visible to searching. Default is false.
+routing | string | A value used to route the operation to a specific shard.
+stored_fields | boolean | If true, the operation retrieves document fields stored in the index rather than the document's `_source`. Default is false.
+_source | string | Whether to include the `_source` field in the response body. Default is true.
+_source_excludes | string | A comma-separated list of source fields to exclude in the query response.
+_source_includes | string | A comma-separated list of source fields to include in the query response.
+version | integer | The version of the document to return, which must match the current version of the document.
+version_type | enum | Retrieves a specifically typed document. Available options are `external` (retrieve the document if the specified version number is greater than the document's current version) and `external_gte` (retrieve the document if the specified version number is greater than or equal to the document's current verison). For example, to retrieve version 3 of a document, use `/_doc/1?version=3&version_type=external`.
+
+
+## Response
+```json
+{
+  "_index": "sample-index1",
+  "_type": "_doc",
+  "_id": "1",
+  "_version": 1,
+  "_seq_no": 0,
+  "_primary_term": 9,
+  "found": true,
+  "_source": {
+    "text": "This is just some sample text."
+  }
+}
+```
+
+## Response body fields
+
+Field | Description
+:--- | :---
+_index | The name of the index.
+_type | The document's type. OpenSearch only supports one type, which is `_doc`.
+_id | The document's id.
+_version | The document's version number. Updated whenever the document changes.
+_seq_no | The sequnce number assigned when the document is indexed.
+primary_term | The primary term assigned when the document is indexed.
+found | Whether the document exists.
+_routing | The shard that the document is routed to. If the document is not routed to a particular shard, this field is omitted.
+_source | Contains the document's data if `found` is true. If `_source` is set to false or `stored_fields` is set to true in the URL parameters, this field is omitted.
+_fields | Contains the document's data that's stored in the index. Only returned if both `stored_fields` and `found` are true.

_opensearch/rest-api/document-apis/index.md

@@ -0,0 +1,28 @@
+---
+layout: default
+title: Document APIs
+parent: REST API reference
+has_children: true
+nav_order: 7
+---
+
+# Document APIs
+
+The document APIs allow you to handle documents relative to your index, such as adding, updating, and deleting documents.
+
+Document APIs are separated into two categories: single document operations and multi-document operations. Multi-document operations offer performance advantages over submitting many individual requests, so whenever practical, we recommend that you use multi-document operations.
+
+## Single document operations
+
+- Index
+- Get
+- Delete
+- Update
+
+## Multi-document operations
+
+- Bulk
+- Multi get
+- Delete by query
+- Update by query
+- Reindex

_security-plugin/configuration/index.md

@@ -13,12 +13,13 @@ redirect_from:
 
 The plugin includes demo certificates so that you can get up and running quickly, but before using OpenSearch in a production environment, you must configure it manually:
 
-1. [Replace the demo certificates]({{site.url}}{{site.baseurl}}/opensearch/install/docker-security)
-1. [Reconfigure opensearch.yml to use your certificates]({{site.url}}{{site.baseurl}}/security-plugin/configuration/tls)
-1. [Reconfigure config.yml to use your authentication backend]({{site.url}}{{site.baseurl}}/security-plugin/configuration/configuration/) (if you don't plan to use the internal user database)
-1. [Modify the configuration YAML files]({{site.url}}{{site.baseurl}}/security-plugin/configuration/yaml)
-1. [Apply changes using securityadmin.sh]({{site.url}}{{site.baseurl}}/security-plugin/configuration/security-admin)
+1. [Replace the demo certificates]({{site.url}}{{site.baseurl}}/opensearch/install/docker-security).
+1. [Reconfigure opensearch.yml to use your certificates]({{site.url}}{{site.baseurl}}/security-plugin/configuration/tls).
+1. [Reconfigure config.yml to use your authentication backend]({{site.url}}{{site.baseurl}}/security-plugin/configuration/configuration/) (if you don't plan to use the internal user database).
+1. [Modify the configuration YAML files]({{site.url}}{{site.baseurl}}/security-plugin/configuration/yaml).
+1. If you plan to use the internal user database, [set a password policy in opensearch.yml]({{site.url}}{{site.baseurl}}/security-plugin/configuration/yaml/#opensearchyml).
+1. [Apply changes using securityadmin.sh]({{site.url}}{{site.baseurl}}/security-plugin/configuration/security-admin).
 1. Start OpenSearch.
-1. [Add users, roles, role mappings, and tenants]({{site.url}}{{site.baseurl}}/security-plugin/access-control/index/)
+1. [Add users, roles, role mappings, and tenants]({{site.url}}{{site.baseurl}}/security-plugin/access-control/index/).
 
 If you don't want to use the plugin, see [Disable security]({{site.url}}{{site.baseurl}}/security-plugin/configuration/disable).

_security-plugin/configuration/yaml.md

@@ -89,6 +89,42 @@ snapshotrestore:
   description: "Demo snapshotrestore user"
 ```
 
+## opensearch.yml
+
+In addition to many OpenSearch settings, this file contains paths to TLS certificates and their attributes, such as distinguished names and trusted certificate authorities.
+
+```yml
+plugins.security.ssl.transport.pemcert_filepath: esnode.pem
+plugins.security.ssl.transport.pemkey_filepath: esnode-key.pem
+plugins.security.ssl.transport.pemtrustedcas_filepath: root-ca.pem
+plugins.security.ssl.transport.enforce_hostname_verification: false
+plugins.security.ssl.http.enabled: true
+plugins.security.ssl.http.pemcert_filepath: esnode.pem
+plugins.security.ssl.http.pemkey_filepath: esnode-key.pem
+plugins.security.ssl.http.pemtrustedcas_filepath: root-ca.pem
+plugins.security.allow_unsafe_democertificates: true
+plugins.security.allow_default_init_securityindex: true
+plugins.security.authcz.admin_dn:
+  - CN=kirk,OU=client,O=client,L=test, C=de
+
+plugins.security.audit.type: internal_opensearch
+plugins.security.enable_snapshot_restore_privilege: true
+plugins.security.check_snapshot_restore_write_privileges: true
+plugins.security.restapi.roles_enabled: ["all_access", "security_rest_api_access"]
+plugins.security.system_indices.enabled: true
+plugins.security.system_indices.indices: [".opendistro-alerting-config", ".opendistro-alerting-alert*", ".opendistro-anomaly-results*", ".opendistro-anomaly-detector*", ".opendistro-anomaly-checkpoints", ".opendistro-anomaly-detection-state", ".opendistro-reports-*", ".opendistro-notifications-*", ".opendistro-notebooks", ".opendistro-asynchronous-search-response*"]
+node.max_local_storage_nodes: 3
+```
+
+If you want to run your users' passwords against some validation, specify a regular expression (regex) in this file. You can also include an error message that loads when passwords don't pass validation. The following example demonstrates how to include a regex so OpenSearch requires new passwords to be a minimum of eight characters with at least one uppercase, one lowercase, one digit, and one special character.
+
+Note that OpenSearch validates only users and passwords created through OpenSearch Dashboards or the REST API.
+
+```yml
+plugins.restapi.password_validation_regex: '(?=.*[A-Z])(?=.*[^a-zA-Z\d])(?=.*[0-9])(?=.*[a-z]).{8,}'
+plugins.restapi.password_validation_error_message: "Password must be minimum 8 characters long and must contain at least one uppercase letter, one lowercase letter, one digit, and one special character."
+```
+
 
 ## roles.yml
 

_upgrade-to/dashboards-upgrade-to.md

@@ -0,0 +1,38 @@
+---
+layout: default
+title: Upgrade from Kibana OSS to OpenSearch Dashboards
+nav_order: 50
+redirect_from:
+  - /migrate/dashboards/
+---
+
+# Upgrade from Kibana OSS to OpenSearch Dashboards
+
+Kibana OSS stores its visualizations and dashboards in one or more indices (`.kibana*`) on the Elasticsearch OSS cluster. As such, the most important step is to leave those indices intact as you upgrade from Elasticsearch OSS to OpenSearch.
+
+Consider exporting all Kibana objects prior to starting the upgrade. In Kibana, choose **Stack Management**, **Saved Objects**, **Export objects**.
+{: .tip }
+
+1. After you upgrade your Elasticsearch OSS cluster to OpenSearch, stop Kibana.
+
+1. For safety, make a backup copy of `<kibana-dir>/config/kibana.yml`.
+
+1. Extract the OpenSearch Dashboards tarball to a new directory.
+
+1. Port your settings from `<kibana-dir>/config/kibana.yml` to `<dashboards-dir>/config/opensearch_dashboards.yml`.
+
+   In general, settings with `elasticsearch` in their names map to `opensearch` (e.g. `elasticsearch.shardTimeout` and `opensearch.shardTimeout`) and settings with `kibana` in their names map to `opensearchDashboards` (e.g. `kibana.defaultAppId` and `opensearchDashboards.defaultAppId`). Most other settings use the same names.
+
+   For a full list of OpenSearch Dashboards settings, see [here](https://github.com/opensearch-project/OpenSearch-Dashboards/blob/main/config/opensearch_dashboards.yml){:target='\_blank'}.
+
+1. If your OpenSearch cluster uses the security plugin, preserve and modify the default settings in `opensearch_dashboards.yml`, particularly `opensearch.username` and `opensearch.password`.
+
+   If you disabled the security plugin on your OpenSearch cluster, remove or comment out all `opensearch_security` settings. Then run `rm -rf plugins/security-dashboards/` to remove the security plugin.
+
+1. Start OpenSearch Dashboards:
+
+   ```
+   ./bin/opensearch-dashboards
+   ```
+
+1. Log in, and verify that your saved searches, visualizations, and dashboards are present.

index.md

@@ -37,7 +37,7 @@ Component | Purpose
 [Anomaly Detection]({{site.url}}{{site.baseurl}}/monitoring-plugins/ad/) | Identify atypical data and receive automatic notifications
 [Asynchronous Search]({{site.url}}{{site.baseurl}}/search-plugins/async/) | Run search requests in the background
 
-You can install OpenSearch plugins [individually]({{site.url}}{{site.baseurl}}/opensearch/install/plugins/) or use the [all-in-one packages]({{site.url}}{{site.baseurl}}/opensearch/install/). Most of these OpenSearch plugins have corresponding OpenSearch Dashboards plugins that provide a convenient, unified user interface.
+Most of OpenSearch plugins have a corresponding OpenSearch Dashboards plugin that provide a convenient, unified user interface.
 
 For specifics around the project, see the [FAQ](https://opensearch.org/faq/).
 
@@ -65,7 +65,10 @@ Docker
 To learn more, see [Install and configure OpenSearch]({{site.url}}{{site.baseurl}}/opensearch/install/) and [Install and configure OpenSearch Dashboards]({{site.url}}{{site.baseurl}}/dashboards/install/).
 
 
----
+## The secure path forward
+
+OpenSearch includes a demo configuration so that you can get up and running quickly, but before using OpenSearch in a production environment, you must [configure the security plugin manually]({{site.url}}{{site.baseurl}}/security-plugin/configuration/index/): your own certificates, your own authentication method, your own users, and your own passwords.
+
 
 ## Looking for the Javadoc?