adding spelling and grammer

Signed-off-by: R-Lawton <[email protected]>

rfcs/0000-observability-api.md

@@ -18,7 +18,7 @@ Users of Kuadrant (Platform engineers and or Site reliability engineers) will wa
 # Guide-level explanation
 [guide-level-explanation]: #guide-level-explanation
 
-The observability configuration, will allow a user to configure different parts of the offered Kuadrant observability. This provides more freedom to the user rather then the all or nothing current approach for certain aspects or the manual entry in multiple locations approach. With the new way the user will only have to fill in their configuration in one location.
+The observability configuration, will allow a user to configure different parts of the offered Kuadrant observability. This provides more freedom to the user rather than the current all or nothing approach for certain aspects or the manual entry in multiple locations approach. With the new way the user will only have to fill in their configuration in one location.
 
 ### Potential configurations
 
@@ -40,8 +40,8 @@ The different aspects a user might want to modify could be the following:
 A use case a user might have could be the following:
 
 1. Setup tracing for the Kuadrant components Authorino and Limitador with the required endpoint and optional tag. 
-2. Disable the creation of the service and serviceMonitors created by Kuadrant for the components and there operators
-3. Configure logging for Authorino and Limitador. Note: For the first phase this is not available for the operators as they dont use the component CRs to implement new log levels flags/env-vars are used instead.
+2. Disable the creation of the service and serviceMonitors created by Kuadrant for the components and their operators
+3. Configure logging for Authorino and Limitador. Note: For the first phase this is not available for the operators as they don't use the component CRs to implement new log levels flags/env-vars are used instead.
 
 ```yaml 
 
@@ -89,7 +89,7 @@ The best approach would be the approach 2), an indirect approach, meaning once t
 
 #### Adding, modifying and deleting values or no values
 
-If a values is being configured either by being added, modified or removed, all changes will have to be made in the Kuadrant CR. If the component level operators are updated to change these values without the Kuadrant CR being changed they will be overridden back to the source of truth the Kuadrant CR provides. 
+If a value is being configured either by being added, modified or removed, all changes will have to be made in the Kuadrant CR. If the component level operators are updated to change these values without the Kuadrant CR being changed, they will be overridden back to the source of truth the Kuadrant CR provides. 
 
 If the value is removed from the Kuadrant CR it will also be removed from the relevant component CRs. If the value is removed from the component CR but not the Kuadrant CR it will be overridden and added back. 
 
@@ -99,21 +99,21 @@ If the value is removed from the Kuadrant CR it will also be removed from the re
 
 #### Answered q's
 1. Should the configuration be Kuadrant scoped as in its changed for everything or should be individual component scoped?
-**Yes it should be  level scope i.e Logging level configured is configured for every component that can not the user gets to pick and choose.**
+**Yes, it should be Kuadrant level scoped, i.e., the logging level configured is configured for every component.The user can not pick and choose.**
 
 2. Do we add the values to the Kuadrant CR instead?
 **Yes the configuration should be in the Kuadrant CR, the original observability CR no longer make sense. We should avoid APIs that rely on another APIs being there.**
 
-3. Do we go with a observability policy instead of the proposed configuration style CR like whats being suggested? TLDR of what that would look like is quite similar to the observability CR in the fact that the observability piece is pulled out but instead of there just being one source of truth with the current method, and having the fine grained capabilities be in the one location. Instead you would have for most use cases a single observability policy that would be attached at the Kuadrant component level, in there you would have a Kuadrant level view i.e if i enable tracing here its enabled for all the components that can handle it. From there if a component needs some special configuration a separate policy can be created and attached to that specific component instead. 
+3. Do we go with a observability policy instead of the proposed configuration style CR like whats being suggested? TLDR of what that would look like is quite similar to the observability CR in the fact that the observability piece is pulled out. However,instead of there just being one source of truth with the current method, and having the fine grained capabilities be in the one location, you would instead have, for most use cases, a single observability policy that would be attached at the Kuadrant component level. This would define would a Kuadrant level view i.e., if I enable tracing here its enabled for all the components that can handle it. If a component needs some special configuration a separate policy can be created and attached to that specific component instead. 
 
-In terms of Adding, modifying and deleting values or no values. Adding a value to the Kuadrant level view populates the values to the relevant component CR's. If finer configuration is needed then another policy is created for said component. If values are deleted from the Kuadrant level policy they are also then deleted from the relevant components CR's but if a component level policy is in place that will remain. If there is a observability policy in place in the Kuadrant level and a value is changes in the component CR then it will get overridden by the Kuadrant level policy. If there is no values in the Kuadrant level policy and a user changes the component level CR the value will not get overridden but the user will have to be made aware if something is added at the Kuadrant level in the future it will be overridden.
+In terms of adding, modifying and deleting values or no values; adding a value to the Kuadrant level view populates the values to the relevant component CR's. If finer configuration is needed then another policy is created for said component. If values are deleted from the Kuadrant level policy, they are also then deleted from the relevant components CR's but if a component level policy is in place that will remain. If there is a observability policy in place in the Kuadrant level and a value is changes in the component CR, then it will get overridden by the Kuadrant level policy. If there is no values in the Kuadrant level policy and a user changes the component level CR the value will not get overridden but the user will have to be made aware that if something is added at the Kuadrant level in the future, it will be overridden.
 
-**As of the time of writing this, no the original suggestion solves the issues we need right now.**
+**As of the time of writing this, no the original suggestion solves the issues we have right now, we dont need the Observability policy.**
 
 #### Work thats needed
-The indirect approach allows for not much if any changes to the Authorino operator and the Limitador operator etc. The bulk of the work that would be needed would be in the Kuadrant operator.
+The indirect approach allows for a few, if any, changes to the Authorino operator and the Limitador operator etc. The bulk of the work that would be needed would be in the Kuadrant operator.
 
-The changes will come into full affect through a phased approach due to the nature of some aspects not being available yet. The phased approach can follow the versioning syntax that k8s like v1beta1 or v1alpha1 and be portrayed in the CRD. 
+The changes will come into full effect through a phased approach due to the nature of some aspects not being available yet. The phased approach can follow the versioning syntax that k8s like v1beta1 or v1alpha1 and be portrayed in the CRD. 
  
 
 ### Default configuration
@@ -145,5 +145,5 @@ Manually adding configuration to Kuadrant operator crs.
 
 Currently we only have configuration for Logging, Tracing and Metrics. Post v1 the plan is to add alerts, dashboards and potentially other 3rd party like Kiali.
 
-* For the logging piece this is currently only for Authorino and Limitador and not there operators or the Kuadrant operator as these require flags to be changed so in phase two we can look at what work needs to be done to make this cohesive. For example being able to change a config and that gets percolated down to all the components .
+* For the logging piece this is currently only for Authorino and Limitador and not their operators or the Kuadrant operator as these require flags to be changed so in phase two we can look at what work needs to be done to make this cohesive. For example being able to change a config and that gets percolated down to all the components .