From 2831535cf913ec4ee74acc98a78dd57c60e109d7 Mon Sep 17 00:00:00 2001 From: James Rodewig Date: Fri, 13 Sep 2019 11:23:53 -0400 Subject: [PATCH] [DOCS] Replace "// CONSOLE" comments with [source,console] (#46679) --- .../pipeline/movavg-aggregation.asciidoc | 27 +++++++------------ docs/reference/ilm/apis/slm-api.asciidoc | 3 +-- docs/reference/indices/templates.asciidoc | 1 - .../mapping/fields/field-names-field.asciidoc | 1 - .../migration/migrate_7_0/search.asciidoc | 4 +-- .../query-dsl/common-terms-query.asciidoc | 27 +++++++------------ docs/reference/query-dsl/match-query.asciidoc | 3 +-- docs/reference/query-dsl/type-query.asciidoc | 3 +-- .../sql/language/data-types.asciidoc | 2 +- .../transform/ecommerce-example.asciidoc | 9 +++---- .../security/role-mapping-resources.asciidoc | 2 +- .../authentication/user-cache.asciidoc | 4 +-- 12 files changed, 30 insertions(+), 56 deletions(-) diff --git a/docs/reference/aggregations/pipeline/movavg-aggregation.asciidoc b/docs/reference/aggregations/pipeline/movavg-aggregation.asciidoc index 3c5d5d0cff7..b91d14e513e 100644 --- a/docs/reference/aggregations/pipeline/movavg-aggregation.asciidoc +++ b/docs/reference/aggregations/pipeline/movavg-aggregation.asciidoc @@ -51,7 +51,7 @@ A `moving_avg` aggregation looks like this in isolation: `moving_avg` aggregations must be embedded inside of a `histogram` or `date_histogram` aggregation. They can be embedded like any other metric aggregation: -[source,js] +[source,console] -------------------------------------------------- POST /_search { @@ -74,7 +74,6 @@ POST /_search } } -------------------------------------------------- -// CONSOLE // TEST[setup:sales] // TEST[warning:The moving_avg aggregation has been deprecated in favor of the moving_fn aggregation.] @@ -154,7 +153,7 @@ The `simple` model calculates the sum of all values in the window, then divides a simple arithmetic mean of the window. The simple model does not perform any time-dependent weighting, which means the values from a `simple` moving average tend to "lag" behind the real data. -[source,js] +[source,console] -------------------------------------------------- POST /_search { @@ -181,7 +180,6 @@ POST /_search } } -------------------------------------------------- -// CONSOLE // TEST[setup:sales] // TEST[warning:The moving_avg aggregation has been deprecated in favor of the moving_fn aggregation.] @@ -208,7 +206,7 @@ The `linear` model assigns a linear weighting to points in the series, such that the beginning of the window) contribute a linearly less amount to the total average. The linear weighting helps reduce the "lag" behind the data's mean, since older points have less influence. -[source,js] +[source,console] -------------------------------------------------- POST /_search { @@ -235,7 +233,6 @@ POST /_search } } -------------------------------------------------- -// CONSOLE // TEST[setup:sales] // TEST[warning:The moving_avg aggregation has been deprecated in favor of the moving_fn aggregation.] @@ -268,7 +265,7 @@ The default value of `alpha` is `0.3`, and the setting accepts any float from 0- The EWMA model can be <> -[source,js] +[source,console] -------------------------------------------------- POST /_search { @@ -298,7 +295,6 @@ POST /_search } } -------------------------------------------------- -// CONSOLE // TEST[setup:sales] // TEST[warning:The moving_avg aggregation has been deprecated in favor of the moving_fn aggregation.] @@ -327,7 +323,7 @@ The default value of `alpha` is `0.3` and `beta` is `0.1`. The settings accept a The Holt-Linear model can be <> -[source,js] +[source,console] -------------------------------------------------- POST /_search { @@ -358,7 +354,6 @@ POST /_search } } -------------------------------------------------- -// CONSOLE // TEST[setup:sales] // TEST[warning:The moving_avg aggregation has been deprecated in favor of the moving_fn aggregation.] @@ -416,7 +411,7 @@ The default value of `period` is `1`. The additive Holt-Winters model can be <> -[source,js] +[source,console] -------------------------------------------------- POST /_search { @@ -450,7 +445,6 @@ POST /_search } } -------------------------------------------------- -// CONSOLE // TEST[setup:sales] // TEST[warning:The moving_avg aggregation has been deprecated in favor of the moving_fn aggregation.] @@ -477,7 +471,7 @@ the result, but only minimally. If your data is non-zero, or you prefer to see you can disable this behavior with `pad: false` ====== -[source,js] +[source,console] -------------------------------------------------- POST /_search { @@ -512,7 +506,6 @@ POST /_search } } -------------------------------------------------- -// CONSOLE // TEST[setup:sales] // TEST[warning:The moving_avg aggregation has been deprecated in favor of the moving_fn aggregation.] @@ -527,7 +520,7 @@ Predictions are enabled by adding a `predict` parameter to any moving average ag predictions you would like appended to the end of the series. These predictions will be spaced out at the same interval as your buckets: -[source,js] +[source,console] -------------------------------------------------- POST /_search { @@ -555,7 +548,6 @@ POST /_search } } -------------------------------------------------- -// CONSOLE // TEST[setup:sales] // TEST[warning:The moving_avg aggregation has been deprecated in favor of the moving_fn aggregation.] @@ -606,7 +598,7 @@ models. Minimization is enabled/disabled via the `minimize` parameter: -[source,js] +[source,console] -------------------------------------------------- POST /_search { @@ -637,7 +629,6 @@ POST /_search } } -------------------------------------------------- -// CONSOLE // TEST[setup:sales] // TEST[warning:The moving_avg aggregation has been deprecated in favor of the moving_fn aggregation.] diff --git a/docs/reference/ilm/apis/slm-api.asciidoc b/docs/reference/ilm/apis/slm-api.asciidoc index 0aa2f0307aa..51cbb0f8968 100644 --- a/docs/reference/ilm/apis/slm-api.asciidoc +++ b/docs/reference/ilm/apis/slm-api.asciidoc @@ -353,11 +353,10 @@ retrieved by using the following API: ==== Example -[source,js] +[source,console] -------------------------------------------------- GET /_slm/stats -------------------------------------------------- -// CONSOLE // TEST[continued] Which returns a response similar to: diff --git a/docs/reference/indices/templates.asciidoc b/docs/reference/indices/templates.asciidoc index fc0cba1ce36..0f33b21d013 100644 --- a/docs/reference/indices/templates.asciidoc +++ b/docs/reference/indices/templates.asciidoc @@ -248,4 +248,3 @@ The API returns the following response: } } -------------------------------------------------- -// TESTRESPONSE diff --git a/docs/reference/mapping/fields/field-names-field.asciidoc b/docs/reference/mapping/fields/field-names-field.asciidoc index cec9d8b0d37..5c03da1124f 100644 --- a/docs/reference/mapping/fields/field-names-field.asciidoc +++ b/docs/reference/mapping/fields/field-names-field.asciidoc @@ -33,5 +33,4 @@ PUT tweets } } -------------------------------------------------- -// CONSOLE // TEST[warning:Index [tweets] uses the deprecated `enabled` setting for `_field_names`. Disabling _field_names is not necessary because it no longer carries a large index overhead. Support for this setting will be removed in a future major version. Please remove it from your mappings and templates.] diff --git a/docs/reference/migration/migrate_7_0/search.asciidoc b/docs/reference/migration/migrate_7_0/search.asciidoc index 95aaab91fd8..a8daee32efb 100644 --- a/docs/reference/migration/migrate_7_0/search.asciidoc +++ b/docs/reference/migration/migrate_7_0/search.asciidoc @@ -65,7 +65,7 @@ Adaptive replica selection has been enabled by default. If you wish to return to the older round robin of search requests, you can use the `cluster.routing.use_adaptive_replica_selection` setting: -[source,js] +[source,console] -------------------------------------------------- PUT /_cluster/settings { @@ -74,7 +74,7 @@ PUT /_cluster/settings } } -------------------------------------------------- -// CONSOLE + [float] [[search-api-returns-400-invalid-requests]] diff --git a/docs/reference/query-dsl/common-terms-query.asciidoc b/docs/reference/query-dsl/common-terms-query.asciidoc index f2d784eb0c4..ff38af303b5 100644 --- a/docs/reference/query-dsl/common-terms-query.asciidoc +++ b/docs/reference/query-dsl/common-terms-query.asciidoc @@ -70,7 +70,7 @@ as stopwords without the need to maintain a manual list. In this example, words that have a document frequency greater than 0.1% (eg `"this"` and `"is"`) will be treated as _common terms_. -[source,js] +[source,console] -------------------------------------------------- GET /_search { @@ -84,7 +84,6 @@ GET /_search } } -------------------------------------------------- -// CONSOLE // TEST[warning:Deprecated field [common] used, replaced by [[match] query which can efficiently skip blocks of documents if the total number of hits is not tracked]] The number of terms which should match can be controlled with the @@ -95,7 +94,7 @@ The number of terms which should match can be controlled with the For low frequency terms, set the `low_freq_operator` to `"and"` to make all terms required: -[source,js] +[source,console] -------------------------------------------------- GET /_search { @@ -110,12 +109,11 @@ GET /_search } } -------------------------------------------------- -// CONSOLE // TEST[warning:Deprecated field [common] used, replaced by [[match] query which can efficiently skip blocks of documents if the total number of hits is not tracked]] which is roughly equivalent to: -[source,js] +[source,console] -------------------------------------------------- GET /_search { @@ -135,14 +133,13 @@ GET /_search } } -------------------------------------------------- -// CONSOLE Alternatively use <> to specify a minimum number or percentage of low frequency terms which must be present, for instance: -[source,js] +[source,console] -------------------------------------------------- GET /_search { @@ -157,12 +154,11 @@ GET /_search } } -------------------------------------------------- -// CONSOLE // TEST[warning:Deprecated field [common] used, replaced by [[match] query which can efficiently skip blocks of documents if the total number of hits is not tracked]] which is roughly equivalent to: -[source,js] +[source,console] -------------------------------------------------- GET /_search { @@ -187,7 +183,6 @@ GET /_search } } -------------------------------------------------- -// CONSOLE A different <> @@ -195,7 +190,7 @@ can be applied for low and high frequency terms with the additional `low_freq` and `high_freq` parameters. Here is an example when providing additional parameters (note the change in structure): -[source,js] +[source,console] -------------------------------------------------- GET /_search { @@ -213,12 +208,11 @@ GET /_search } } -------------------------------------------------- -// CONSOLE // TEST[warning:Deprecated field [common] used, replaced by [[match] query which can efficiently skip blocks of documents if the total number of hits is not tracked]] which is roughly equivalent to: -[source,js] +[source,console] -------------------------------------------------- GET /_search { @@ -249,7 +243,6 @@ GET /_search } } -------------------------------------------------- -// CONSOLE In this case it means the high frequency terms have only an impact on relevance when there are at least three of them. But the most @@ -257,7 +250,7 @@ interesting use of the <> for high frequency terms is when there are only high frequency terms: -[source,js] +[source,console] -------------------------------------------------- GET /_search { @@ -275,12 +268,11 @@ GET /_search } } -------------------------------------------------- -// CONSOLE // TEST[warning:Deprecated field [common] used, replaced by [[match] query which can efficiently skip blocks of documents if the total number of hits is not tracked]] which is roughly equivalent to: -[source,js] +[source,console] -------------------------------------------------- GET /_search { @@ -297,7 +289,6 @@ GET /_search } } -------------------------------------------------- -// CONSOLE The high frequency generated query is then slightly less restrictive than with an `AND`. diff --git a/docs/reference/query-dsl/match-query.asciidoc b/docs/reference/query-dsl/match-query.asciidoc index fc39b191ce3..5ceba4e61d9 100644 --- a/docs/reference/query-dsl/match-query.asciidoc +++ b/docs/reference/query-dsl/match-query.asciidoc @@ -279,7 +279,7 @@ documents if in the range `[0..1)` or absolute if greater or equal to Here is an example showing a query composed of stopwords exclusively: -[source,js] +[source,console] -------------------------------------------------- GET /_search { @@ -293,7 +293,6 @@ GET /_search } } -------------------------------------------------- -// CONSOLE // TEST[warning:Deprecated field [cutoff_frequency] used, replaced by [you can omit this option, the [match] query can skip block of documents efficiently if the total number of hits is not tracked]] IMPORTANT: The `cutoff_frequency` option operates on a per-shard-level. This means diff --git a/docs/reference/query-dsl/type-query.asciidoc b/docs/reference/query-dsl/type-query.asciidoc index 4364d1e14e9..82272968f91 100644 --- a/docs/reference/query-dsl/type-query.asciidoc +++ b/docs/reference/query-dsl/type-query.asciidoc @@ -5,7 +5,7 @@ deprecated[7.0.0,Types and the `type` query are deprecated and in the process of Filters documents matching the provided document / mapping type. -[source,js] +[source,console] -------------------------------------------------- GET /_search { @@ -16,4 +16,3 @@ GET /_search } } -------------------------------------------------- -// CONSOLE diff --git a/docs/reference/sql/language/data-types.asciidoc b/docs/reference/sql/language/data-types.asciidoc index 7c5b4db045f..ee73a1eea7c 100644 --- a/docs/reference/sql/language/data-types.asciidoc +++ b/docs/reference/sql/language/data-types.asciidoc @@ -102,7 +102,7 @@ To do that, it will search for the first `keyword` that it can find that is _not Consider the following `string` mapping: -[source, js] +[source,js] ---- { "first_name" : { diff --git a/docs/reference/transform/ecommerce-example.asciidoc b/docs/reference/transform/ecommerce-example.asciidoc index ce4193aa665..3404ee37758 100644 --- a/docs/reference/transform/ecommerce-example.asciidoc +++ b/docs/reference/transform/ecommerce-example.asciidoc @@ -83,7 +83,7 @@ If you want to use more complex queries, you can create your {dataframe} from a If you prefer, you can use the {ref}/preview-data-frame-transform.html[preview {dataframe-transforms} API]: -[source,js] +[source,console] -------------------------------------------------- POST _data_frame/transforms/_preview { @@ -130,7 +130,6 @@ POST _data_frame/transforms/_preview } } -------------------------------------------------- -// CONSOLE // TEST[skip:set up sample data] -- @@ -159,7 +158,7 @@ If you prefer, you can use the {ref}/put-data-frame-transform.html[create {dataframe-transforms} API]. For example: -[source,js] +[source,console] -------------------------------------------------- PUT _data_frame/transforms/ecommerce-customer-transform { @@ -213,7 +212,6 @@ PUT _data_frame/transforms/ecommerce-customer-transform } } -------------------------------------------------- -// CONSOLE // TEST[skip:setup kibana sample data] -- @@ -236,11 +234,10 @@ Alternatively, you can use the {ref}/stop-data-frame-transform.html[stop {dataframe-transforms}] APIs. For example: -[source,js] +[source,console] -------------------------------------------------- POST _data_frame/transforms/ecommerce-customer-transform/_start -------------------------------------------------- -// CONSOLE // TEST[skip:setup kibana sample data] -- diff --git a/x-pack/docs/en/rest-api/security/role-mapping-resources.asciidoc b/x-pack/docs/en/rest-api/security/role-mapping-resources.asciidoc index 1b41d89db0b..ad90bef063a 100644 --- a/x-pack/docs/en/rest-api/security/role-mapping-resources.asciidoc +++ b/x-pack/docs/en/rest-api/security/role-mapping-resources.asciidoc @@ -80,7 +80,7 @@ if _at least one_ of the member values matches. For example, the following rule matches any user who is a member of the `admin` group, regardless of any other groups they belong to: -[source, js] +[source,js] ------------------------------------------------------------ { "field" : { "groups" : "admin" } } ------------------------------------------------------------ diff --git a/x-pack/docs/en/security/authentication/user-cache.asciidoc b/x-pack/docs/en/security/authentication/user-cache.asciidoc index aa5cd1dc903..e92a49aa9b7 100644 --- a/x-pack/docs/en/security/authentication/user-cache.asciidoc +++ b/x-pack/docs/en/security/authentication/user-cache.asciidoc @@ -22,7 +22,7 @@ You can use the {ref}/security-api-clear-cache.html[clear cache API] to force the eviction of cached users . For example, the following request evicts all users from the `ad1` realm: -[source, js] +[source,js] ------------------------------------------------------------ $ curl -XPOST 'http://localhost:9200/_security/realm/ad1/_clear_cache' ------------------------------------------------------------ @@ -30,7 +30,7 @@ $ curl -XPOST 'http://localhost:9200/_security/realm/ad1/_clear_cache' To clear the cache for multiple realms, specify the realms as a comma-separated list: -[source, js] +[source,js] ------------------------------------------------------------ $ curl -XPOST 'http://localhost:9200/_security/realm/ad1,ad2/_clear_cache' ------------------------------------------------------------