doc: correct typos in struct field comments and release.md

corrected strings in the release guide and util server.

Signed-off-by: Humble Chirammal <hchiramm@redhat.com>

docs/development-guide.md

@@ -25,7 +25,7 @@ it is **highly** encouraged to:
    package](https://github.com/ceph/go-ceph). It is required to install the
    Ceph C headers in order to compile Ceph-CSI. The packages are called
    `librados-devel` and `librbd-devel` on many Linux distributions. See the
-   [go-ceph installaton
+   [go-ceph installation
    instructions](https://github.com/ceph/go-ceph#installation) for more
    details.
 * Run
@@ -169,7 +169,7 @@ The `component` in the subject of the commit message can be one of the following
 * `doc`: documentation updates
 * `util`: utilities shared between components use `cephfs` or `rbd` if the
    change is only relevant for one of the type of storage
-* `journal`: any of the journalling functionalities
+* `journal`: any of the journaling functionalities
 * `helm`: deployment changes for the Helm charts
 * `deploy`: updates to Kubernetes templates for deploying components
 * `build`: anything related to building Ceph-CSI, the executable or container
@@ -312,12 +312,12 @@ Right now, we also have below commands to manually retrigger the CI jobs
 **Caution**: Please do not retrigger the CI jobs without an understanding of
              the root cause, because:
 
-* We may miss some of the important corner cases which are true negatives,
+* We may miss some important corner cases which are true negatives,
   and hard to reproduce
 * Retriggering jobs for known failures can unnecessarily put CI resources
   under pressure
 
-Hence it is recommended that you please go through the CI logs first, if you
+Hence, it is recommended that you please go through the CI logs first, if you
 are certain about the flaky test failure behavior, then comment on the PR
 indicating the logs about a particular test that went flaky and use the
 appropriate command to retrigger the job[s].

docs/metrics.md

@@ -26,10 +26,10 @@ Promethues can be deployed through the promethues operator described [here](http
 The [service-monitor](../examples/service-monitor.yaml) will tell promethues how
 to pull metrics out of CSI.
 
-Each CSI pod has a service to expose the endpoint to prometheus. By default rbd
+Each CSI pod has a service to expose the endpoint to prometheus. By default, rbd
 pods run on port 8080 and cephfs 8081.
 These can be changed if desired or if multiple ceph clusters are deployed more
 ports will be used for additional CSI pods.
 
-Note: You may need to open the ports used in your firewall depending on how you
-cluster is setup.
+Note: You may need to open the ports used in your firewall depending on how your
+cluster has set up.

docs/releases.md

@@ -41,7 +41,7 @@ and it must be backward compatible.
 
 - When `MAJOR` increases, the new release adds **new features,
   bug fixes, or both** and which *changes the behavior from
-  the previous release* (may be backward incompatible).
+  the previous release* (maybe backward incompatible).
 
 ## Tagging repositories
 

internal/util/util.go

@@ -90,7 +90,7 @@ type Config struct {
 	EnableGRPCMetrics bool          // option to enable grpc metrics
 
 	EnableProfiling    bool // flag to enable profiling
-	IsControllerServer bool // if set to true start provisoner server
+	IsControllerServer bool // if set to true start provisioner server
 	IsNodeServer       bool // if set to true start node server
 	Version            bool // cephcsi version
 
@@ -164,7 +164,7 @@ type KernelVersion struct {
 	SubLevel     int
 	ExtraVersion int    // prefix of the part after the first "-"
 	Distribution string // component of full extraversion
-	Backport     bool   // backports have a fixed version/patchlevel/sublevel
+	Backport     bool   // backport have a fixed version/patchlevel/sublevel
 }
 
 // parseKernelRelease parses a kernel release version string into:
@@ -202,9 +202,9 @@ func parseKernelRelease(release string) (int, int, int, int, error) {
 
 // CheckKernelSupport checks the running kernel and comparing it to known
 // versions that have support for required features . Distributors of
-// enterprise Linux have backported quota support to previous versions. This
+// enterprise Linux have backport quota support to previous versions. This
 // function checks if the running kernel is one of the versions that have the
-// feature/fixes backported.
+// feature/fixes backport.
 //
 // `uname -r` (or Uname().Utsname.Release has a format like 1.2.3-rc.vendor
 // This can be slit up in the following components: - version (1) - patchlevel