spell fixes

Author: isabella-janssen

Diff for: enhancements/machine-config/machine-config-node.md

@@ -22,7 +22,7 @@ superseded-by:
 
 <!-- 
 General TODO List:
-- Reference PIS enhancment (https://github.com/openshift/enhancements/blob/master/enhancements/machine-config/pin-and-pre-load-images.md) for PIS related fields
+- Reference PIS enhancement (https://github.com/openshift/enhancements/blob/master/enhancements/machine-config/pin-and-pre-load-images.md) for PIS related fields
 - Add information on node degraded field
 -->
 
@@ -184,9 +184,9 @@ There are two levels of conditions in MachineConfigNode: the parent and the chil
 
 <!-- TODO: 
 - Update with what the `oc get` and `oc get .. wide` columns are updated to be; the "child" showing for the same command does not really make sense?
-- Decide if PIS statuses should be included in -o wide output. If not, change "will additionally reveal all parent and child phases" phrasing to highlight it does nto include PIS statuses.
+- Decide if PIS statuses should be included in -o wide output. If not, change "will additionally reveal all parent and child phases" phrasing to highlight it does not include PIS statuses.
 -->
-The information shown in `oc get machineconfignodes` includes the Node's name, associated MachineConfigPool, current and desired config versions, and updated status. Using `oc describe machineconfignodes -o wide` will additionally reveal all parent and child phases. Within each parent phase there can be 0+ child phases that customers can use to see upgrade progression. The upgrade flow can be seen in the following diagram and in the subsequent example ouputs.
+The information shown in `oc get machineconfignodes` includes the Node's name, associated MachineConfigPool, current and desired config versions, and updated status. Using `oc describe machineconfignodes -o wide` will additionally reveal all parent and child phases. Within each parent phase there can be 0+ child phases that customers can use to see upgrade progression. The upgrade flow can be seen in the following diagram and in the subsequent example outputs.
 
 ```mermaid
 block-beta
@@ -363,7 +363,7 @@ ip-10-0-65-65.ec2.internal    worker     rendered-worker-f77322e2feead61600f41c9
 ip-10-0-73-121.ec2.internal   master     rendered-master-6c320f722eb9ce8bfbd80750dbf70d2e   rendered-master-6c320f722eb9ce8bfbd80750dbf70d2e   True      False            False            False                      False            False     False               False          False         False          False          
 ```
 
-In general, a state (and its respective child states) will transition from False -> Unknown -> True -> False. The states are mostly in the past tense. This is because processes like `Drained` are primarily defined by completion, not the progress. So a user will have `UpdateExecuted` == Unknown and `Drained` == Unknown until the Drain actually completes. However, the unknown phase will be accompanied by a message for how the drain is currently going or if an error has occured with during the drain.
+In general, a state (and its respective child states) will transition from False -> Unknown -> True -> False. The states are mostly in the past tense. This is because processes like `Drained` are primarily defined by completion, not the progress. So a user will have `UpdateExecuted` == Unknown and `Drained` == Unknown until the Drain actually completes. However, the unknown phase will be accompanied by a message for how the drain is currently going or if an error has occurred during the drain.
 
 Once Updated == True is the case, the update process is considered complete, all previous states are set to False, and the condition details will show that the message is from the previous update cycle.
 
@@ -539,7 +539,7 @@ Also add support for the following features
 
 ### Upgrade / Downgrade Strategy
 
-Between upgrades, this feature should not have a large impact. It will preform as it usually does and it will track node processes in both upgrades and downgrades. If a node is added or removed, the MachineConfigNode object will not report on it until the node is acknowledged by the MCO.
+Between upgrades, this feature should not have a large impact. It will perform as it usually does and it will track node processes in both upgrades and downgrades. If a node is added or removed, the MachineConfigNode object will not report on it until the node is acknowledged by the MCO.
 
 ### Version Skew Strategy
 
@@ -575,7 +575,7 @@ Using a separate controller allows for information consolidation and furthers th
   - An improper actor could potentially modify information on the node such that the MachinestateController thinks an upgrade event is going on but in reality it is not.
     - Nothing "consumes" the MCN data type in this design. However, this is still a future concern and one that has been voiced by many teams.
 2) Unnecessary level of abstraction
-   - The MCD is the source of the data so it should "own" the updating process of the MCN. This is true and fits into the idomatic processes of kubernetes. However, the goal of the MCO was to consolidate all state and metric reporting into a single location. It is a question of prioritizing data efficiency.
+   - The MCD is the source of the data so it should "own" the updating process of the MCN. This is true and fits into the idiomatic processes of kubernetes. However, the goal of the MCO was to consolidate all state and metric reporting into a single location. It is a question of prioritizing data efficiency.
 
 The summary of the two alternatives is as follows: