fix linting

enhancements/node-tuning/pao-in-nto.md

@@ -48,7 +48,10 @@ The current deliverables are:
 
   The must gather image [enhances](https://github.com/openshift-kni/performance-addon-operators/tree/master/must-gather) the main OCP one and [collects](https://docs.openshift.com/container-platform/4.8/scalability_and_performance/cnf-performance-addon-operator-for-low-latency-nodes.html#cnf-about-gathering-data_cnf-master) some latency tuning configuration and data that are needed for debugging.
 
-- and the functional tests are also vendored into [cnf-tests](https://catalog.redhat.com/software/containers/openshift4/cnf-tests-rhel8/5e9d81f65a134668769d560b?container-tabs=overview&gti-tabs=registry-tokens) that can be used to [validate customer deployments](https://docs.openshift.com/container-platform/4.8/scalability_and_performance/cnf-performance-addon-operator-for-low-latency-nodes.html#cnf-performing-end-to-end-tests-for-platform-verification_cnf-master) (this includes other aspects like SCTP, PTP, SR-IOV as well).
+- functional tests are also vendored into 
+[cnf-tests](https://catalog.redhat.com/software/containers/openshift4/cnf-tests-rhel8/5e9d81f65a134668769d560b?container-tabs=overview&gti-tabs=registry-tokens) 
+that can be used to 
+[validate customer deployments](https://docs.openshift.com/container-platform/4.8/scalability_and_performance/cnf-performance-addon-operator-for-low-latency-nodes.html#cnf-performing-end-to-end-tests-for-platform-verification_cnf-master) (this includes other aspects like SCTP, PTP, SR-IOV as well).
 
 ## Motivation
 
@@ -58,9 +61,16 @@ The Telco team maintains its own build and release pipelines and releases via a
 
 - The OCP [gcp-rt](https://prow.ci.openshift.org/?type=periodic&job=*gcp-rt*) lane tests OCP deployment on top of GCP with the real-time kernel enabled, but it only works [thanks to some pieces of PAO tuning](https://github.com/openshift/release/pull/18870). However the tuning is a pre-rendered snippet, not linked to the operator, because the deployment does not know about PAO.
 
-- PAO is closely tied to some OCP components ([Cluster Node Tuning Operator](https://github.com/openshift/cluster-node-tuning-operator)) and depends on the OCP version. So we release PAO for every OCP minor version (since 4.4) and together with some of the OCP Z-streams. The upgrade procedure is tricky though, first OCP needs to be upgraded and then PAO via an OLM channel change. This is needed to make sure the necessary functionality is present in the running NTO.
+- PAO is closely tied to some OCP components 
+([Cluster Node Tuning Operator](https://github.com/openshift/cluster-node-tuning-operator)) 
+and depends on the OCP version. So we release PAO for every OCP minor version (since 4.4) and together with some of the OCP Z-streams. 
+The upgrade procedure is tricky though, first OCP needs to be upgraded and then PAO via an OLM channel change. 
+This is needed to make sure the necessary functionality is present in the running NTO.
 
-- The new [Workload partitioning](https://github.com/openshift/enhancements/blob/master/enhancements/workload-partitioning/management-workload-partitioning.md) feature seeks to use PAO as the configuration tool. However Workload partitioning needs to be enabled at install phase and PAO CRDs are not yet available at that time. [A "hacky" procedure](https://github.com/openshift/enhancements/pull/753) is needed to overcome this.
+- The new [Workload partitioning](https://github.com/openshift/enhancements/blob/master/enhancements/workload-partitioning/management-workload-partitioning.md) 
+feature seeks to use PAO as the configuration tool. 
+However Workload partitioning needs to be enabled at install phase and PAO CRDs are not yet available at that time. 
+[A "hacky" procedure](https://github.com/openshift/enhancements/pull/753) is needed to overcome this.
 
 ### Goals
 
@@ -76,7 +86,7 @@ Logic changes or tighter integration with other MCO controllers are not expected
 
 To be really clear here, the Telco team will handle all the necessary changes to both codebases, however we will need support in the form of PR reviews and design consultations.
 
-#### Code
+### Code
 
 PAO code would be moved into the NTO repository as a separate controller. The Telco team would keep ownership as it has the necessary domain knowledge needed to implement the low latency tuning.
 
@@ -89,27 +99,27 @@ PAO must-gather will have the native support with additional arguments and will
 [cnf-tests](https://github.com/openshift-kni/cnf-features-deploy/) are NOT part of this move either, the Telco team will keep maintaining the validation suite in OpenShift KNI.
 
 
-#### CI
+### CI
 
 PAO contains both unit and functional tests implemented using Ginkgo.
 
 Integration with NTO is currently TBD, please advise if anything special is needed.
 
 One of the test suites (4_latency) implements an opinionated latency testing suite to get comparable results from customers and to prevent configuration / command line invocation mistakes. Keeping it in PAO/NTO or moving it into cnf-tests is TBD.
 
-#### Build pipeline
+### Build pipeline
 
 PAO would inherit the NTO pipeline and all the images will be released via ART.
 
-#### Releases
+### Releases
 
 PAO should be shipped as part of core OCP. ART again. PAO already obeys the OCP github PR rules and uses the same PR bot so nothing changes in the lifecycle.
 
-#### API stability
+### API stability
 
 The `PerformanceProfile` CR uses an `performance.openshift.io/v2` API group which marks it as stable interface that needs to be maintained for about a year after official deprecation. We do not expect any change to the API as part of this proposal.
 
-#### Bugs
+### Bugs
 
 PAO bugs are currently tracked in The OpenShift Bugzilla component [Performance Addon Operator](https://bugzilla.redhat.com/buglist.cgi?component=Performance%20Addon%20Operator&list_id=12053428&product=OpenShift%20Container%20Platform)