Fix from the pre-commit integration

Signed-off-by: Pierluigi Lenoci <pierluigi.lenoci@gmail.com>

.github/ISSUE_TEMPLATE/vpa_release.md

@@ -14,4 +14,4 @@ completed step on this issue.
 Please provide any information that is related to the release:
 
 - When we plan to do the release?
-- Are there any issues / PRs blocking the release?
+- Are there any issues / PRs blocking the release?

CONTRIBUTING.md

@@ -5,10 +5,10 @@
 ### Signing Contributor License Agreements(CLA)
 
 We'd love to accept your patches! Before we can take them, we have to jump a couple of legal hurdles.
- 
+
  Please fill out either the individual or corporate Contributor License Agreement
  (CLA).
- 
+
    * If you are an individual writing original source code and you're sure you
      own the intellectual property, then you'll need to sign an
      [individual CLA](https://identity.linuxfoundation.org/node/285/node/285/individual-signup).
@@ -21,15 +21,15 @@ We'd love to accept your patches! Before we can take them, we have to jump a cou
  * Fork the desired repo, develop and test your code changes.
  * Submit a pull request.
 
-All changes must be code reviewed. Coding conventions and standards are explained in the official 
-[developer docs](https://github.com/kubernetes/community/tree/master/contributors/devel). Expect 
+All changes must be code reviewed. Coding conventions and standards are explained in the official
+[developer docs](https://github.com/kubernetes/community/tree/master/contributors/devel). Expect
 reviewers to request that you avoid common [go style mistakes](https://github.com/golang/go/wiki/CodeReviewComments)
 in your PRs.
 
 ### Merge Approval
 
-Autoscaler collaborators may add "LGTM" (Looks Good To Me) or an equivalent comment to indicate 
-that a PR is acceptable. Any change requires at least one LGTM. No pull requests can be merged 
+Autoscaler collaborators may add "LGTM" (Looks Good To Me) or an equivalent comment to indicate
+that a PR is acceptable. Any change requires at least one LGTM. No pull requests can be merged
 until at least one Autoscaler collaborator signs off with an LGTM.
 
 ### Support Channels

addon-resizer/README.md

@@ -77,7 +77,7 @@ parameters:
   *Note: Addon Resizer uses buckets of cluster sizes, so it will use n larger
   than the cluster size by up to 50% for clusters larger than 16 nodes. For
   smaller clusters, n = 16 will be used.*
- 
+
 2. Memory parameters:
   ```
   --memory

addon-resizer/enhancements/5546-scaling-based-on-container-count/README.md

@@ -15,7 +15,7 @@
 
 Currently Addon Resizer supports scaling based on the number of nodes. Some workloads use resources proportionally to
 the number of containers in the cluster. Since number of containers per node is very different in different clusters
-it's more resource-efficient to scale such workloads based directly on the container count. 
+it's more resource-efficient to scale such workloads based directly on the container count.
 
 ### Goals
 
@@ -46,7 +46,7 @@ Addon Resizer 1.8 assumes in multiple places that it's scaling based on the numb
   to either node count or container count, depending on the value of the `--scaling-mode` flag.
 - Many variable names in code which now refer to node count will refer to cluster size and should be renamed accordingly.
 
-In addition to implementing the feature we should also clean up the code and documentation.  
+In addition to implementing the feature we should also clean up the code and documentation.
 
 ### Risks and Mitigations
 
@@ -59,7 +59,7 @@ all containers could result in higher load on the Cluster API server. Since Addo
 I don't expect this effect to be noticeable.
 
 Also I expect metrics-server to test for this before using the feature and any other users of Addon Resizer are likely
-better off using metrics (which don't have this problem). 
+better off using metrics (which don't have this problem).
 
 ## Design Details
 
@@ -120,4 +120,4 @@ Both tests should be performed with metrics- and API- based scaling.
 [`Status.Phase`]: https://github.com/kubernetes/api/blob/1528256abbdf8ff2510112b28a6aacd239789a36/core/v1/types.go#L4011
 [selector excluding pods in terminal states in VPA]: https://github.com/kubernetes/autoscaler/blob/04e5bfc88363b4af9fdeb9dfd06c362ec5831f51/vertical-pod-autoscaler/e2e/v1beta2/common.go#L195
 [`updateResources()`]: https://github.com/kubernetes/autoscaler/blob/da500188188d275a382be578ad3d0a758c3a170f/addon-resizer/nanny/nanny_lib.go#L126
-[`example.yaml`]: https://github.com/kubernetes/autoscaler/blob/c8d612725c4f186d5de205ed0114f21540a8ed39/addon-resizer/deploy/example.yaml
+[`example.yaml`]: https://github.com/kubernetes/autoscaler/blob/c8d612725c4f186d5de205ed0114f21540a8ed39/addon-resizer/deploy/example.yaml

addon-resizer/enhancements/5700-nanny-configuration-reload/README.md

@@ -14,7 +14,7 @@
 Sure, here's the enhancement proposal in the requested format:
 
 ## Summary
-- **Goals:** The goal of this enhancement is to improve the user experience for applying nanny configuration changes in the addon-resizer 1.8 when used with the metrics server. The proposed solution involves automatically reloading the nanny configuration whenever changes occur, eliminating the need for manual intervention and sidecar containers. 
+- **Goals:** The goal of this enhancement is to improve the user experience for applying nanny configuration changes in the addon-resizer 1.8 when used with the metrics server. The proposed solution involves automatically reloading the nanny configuration whenever changes occur, eliminating the need for manual intervention and sidecar containers.
 - **Non-Goals:** This proposal does not aim to update the functional behavior of the addon-resizer.
 
 ## Proposal