docs: update data plane config file

Author: salonichf5

content/ngf/how-to/data-plane-configuration.md

@@ -11,34 +11,34 @@ Learn how to dynamically update the NGINX Gateway Fabric global data plane confi
 
 ## Overview
 
-NGINX Gateway Fabric can dynamically update the global data plane configuration without restarting. The data plane configuration contains configuration for NGINX that is not available using the standard Gateway API resources. This includes such things as setting an OpenTelemetry collector config, disabling http2, changing the IP family, or setting the NGINX error log level.
+NGINX Gateway Fabric can dynamically update the global data plane configuration without restarting. The data plane configuration is a global configuration for NGINX that has options that is not available using the standard Gateway API resources. This includes options such as configuring an OpenTelemetry collector, disabling HTTP/2, changing the IP family, modifying infrastructure-related fields, and setting the NGINX error log level.
 
-The data plane configuration is stored in the NginxProxy custom resource, which is a namespace-scoped resource that can be attached to a GatewayClass or Gateway. When attached to a GatewayClass, the fields in the NginxProxy affect all Gateways that belong to the GatewayClass.
-When attached to a Gateway, the fields in the NginxProxy only affect the Gateway. If a GatewayClass and its Gateway both specify an NginxProxy, the GatewayClass NginxProxy provides defaults that can be overridden by the Gateway NginxProxy. See the [Merging Semantics](#merging-semantics) section for more detail.
+The data plane configuration is stored in the `NginxProxy` custom resource, which is a namespace-scoped resource that can be attached to a gatewayClass or gateway. When attached to a gatewayClass, the fields in the NginxProxy affect all gateways that belong to the gatewayClass.
+When attached to a gateway, the fields in the NginxProxy only affect the gateway. If a gatewayClass and its gateway both specify an NginxProxy, the gatewayClass NginxProxy provides defaults that can be overridden by the gateway NginxProxy. See the [Merging Semantics](#merging-semantics) section for more detail.
 
 ---
 
 ## Merging Semantics
 
-NginxProxy resources are merged when a GatewayClass and a Gateway reference different NginxProxy resources.
+NginxProxy resources are merged when a gatewayClass and a gateway reference different NginxProxy resources.
 
 For fields that are bools, integers, and strings:
-- If a field on the Gateway's NginxProxy is unspecified (`nil`), the Gateway __inherits__ the value of the field in the GatewayClass's NginxProxy.
-- If a field on the Gateway's NginxProxy is specified, its value __overrides__ the value of the field in the GatewayClass's NginxProxy.
+- If a field on the gateway's NginxProxy is unspecified (`nil`), the gateway __inherits__ the value of the field in the gatewayClass's NginxProxy.
+- If a field on the gateway's NginxProxy is specified, its value __overrides__ the value of the field in the gatewayClass's NginxProxy.
 
 For array fields:
-- If the array on the Gateway's NginxProxy is unspecified (`nil`), the Gateway __inherits__ the entire array in the GatewayClass's NginxProxy.
-- If the array on the Gateway's NginxProxy is empty, it __overrides__ the entire array in the GatewayClass's NginxProxy, effectively unsetting the field.
-- If the array on the Gateway's NginxProxy is specified and not empty, it __overrides__ the entire array in the GatewayClass's NginxProxy.
+- If the array on the gateway's NginxProxy is unspecified (`nil`), the gateway __inherits__ the entire array in the gatewayClass's NginxProxy.
+- If the array on the gateway's NginxProxy is empty, it __overrides__ the entire array in the gatewayClass's NginxProxy, effectively unsetting the field.
+- If the array on the gateway's NginxProxy is specified and not empty, it __overrides__ the entire array in the gatewayClass's NginxProxy.
 
 
 ### Merging Examples
 
-This section contains examples of how NginxProxy resources are merged when they are attached to both a Gateway and its GatewayClass.
+This section contains examples of how NginxProxy resources are merged when they are attached to both a gateway and its gatewayClass.
 
 #### Disable HTTP/2 for a Gateway
 
-A GatewayClass references the following NginxProxy which explicitly allows HTTP/2 traffic and sets the IPFamily to ipv4:
+A gatewayClass references the following NginxProxy which explicitly allows HTTP/2 traffic and sets the IPFamily to ipv4:
 
 ```yaml
 apiVersion: gateway.nginx.org/v1alpha2
@@ -51,7 +51,7 @@ spec:
   disableHTTP: false
 ```
 
-To disable HTTP/2 traffic for a particular Gateway, reference the following NginxProxy in the Gateway's spec:
+To disable HTTP/2 traffic for a particular gateway, reference the following NginxProxy in the gateway's spec:
 
 ```yaml
 apiVersion: gateway.nginx.org/v1alpha2
@@ -63,7 +63,7 @@ spec:
   disableHTTP: true
 ```
 
-These NginxProxy resources are merged and the following settings are applied to the Gateway:
+These NginxProxy resources are merged and the following settings are applied to the gateway:
 
 ```yaml
 ipFamily: "ipv4"
@@ -72,7 +72,7 @@ disableHTTP: true
 
 #### Change Telemetry configuration for a Gateway
 
-A GatewayClass references the following NginxProxy which configures telemetry:
+A gatewayClass references the following NginxProxy which configures telemetry:
 
 ```yaml
 apiVersion: gateway.nginx.org/v1alpha2
@@ -92,7 +92,7 @@ spec:
       value: "company-value"
 ```
 
-To change the telemetry configuration for a particular Gateway, reference the following NginxProxy in the Gateway's spec:
+To change the telemetry configuration for a particular gateway, reference the following NginxProxy in the gateway's spec:
 
 ```yaml
 apiVersion: gateway.nginx.org/v1alpha2
@@ -111,7 +111,7 @@ spec:
       value: "app-value"
 ```
 
-These NginxProxy resources are merged and the following settings are applied to the Gateway:
+These NginxProxy resources are merged and the following settings are applied to the gateway:
 
 ```yaml
   telemetry:
@@ -128,7 +128,7 @@ These NginxProxy resources are merged and the following settings are applied to
 
 #### Disable Tracing for a Gateway
 
-A GatewayClass references the following NginxProxy which configures telemetry:
+A gatewayClass references the following NginxProxy which configures telemetry:
 
 ```yaml
 apiVersion: gateway.nginx.org/v1alpha2
@@ -144,7 +144,7 @@ spec:
     serviceName: "my-company"
 ```
 
-To disable tracing for a particular Gateway, reference the following NginxProxy in the Gateway's spec:
+To disable tracing for a particular gateway, reference the following NginxProxy in the gateway's spec:
 
 ```yaml
 apiVersion: gateway.nginx.org/v1alpha2
@@ -158,7 +158,7 @@ spec:
     - DisableTracing
 ```
 
-These NginxProxy resources are merged and the following settings are applied to the Gateway:
+These NginxProxy resources are merged and the following settings are applied to the gateway:
 
 ```yaml
 telemetry:
@@ -172,9 +172,9 @@ telemetry:
 
 ---
 
-## Configuring the GatewayClass NginxProxy on Install
+## Configuring the GatewayClass NginxProxy on install
 
-By default, the NginxProxy resource is not created when installing NGINX Gateway Fabric. However, you can set configuration options in the `nginx.config` Helm values, and the resource will be created and attached to the GatewayClass when NGINX Gateway Fabric is installed using Helm. You can also [manually create and attach](#manually-creating-nginxproxies) the resource after NGINX Gateway Fabric is already installed.
+By default, the `NginxProxy` resource is created in the same namespace where NGINX Gateway Fabric is installed. You can set configuration options in the `nginx.` Helm values, and the resource will be created and attached using the set values, when NGINX Gateway Fabric is installed using Helm. You can also manually create and attach specific `NginxProxy` resources to target different data planes [manually creating NginxProxies](#manually-creating-nginxProxies).
 
 When installed using the Helm chart, the NginxProxy resource is named `<release-name>-proxy-config` and is created in the release Namespace.
 
@@ -186,7 +186,7 @@ When installed using the Helm chart, the NginxProxy resource is named `<release-
 
 ## Manually Creating NginxProxies
 
-The following command creates a basic `NginxProxy` configuration that sets the IP family to `ipv4` instead of the default value of `dual`:
+The following command creates a basic `NginxProxy` configuration in the `default` namespace that sets the IP family to `ipv4` instead of the default value of `dual`:
 
 ```yaml
 kubectl apply -f - <<EOF
@@ -200,13 +200,11 @@ spec:
 EOF
 ```
 
-**For a full list of configuration options that can be set, see the `NginxProxy spec` in the [API reference]({{< ref "/ngf/reference/api.md" >}}).**
-
 ---
 
 ### Attaching NginxProxy to GatewayClass
 
-To attach the `ngf-proxy-config` NginxProxy to the GatewayClass:
+To attach the `ngf-proxy-config` NginxProxy to the gatewayClass:
 
 ```shell
 kubectl edit gatewayclass nginx
@@ -222,7 +220,7 @@ parametersRef:
     namespace: default
 ```
 
-After updating, you can check the status of the GatewayClass to see if the configuration is valid:
+After updating, you can check the status of the gatewayClass to see if the configuration is valid:
 
 ```shell
 kubectl describe gatewayclass nginx
@@ -246,7 +244,7 @@ If everything is valid, the `ResolvedRefs` condition should be `True`. Otherwise
 
 ### Attaching NginxProxy to Gateway
 
-To attach the `ngf-proxy-config` NginxProxy to a Gateway:
+To attach the `ngf-proxy-config` NginxProxy to a gateway:
 
 ```shell
 kubectl edit gateway <gateway-name>
@@ -262,7 +260,7 @@ infrastructure:
         name: ngf-proxy-config
 ```
 
-After updating, you can check the status of the Gateway to see if the configuration is valid:
+After updating, you can check the status of the gateway to see if the configuration is valid:
 
 ```shell
 kubectl describe gateway <gateway-name>
@@ -282,11 +280,13 @@ Status:
 
 If everything is valid, the `ResolvedRefs` condition should be `True`. Otherwise, you will see an `InvalidParameters` condition in the status.
 
+{{< note >}} The `NginxProxy` resource must reside in the same namespace as the gateway it is attached to. {{< /note >}}
+
 ---
 
 ## Configure the data plane log level
 
-You can use the `NginxProxy` resource to dynamically configure the Data Plane Log Level.
+You can use the `NginxProxy` resource at the gatewayClass level to dynamically configure the log level for all data plane instances.
 
 The following command creates a basic `NginxProxy` configuration that sets the log level to `warn` instead of the default value of `info`:
 
@@ -302,7 +302,7 @@ spec:
 EOF
 ```
 
-To view the full list of supported log levels, see the `NginxProxy spec` in the [API reference]({{< ref "/ngf/reference/api.md" >}}).
+Other log levels supported are  - debug, notice, error, crit, alert, emerg.
 
 {{< note >}}For `debug` logging to work, NGINX needs to be built with `--with-debug` or "in debug mode". NGINX Gateway Fabric can easily
 be [run with NGINX in debug mode](#run-nginx-gateway-fabric-with-nginx-in-debug-mode) upon startup through the addition
@@ -375,6 +375,36 @@ spec:
 EOF
 ```
 
-For the full configuration API, see the `NginxProxy spec` in the [API reference]({{< ref "/ngf/reference/api.md" >}}).
-
 {{< note >}} When sending curl requests to a server expecting proxy information, use the flag `--haproxy-protocol` to avoid broken header errors. {{< /note >}}
+
+---
+
+## Configure infrastructure-related settings
+
+You can configure deployment and service settings for all data plane instances by editing the `NginxProxy` resource at the gatewayClass level. These settings can also be specified under `nginx.` in the Helm values file. 
+
+Users can specify these settings for NGINX data plane deployments:
+
+  - _replicas_ specifies the number of data plane pod replicas..
+  - The `pod` section provides control over pod scheduling and lifecycle behavior. You can configure settings such as _terminationGracePeriodSeconds_, _tolerations_, _nodeSelector_, _affinity_, and _topologySpreadConstraints_. Use _extraVolumes_ to mount additional volumes, typically alongside container-level _extraVolumeMounts_.
+  - The `container` defines settings for the NGINX container itself., such as resource requests and limits using _resources_, and lifecycle hooks like preStop or postStart via _lifecycle_. You can also specify _extraVolumeMounts_ to mount additional volumes defined at the pod level.
+
+Users can specify these settings for NGINX data plane service in the `service` config:
+
+  - _type_ specifies the service type for the NGINX data plane. Allowed values are ClusterIP, NodePort, or LoadBalancer.
+  - _externalTrafficPolicy_ sets how external traffic is handled. `Local` preserves the client’s source IP.
+  - _annotations_ adds custom annotations to the NGINX data plane service.
+  - Certain fields are only applicable when _service.type_ is set to `LoadBalancer`: _loadBalancerIP_ to assign a static IP, _loadBalancerClass_ to define the load balancer implementation, and _loadBalancerSourceRanges_ to restrict access to specific IP ranges (CIDRs).
+
+  The below fields can only be specified when the `service.type` is `LoadBalancer`:
+  - _loadBalancerIP_ specifies the static IP address of the load balancer.
+  - _loadBalancerClass_ specifies the class of the load balancer implementation this service belongs to.
+  - _loadBalancerSourceRanges_ specifies IP ranges (CIDR) that are allowed to access the load balancer.
+
+---
+
+## See also
+
+For a full list of configuration options that can be set, see the `NginxProxy spec` in the [API reference]({{< ref "/ngf/reference/api.md" >}}).
+
+---