updating upgrade notes for style and grammar

Signed-off-by: Lynette Miles <[email protected]>

Author: esmerel

installation/upgrade-notes.md

@@ -1,13 +1,19 @@
 # Upgrade Notes
 
-The following article cover the relevant notes for users upgrading from previous Fluent Bit versions. We aim to cover compatibility changes that you must be aware of.
+The following article cover the relevant notes for users upgrading from previous
+Fluent Bit versions. These aim to cover compatibility changes that you must be aware of.
 
-For more details about changes on each release please refer to the [Official Release Notes](https://fluentbit.io/announcements/).
+For more details about changes on each release, refer to the
+ [Official Release Notes](https://fluentbit.io/announcements/).
 
-Note: release notes will be prepared in advance of a Git tag for a release so an official release should provide both a tag and a release note together to allow users to verify and understand the release contents.
+Release notes will be prepared in advance of a Git tag for a release. An official
+release should provide both a tag and a release note together to allow users to
+verify and understand the release contents.
 
-The tag drives the overall binary release process so release binaries (containers/packages) will appear after a tag and its associated release note.
-This allows users to expect the new release binary to appear and allow/deny/update it as appropriate in their infrastructure.
+The tag drives the binary release process. Release binaries (containers and packages)
+will appear after a tag and its associated release note. This lets users to expect
+the new release binary to appear and allow/deny/update it as appropriate in their
+infrastructure.
 
 ## Fluent Bit v1.9.9
 
@@ -16,42 +22,63 @@ Users should switch to the `fluent-bit` package.
 
 ## Fluent Bit v1.6
 
-If you are migrating from previous version of Fluent Bit please review the following important changes:
+If you are migrating from previous version of Fluent Bit, review the following
+important changes:
 
 ### Tail Input Plugin
 
-Now by default the plugin follows a file from the end once the service starts \(old behavior was always read from the beginning\). For every file found at start, its followed from it last position, for new files discovered at runtime or rotated, they are read from the beginning.
+By default, the plugin follows a file from the end once the service starts, instead
+of reading from the beginning. Every file found at start is followed from it last
+position. New files discovered at runtime or rotated are read from the beginning.
 
-If you desire to keep the old behavior you can set the option `read_from_head` to true.
+To keep the old behavior, set the option `read_from_head` to true.
 
 ### Stackdriver Output Plugin
 
-The project\_id of [resource](https://cloud.google.com/logging/docs/reference/v2/rest/v2/MonitoredResource) in [LogEntry](https://cloud.google.com/logging/docs/reference/v2/rest/v2/LogEntry) sent to Google Cloud Logging would be set to the project ID rather than the project number. To learn the difference between Project ID and project number, see [this](https://cloud.google.com/resource-manager/docs/creating-managing-projects#before_you_begin) for more details.
+The `project_id` of
+[resource](https://cloud.google.com/logging/docs/reference/v2/rest/v2/MonitoredResource)
+in [LogEntry](https://cloud.google.com/logging/docs/reference/v2/rest/v2/LogEntry)
+sent to Google Cloud Logging would be set to the `project_id` rather than the project
+number. To learn the difference between Project ID and project number, see
+[Creating and managing projects](https://cloud.google.com/resource-manager/docs/creating-managing-projects#before_you_begin).
 
-If you have any existing queries based on the resource's project\_id, please update your query accordingly.
+If you have existing queries based on the resource's `project_id,` update your query accordingly.
 
 ## Fluent Bit v1.5
 
 The migration from v1.4 to v1.5 is pretty straightforward.
 
-* If you enabled `keepalive` mode in your configuration, note that this configuration property has been renamed to `net.keepalive`. Now all Network I/O keepalive is enabled by default, to learn more about this and other associated configuration properties read the [Networking Administration](https://docs.fluentbit.io/manual/administration/networking#tcp-keepalive) section.
-* If you use the Elasticsearch output plugin, note the default value of `type` [changed from `flb_type` to `_doc`](https://github.com/fluent/fluent-bit/commit/04ed3d8104ca8a2f491453777ae6e38e5377817e#diff-c9ae115d3acaceac5efb949edbb21196). Many versions of Elasticsearch will tolerate this, but ES v5.6 through v6.1 require a type _without_ a leading underscore. See the [Elasticsearch output plugin documentation FAQ entry](https://docs.fluentbit.io/manual/pipeline/outputs/elasticsearch#faq-underscore) for more.
+- If you enabled `keepalive` mode in your configuration, this configuration property
+  has been renamed to `net.keepalive`. Now all Network I/O keepalive is enabled by
+  default. To learn more about this and other associated configuration properties
+  read the
+  [Networking Administration](https://docs.fluentbit.io/manual/administration/networking#tcp-keepalive)
+  section.
+- If you use the Elasticsearch output plugin, note the default value of `type`
+  [changed from `flb_type` to `_doc`](https://github.com/fluent/fluent-bit/commit/04ed3d8104ca8a2f491453777ae6e38e5377817e#diff-c9ae115d3acaceac5efb949edbb21196).
+  Many versions of Elasticsearch tolerate this, but ES v5.6 through v6.1 require
+  a `type` without a leading underscore. See the
+  [Elasticsearch output plugin documentation FAQ entry](https://docs.fluentbit.io/manual/pipeline/outputs/elasticsearch#faq-underscore) for more.
 
 ## Fluent Bit v1.4
 
-If you are migrating from Fluent Bit v1.3, there are no breaking changes. Just new exciting features to enjoy :\)
+If you are migrating from Fluent Bit v1.3, there are no breaking changes, only new exciting features to enjoy :\)
 
 ## Fluent Bit v1.3
 
-If you are migrating from Fluent Bit v1.2 to v1.3, there are no breaking changes. If you are upgrading from an older version please review the incremental changes below.
+If you are migrating from Fluent Bit v1.2 to v1.3, there are no breaking changes.
+If you are upgrading from an older version, review the following incremental changes:
 
 ## Fluent Bit v1.2
 
 ### Docker, JSON, Parsers and Decoders
 
-On Fluent Bit v1.2 we have fixed many issues associated with JSON encoding and decoding, for hence when parsing Docker logs **is no longer necessary** to use decoders. The new Docker parser looks like this:
+Fluent Bit v1.2 fixed many issues associated with JSON encoding and decoding.
 
-```text
+For example, when parsing Docker logs it's no longer necessary** to use decoders. The
+new Docker parser looks like this:
+
+```python
 [PARSER]
     Name         docker
     Format       json
@@ -60,15 +87,17 @@ On Fluent Bit v1.2 we have fixed many issues associated with JSON encoding and d
     Time_Keep    On
 ```
 
-> Note: again, do not use decoders.
-
 ### Kubernetes Filter
 
-We have done improvements also on how Kubernetes Filter handle the stringified _log_ message. If the option _Merge\_Log_ is enabled, it will try to handle the log content as a JSON map, if so, it will add the keys to the root map.
+Fluent Bit made improvements to Kubernetes Filter handling of stringified `log`
+messages. If the `Merge_Log` option is enabled, it will try to handle the log content
+as a JSON map, if so, it will add the keys to the root map.
 
-In addition, we have fixed and improved the option called _Merge\_Log\_Key_. If a merge log succeed, all new keys will be packaged under the key specified by this option, a suggested configuration is as follows:
+In addition, fixes and improvements where made to the  `Merge_Log_Key` option. If a
+merge log succeed, all new keys will be packaged under the key specified by this
+option. A suggested configuration is as follows:
 
-```text
+```python
 [FILTER]
     Name             Kubernetes
     Match            kube.*
@@ -97,15 +126,20 @@ the final record will be composed as follows:
 
 ## Fluent Bit v1.1
 
-If you are upgrading from **Fluent Bit <= 1.0.x** you should take in consideration the following relevant changes when switching to **Fluent Bit v1.1** series:
+If you are upgrading from Fluent Bit <= 1.0.x review the following relevant
+changes when switching to Fluent Bit v1.1 or later series:
 
-### Kubernetes Filter
+### Kubernetes filter
 
-We introduced a new configuration property called _Kube\_Tag\_Prefix_ to help Tag prefix resolution and address an unexpected behavior that landed in previous versions.
+Fluent Bit introduced a new configuration property called `Kube_Tag_Prefix` to help
+Tag prefix resolution and address an unexpected behavior in previous versions.
 
-During 1.0.x release cycle, a commit in Tail input plugin changed the default behavior on how the Tag was composed when using the wildcard for expansion generating breaking compatibility with other services. Consider the following configuration example:
+During the `1.0.x` release cycle, a commit in the Tail input plugin changed the
+default behavior on how the Tag was composed when using the wildcard for expansion
+generating breaking compatibility with other services. Consider the following
+configuration example:
 
-```text
+```python
 [INPUT]
     Name  tail
     Path  /var/log/containers/*.log
@@ -118,19 +152,25 @@ The expected behavior is that Tag will be expanded to:
 kube.var.log.containers.apache.log
 ```
 
-but the change introduced in 1.0 series switched from absolute path to the base file name only:
+but the change introduced in 1.0 series switched from absolute path to the base filename only:
 
 ```text
 kube.apache.log
 ```
 
-On Fluent Bit v1.1 release we restored to our default behavior and now the Tag is composed using the absolute path of the monitored file.
+THe Fluent Bit v1.1 release restored the default behavior and now the Tag is
+composed using the absolute path of the monitored file.
 
-> Having absolute path in the Tag is relevant for routing and flexible configuration where it also helps to keep compatibility with Fluentd behavior.
+Having absolute path in the Tag is relevant for routing and flexible configuration
+where it also helps to keep compatibility with Fluentd behavior.
 
-This behavior switch in Tail input plugin affects how Filter Kubernetes operates. As you know when the filter is used it needs to perform local metadata lookup that comes from the file names when using Tail as a source. Now with the new _Kube\_Tag\_Prefix_ option you can specify what's the prefix used in Tail input plugin, for the configuration example above the new configuration will look as follows:
+This behavior switch in Tail input plugin affects how Filter Kubernetes operates.
+When the filter is used it needs to perform local metadata lookup that comes from the
+file names when using Tail as a source. With the new `Kube_Tag_Prefix` option
+you can specify what's the prefix used in Tail input plugin, for the previous configuration
+example the new configuration will look like:
 
-```text
+```python
 [INPUT]
     Name  tail
     Path  /var/log/containers/*.log
@@ -142,4 +182,5 @@ This behavior switch in Tail input plugin affects how Filter Kubernetes operates
     Kube_Tag_Prefix  kube.var.log.containers.
 ```
 
-So the proper for _Kube\_Tag\_Prefix_ value must be composed by Tag prefix set in Tail input plugin plus the converted monitored directory replacing slashes with dots.
+The proper value for `Kube_Tag_Prefix` must be composed by Tag prefix set in Tail
+input plugin plus the converted monitored directory replacing slashes with dots.