Converted all [IMPORTANT] to another annotation type

Author: clintongormley

050_Search/10_Multi_index_multi_type.asciidoc

@@ -49,7 +49,7 @@ request to a primary or replica of every shard in that index, then gathers the
 results from each shard. Searching within multiple indices works in exactly
 the same way -- there are just more shards involved.
 
-[IMPORTANT]
+[TIP]
 ================================================
 
 Searching one index which has 5 primary shards is *exactly equivalent* to

052_Mapping_Analysis/35_Inverted_index.asciidoc

@@ -106,7 +106,7 @@ we apply the same normalization rules that we used on the `content` field to
 our query string, it would become a query for `"+quick +fox"`, which would
 match both documents!
 
-IMPORTANT: This is very important. You can only find terms that actually exist in your
+NOTE: This is very important. You can only find terms that actually exist in your
 index, so: *both the indexed text and the query string must be normalized
 into the same form*.
 

052_Mapping_Analysis/45_Mapping.asciidoc

@@ -203,7 +203,7 @@ You can specify the mapping for a type when you first create an index.
 Alternatively, you can add the mapping for a new type (or update the mapping
 for an existing type) later, using the `/_mapping` endpoint.
 
-[IMPORTANT]
+[NOTE]
 ================================================
 While you can *add* to an existing mapping, you can't *change* it.  If a field
 already exists in the mapping, then it probably means that data from that

056_Sorting/90_What_is_relevance.asciidoc

@@ -147,7 +147,7 @@ sub-calculations that were required:
 <3> Inverse document frequency
 <4> Field length norm
 
-IMPORTANT: Producing the `explain` output is expensive. It is a debugging tool
+WARNING: Producing the `explain` output is expensive. It is a debugging tool
 only -- don't leave it turned on in production.
 
 The first part is the summary of the calculation. It tells us that it has

056_Sorting/95_Fielddata.asciidoc

@@ -20,7 +20,7 @@ In order to make sorting efficient, Elasticsearch loads all of the values for
 the field that you want to sort on into memory. This is referred to as
 _fielddata_.
 
-IMPORTANT: It doesn't just load the values for the documents that matched a
+WARNING: It doesn't just load the values for the documents that matched a
 particular query. It loads the values from *every document in your index*,
 regardless of the document `type`.
 

060_Distributed_Search/20_Scan_and_scroll.asciidoc

@@ -69,7 +69,7 @@ documents.  When scanning, the `size` is applied to each shard, so you will
 get back a maximum of `size * number_of_primary_shards` documents in each
 batch.
 
-IMPORTANT: The scroll request also returns  a *new `_scroll_id`*.  Every time
+NOTE: The scroll request also returns  a *new `_scroll_id`*.  Every time
 we make the next scroll request, we must pass the `_scroll_id` returned by the
 *previous* scroll request.
 

075_Inside_a_shard/40_Near_real_time.asciidoc

@@ -91,7 +91,7 @@ POST /my_logs/_settings
 <1> Disable automatic refreshes.
 <2> Refresh automatically every second.
 
-IMPORTANT: The `refresh_interval` expects a ``duration'' like `1s` (one
+CAUTION: The `refresh_interval` expects a ``duration'' like `1s` (one
 second) or `2m` (two minutes).  An absolute number like `1` means
 **1 millisecond**... a sure way to bring your cluster to its knees.
 

100_Full_Text_Search/35_Relevance_is_broken.asciidoc

@@ -49,7 +49,7 @@ search requests. The `dfs` stands for _Distributed Frequency Search_ and it
 tells Elasticsearch to first retrieve the local IDF from each shard in order
 to calculate the global IDF across the whole index.
 
-IMPORTANT: Don't use `dfs_query_then_fetch` in production.  It really isn't
+TIP: Don't use `dfs_query_then_fetch` in production.  It really isn't
 required. Just having enough data will ensure that your term frequencies are
 well distributed. There is no reason to add this extra DFS step to every query
 that you run.

110_Multi_Field_Search/45_Custom_all.asciidoc

@@ -42,7 +42,7 @@ With this mapping in place, we can query the `first_name` field for first
 names, the `last_name` field for last name, or the `full_name` field for first
 and last names.
 
-IMPORTANT: Mappings of the `first_name` and `last_name` fields have no bearing
+NOTE: Mappings of the `first_name` and `last_name` fields have no bearing
 on how the `full_name` field is indexed. The `full_name` field copies the
 string values from the other two fields, then indexes them according to the
 mapping of the `full_name` field only.

110_Multi_Field_Search/50_Cross_field.asciidoc

@@ -81,7 +81,7 @@ the `last_name` fields and uses the minimum of the two as the IDF for both
 fields.  The fact that `smith` is a common last name means that it will be
 treated as a common first name too.
 
-[IMPORTANT]
+[NOTE]
 ==================================================
 For the `cross_fields` query type to work optimally, all fields should have
 the same analyzer.  Fields which share an analyzer are grouped together as

130_Partial_Matching/15_WildcardRegexp.asciidoc

@@ -59,7 +59,7 @@ While prefix matching can be made more efficient by preparing your data at
 index time, wildcard and regular expression matching can only really be done
 at query time. These queries have their place, but should be used sparingly.
 
-[IMPORTANT]
+[CAUTION]
 =================================================
 
 The `prefix`, `wildcard` and `regexp` queries operate on terms. If you use

170_Relevance/15_Practical_scoring.asciidoc

@@ -204,7 +204,7 @@ than necessary, this field-level index-time boost is combined with the field
 length norm (see  <<field-norm>>) and stored in the index as a single byte.
 This is the value returned by `norm(t,d)` in the formula above.
 
-[IMPORTANT]
+[WARNING]
 =========================================
 
 We strongly recommend against using field-level index-time boosts for a few

170_Relevance/70_Pluggable_similarities.asciidoc

@@ -71,7 +71,7 @@ it considers each field separately by taking the average length of the field
 into account. It can distinguish between a short `title` field and a `long`
 title field.
 
-IMPORTANT: In <<query-time-boosting>> we said that the `title` field has a
+CAUTION: In <<query-time-boosting>> we said that the `title` field has a
 ``natural'' boost over the `body` field because of its length.  This natural
 boost disappears with BM25 as differences in field length only apply within a
 single field.

260_Synonyms/10_Intro.asciidoc

@@ -32,7 +32,7 @@ Synonyms appear to be a simple concept but they are quite tricky to get right.
 In this chapter will will explain the mechanics of using synonyms and discuss
 the limitations and gotchas.
 
-IMPORTANT: Synonyms are used to broaden the scope of what is considered a
+TIP: Synonyms are used to broaden the scope of what is considered a
 matching document.  Just like with <<stemming,stemming>> or
 <<partial-matching,partial matching>>, synonym fields should not be used
 alone but should be combined with a query on a ``main'' field which contains

260_Synonyms/20_Using_synonyms.asciidoc

@@ -66,11 +66,11 @@ Pos 5: (queen,monarch) <1>
 <1> All synonyms occupy the same position as the original term.
 
 A document like this will match queries for any of: ``English queen'',
-``British queen'', ``English monarch'' or ``British monarch''. 
+``British queen'', ``English monarch'' or ``British monarch''.
 Even a phrase query will work, because the position of
 each term has been preserved.
 
-[IMPORTANT]
+[TIP]
 .Index time vs search time
 ======================================
 

260_Synonyms/40_Expand_contract.asciidoc

@@ -5,7 +5,7 @@ In <<synonym-formats>> we have seen that it is possible to replace synonyms by
 _simple expansion_, _simple contraction_ or _generic expansion_.  We will look
 at the tradeoffs of each of these techniques below.
 
-IMPORTANT: This section deals with single-word synonyms only.  Multi-word
+TIP: This section deals with single-word synonyms only.  Multi-word
 synonyms add another layer of complexity and are discussed later in
 <<multi-word-synonyms>>.
 

310_Geopoints/20_Geopoints.asciidoc

@@ -63,7 +63,7 @@ PUT /attractions/restaurant/3
 <2> An object representation with `lat` and `lon` explicitly named.
 <3> An array representation with `[lon,lat]`.
 
-[IMPORTANT]
+[CAUTION]
 ========================
 
 Everybody gets caught at least once: string geo-points are

310_Geopoints/32_Bounding_box.asciidoc

@@ -97,7 +97,7 @@ GET /attractions/restaurant/_search
 <1> Setting the `type` parameter to `indexed` (instead of the default
     `memory`) tells Elasticsearch to use the inverted index for this filter.
 
-IMPORTANT: While a `geo_point` field can contain multiple geo-points, the
+CAUTION: While a `geo_point` field can contain multiple geo-points, the
 `lat_lon` optimization can only be used on fields which contain a single
 geo-point.
 

340_Geoshapes/74_Indexing_geo_shapes.asciidoc

@@ -6,7 +6,7 @@ standard for encoding two dimensional shapes in JSON.  Each shape definition
 contains the type of shape --  `point`, `line`, `polygon`, `envelope`, etc. --
 and one or more arrays of longitude/latitude points.
 
-IMPORTANT: In GeoJSON, coordinates are always written as *longitude*  followed
+CAUTION: In GeoJSON, coordinates are always written as *longitude*  followed
 by *latitude*.
 
 For instance, we can index a polygon representing Dam Square in Amsterdam as

404_Parent_Child/45_Indexing_parent_child.asciidoc

@@ -64,7 +64,7 @@ POST /company/employee/_bulk
 { "name": "Adrien Grand", "dob": "1987-05-11", "hobby": "horses" }
 -------------------------
 
-IMPORTANT: If you want to change the `parent` value of a child document, it is
+WARNING: If you want to change the `parent` value of a child document, it is
 not sufficient to just reindex or update the child document -- the new parent
 document may be on a different shard. Instead, you must first delete the old
 child, then index the new child.

410_Scaling/40_Multiple_indices.asciidoc

@@ -7,7 +7,7 @@ copy (a primary or a replica) of all the shards in an index.  If we issue the
 same search request on multiple indices, the exact same thing happens -- there
 are just more shards involved.
 
-IMPORTANT: Searching 1 index of 50 shards is exactly equivalent to searching
+TIP: Searching 1 index of 50 shards is exactly equivalent to searching
 50 indices with 1 shard each: both search requests hit 50 shards.
 
 This can be a useful fact to remember when you need to add capacity on the

510_Deployment/40_config.asciidoc

@@ -5,7 +5,7 @@ the settings alone.  We have witnessed countless dozens of clusters ruined
 by errant settings because the administrator thought they could turn a knob
 and gain 100x improvement.
 
-[IMPORTANT]
+[NOTE]
 ====
 Please read this entire section!  All configurations presented are equally
 important, and are not listed in any particular "importance" order.  Please read
@@ -79,7 +79,7 @@ path.logs: /path/to/logs
 path.plugins: /path/to/plugins
 ----
 <1> Notice that you can specify more than one directory for data using comma
-separated lists.  
+separated lists.
 
 Data can be saved to multiple directories, and if each of these directories
 are mounted on a different hard drive, this is a simple and effective way to
@@ -94,15 +94,15 @@ where two masters exist in a single cluster.
 
 When you have a split-brain, your cluster is at danger of losing data.  Because
 the master is considered the "supreme ruler" of the cluster, it decides
-when new indices can be created, how shards are moved, etc.  If you have _two_ 
+when new indices can be created, how shards are moved, etc.  If you have _two_
 masters, data integrity becomes perilous, since you have two different nodes
 that think they are in charge.
 
 This setting tells Elasticsearch to not elect a master unless there are enough
 master-eligible nodes available.  Only then will an election take place.
 
 This setting should always be configured to a quorum (majority) of your master-
-eligible nodes.  A quorum is `(number of master-eligible nodes / 2) + 1`.  
+eligible nodes.  A quorum is `(number of master-eligible nodes / 2) + 1`.
 Some examples:
 
 - If you have ten regular nodes (can hold data, can become master), a quorum is
@@ -147,31 +147,31 @@ remove master-eligible nodes.
 ==== Recovery settings
 
 There are several settings which affect the behavior of shard recovery when
-your cluster restarts.  First, we need to understand what happens if nothing is 
+your cluster restarts.  First, we need to understand what happens if nothing is
 configured.
 
 Imagine you have 10 nodes, and each node holds a single shard -- either a primary
 or a replica -- in a 5 primary / 1 replica index.  You take your
-entire cluster offline for maintenance (installing new drives, etc).  When you 
+entire cluster offline for maintenance (installing new drives, etc).  When you
 restart your cluster, it just so happens that five nodes come online before
-the other five.  
+the other five.
 
 Maybe the switch to the other five is being flaky and they didn't
-receive the restart command right away.  Whatever the reason, you have five nodes 
-online.  These five nodes will gossip with eachother, elect a master and form a 
+receive the restart command right away.  Whatever the reason, you have five nodes
+online.  These five nodes will gossip with eachother, elect a master and form a
 cluster.  They notice that data is no longer evenly distributed since five
 nodes are missing from the cluster, and immediately start replicating new
 shards between each other.
 
 Finally, your other five nodes turn on and join the cluster.  These nodes see
-that _their_ data is being replicated to other nodes, so they delete their local 
+that _their_ data is being replicated to other nodes, so they delete their local
 data (since it is now redundant, and may be out-dated).  Then the cluster starts
 to rebalance even more, since the cluster size just went from five to 10.
 
 During this whole process, your nodes are thrashing the disk and network moving
-data around...for no good reason. For large clusters with terrabytes of data, 
-this useless shuffling of data can take a _really long time_.  If all the nodes 
-had simply waited for the cluster to come online, all the data would have been 
+data around...for no good reason. For large clusters with terrabytes of data,
+this useless shuffling of data can take a _really long time_.  If all the nodes
+had simply waited for the cluster to come online, all the data would have been
 local and nothing would need to move.
 
 Now that we know the problem, we can configure a few settings to alleviate it.
@@ -220,9 +220,9 @@ a few nodes on and they automatically find each other and form a cluster.
 
 This ease of use is the exact reason you should disable it in production.  The
 last thing you want is for nodes to accidentally join your production network, simply
-because they received an errant multicast ping.  There is nothing wrong with 
+because they received an errant multicast ping.  There is nothing wrong with
 multicast _per-se_.  Multicast simply leads to silly problems, and can be a bit
-more fragile (e.g. a network engineer fiddles with the network without telling 
+more fragile (e.g. a network engineer fiddles with the network without telling
 you...and all of a sudden nodes can't find each other anymore).
 
 In production, it is recommended to use Unicast instead of Multicast.  This works