feat: fix image in ee and move content around

docs/enterprise_edition/control_plane/.pages

@@ -1,5 +1,4 @@
 nav:
   - index.md
   - installation.md
-  - features
   - ...

docs/enterprise_edition/control_plane/features/alerts.md → docs/enterprise_edition/control_plane/alerts.md

@@ -4,7 +4,7 @@ icon: material/alert-circle-outline
 
 # Alerts
 
-Since the control plane has access to real-time PgDog [metrics](../../../features/metrics.md), it can detect outliers and trigger automatic alerts.
+Since the control plane has access to real-time PgDog [metrics](../../features/metrics.md), it can detect outliers and trigger automatic alerts.
 
 ## How it works
 
@@ -27,27 +27,42 @@ The following incident management providers are supported:
 
 Alerts are **disabled** by default. To enable them, configure a provider's API key and set thresholds for each supported metric you would like to monitor:
 
-```yaml title="values.yaml"
-control:
-  config:
-    alerts:
-      evaluation_window_secs: 300
-      thresholds:
-        clients_waiting: 10
-        cpu: 90.0
-        memory: 2048
-        server_connections: 100
-      incident_io:
-        api_key: inc_live_xxx
-```
+=== "Helm chart"
+    ```yaml title="values.yaml"
+    control:
+      config:
+        alerts:
+          evaluation_window_secs: 300
+          thresholds:
+            clients_waiting: 10
+            cpu: 90.0
+            memory: 2048
+            server_connections: 100
+          incident_io:
+            api_key: inc_live_xxx
+    ```
+=== "control.toml"
+    ```toml
+    [alerts]
+    evaluation_window_secs = 300
+
+    [alerts.thresholds]
+    clients_waiting = 10
+    cpu = 90.0
+    memory = 2048
+    server_connections = 100
+
+    [alerts.incident_io]
+    api_key = "inc_live_xxx"
+    ```
 
 #### Parameters
 
 !!! note "Disabled by default"
     Thresholds have no defaults. If a threshold is not configured, its metric will not be monitored.
 
 
-The following parameters are configurable via the [Helm chart](../installation.md):
+The following parameters are configurable via the [Helm chart](installation.md):
 
 | Parameter | Description | Unit |
 |-|-|-|

docs/enterprise_edition/control_plane/features/autoscaling.md → docs/enterprise_edition/control_plane/autoscaling.md

@@ -8,18 +8,24 @@ Autoscaling automatically adjusts PgDog settings when the number of processes (e
 
 ## Configuration
 
-Autoscaling is **disabled** by default. To enable it, add the following settings to the [control plane](../installation.md) Helm [chart](https://github.com/pgdogdev/helm-ee):
-
-```yaml title="values.yaml"
-control:
-  config:
-    autoscaling:
-      pool_size: true
-```
+Autoscaling is **disabled** by default. To enable it, add the following settings to the [control plane](installation.md) Helm [chart](https://github.com/pgdogdev/helm-ee):
+
+=== "Helm chart"
+    ```yaml title="values.yaml"
+    control:
+      config:
+        autoscaling:
+          pool_size: true
+    ```
+=== "control.toml"
+    ```toml
+    [autoscaling]
+    pool_size = true
+    ```
 
 ## How it works
 
-When a PgDog process connects to the [control plane](../../control_plane/index.md), the control plane provides it with the total number of processes that are part of the same deployment. PgDog then automatically adjusts its configuration by dividing all pool-related configuration values by that number, for example:
+When a PgDog process connects to the [control plane](index.md), the control plane provides it with the total number of processes that are part of the same deployment. PgDog then automatically adjusts its configuration by dividing all pool-related configuration values by that number, for example:
 
 === "Configuration"
     ```toml title="pgdog.toml"
@@ -99,20 +105,20 @@ The following configuration options are supported for pool size autoscaling:
 
 | Section | Configuration |
 |-|-|
-| [`[general]`](../../../configuration/pgdog.toml/general.md) | [`default_pool_size`](../../../configuration/pgdog.toml/general.md#default_pool_size) (alias: `max_pool_size`) |
-| [`[general]`](../../../configuration/pgdog.toml/general.md) | [`min_pool_size`](../../../configuration/pgdog.toml/general.md#min_pool_size) |
-| [`[[databases]]`](../../../configuration/pgdog.toml/databases.md) | [`pool_size`](../../../configuration/pgdog.toml/databases.md#pool_size) |
-| [`[[databases]]`](../../../configuration/pgdog.toml/databases.md) | [`min_pool_size`](../../../configuration/pgdog.toml/databases.md#min_pool_size) |
-| [`[[users]]`](../../../configuration/users.toml/users.md) | [`pool_size`](../../../configuration/users.toml/users.md#pool_size) |
-| [`[[users]]`](../../../configuration/users.toml/users.md) | [`min_pool_size`](../../../configuration/users.toml/users.md#min_pool_size) |
+| [`[general]`](../../configuration/pgdog.toml/general.md) | [`default_pool_size`](../../configuration/pgdog.toml/general.md#default_pool_size) (alias: `max_pool_size`) |
+| [`[general]`](../../configuration/pgdog.toml/general.md) | [`min_pool_size`](../../configuration/pgdog.toml/general.md#min_pool_size) |
+| [`[[databases]]`](../../configuration/pgdog.toml/databases.md) | [`pool_size`](../../configuration/pgdog.toml/databases.md#pool_size) |
+| [`[[databases]]`](../../configuration/pgdog.toml/databases.md) | [`min_pool_size`](../../configuration/pgdog.toml/databases.md#min_pool_size) |
+| [`[[users]]`](../../configuration/users.toml/users.md) | [`pool_size`](../../configuration/users.toml/users.md#pool_size) |
+| [`[[users]]`](../../configuration/users.toml/users.md) | [`min_pool_size`](../../configuration/users.toml/users.md#min_pool_size) |
 
 ## Orchestrator integration
 
 Autoscaling actions are performed entirely using the internal PgDog <-> control plane protocol and, therefore, will work with all orchestrators, including Kubernetes, ECS, and manual deployments.
 
 ### Kubernetes
 
-If using autoscaling and deploying PgDog with our [Helm chart](../../../installation.md), make sure to set the pool-related settings to reflect the _total_ number of connections. For example, if deploying 3 replicas and the total pool size across the 3 pods is 600 connections, set it accordingly in `values.yaml`:
+If using autoscaling and deploying PgDog with our [Helm chart](../../installation.md), make sure to set the pool-related settings to reflect the _total_ number of connections. For example, if deploying 3 replicas and the total pool size across the 3 pods is 600 connections, set it accordingly in `values.yaml`:
 
 ```yaml title="values.yaml"
 defaultPoolSize: 600

docs/enterprise_edition/control_plane/ha.md

@@ -26,16 +26,26 @@ Whichever instance acquires the lease first will report itself as `"Ready"` to t
 
 This feature is **disabled** by default. It can be enabled and configured in the Helm chart:
 
-```yaml title="values.yaml"
-control:
-  config:
-    leader:
-      enabled: true
-      lease_name: "control2"
-      lease_duration_secs: 15
-      lease_interval_secs: 5
-      release_timeout_secs: 5
-```
+=== "Helm chart"
+    ```yaml title="values.yaml"
+    control:
+      config:
+        leader:
+          enabled: true
+          lease_name: "control2"
+          lease_duration_secs: 15
+          renew_interval_secs: 5
+          release_timeout_secs: 5
+    ```
+=== "control.toml"
+    ```toml
+    [leader]
+    enabled = true
+    lease_name = "control2"
+    lease_duration_secs = 15
+    renew_interval_secs = 5
+    release_timeout_secs = 5
+    ```
 
 Most of these settings have sane defaults:
 
@@ -44,7 +54,7 @@ Most of these settings have sane defaults:
 | `enabled` | Toggle leader election on or off. It is disabled by default (`false`). |
 | `lease_name` | The name of the `Lease` resource. Change it if you're planning to deploy more than one control plane per namespace. |
 | `lease_duration_secs` | Lease duration. Longer values prevent lease takeover due to clock skew, but slow down redeployments after unexpected pod termination. |
-| `lease_interval_secs` | How often the control plane leader attempts to renew the lease. |
+| `renew_interval_secs` | How often the control plane leader attempts to renew the lease. |
 | `release_timeout_secs` | How long the control plane will wait while shutting down gracefully for the lease to be released. |
 
 ### Default deployment

docs/enterprise_edition/control_plane/index.md

@@ -45,17 +45,18 @@ PgDog nodes that are part of the same deployment should use the same token. It c
     A control plane deployment is capable of managing several PgDog deployments. It's not necessary (although possible) to have one control plane per PgDog deployment.
 
 
-### Connection flow
+## Architecture
 
 <center>
-    <img src="/images/control_plane.png" width="65%" alt="Control plane">
+    <img src="/images/control_plane.png" width="65%" alt="Control plane" class="theme-aware-image">
+    <p>Control plane <-> PgDog connection architecture</p>
 </center>
 
 PgDog initiates a connection to the control plane on startup. This happens in the background and doesn't block queries.
 
 Upon connecting, PgDog will send its node identifier (set in the `NODE_ID` environment variable, or randomly generated) to register with the control plane, and will start uploading telemetry and poll for commands.
 
-#### Error handling
+### Error handling
 
 Since most PgDog functions (including sharding) are configuration-driven, the control plane connection is **not required**
 for PgDog to start or serve queries.
@@ -78,5 +79,5 @@ PgDog transmits the following information to the control plane:
 
 {{ next_steps_links([
     ("Installation", "installation.md", "Deploy the control plane alongside your PgDog nodes and connect them together."),
-    ("Features", "features/index.md", "Explore control plane features like alerts, configuration management, instances, metrics, and Slack integration."),
+    ("Features", "alerts.md", "Explore control plane features like alerts, configuration management, instances, metrics, and Slack integration."),
 ]) }}

docs/enterprise_edition/control_plane/installation.md

@@ -94,9 +94,11 @@ ingress:
 
 ## OAuth2
 
-OAuth2 authentication is supported out of the box for GitHub and Google providers. Either one can be configured as follows:
+OAuth2 authentication is supported out of the box for GitHub and Google providers.
 
-=== "GitHub"
+### GitHub
+
+=== "Helm chart"
     ```yaml title="values.yaml"
     control:
       config:
@@ -108,7 +110,20 @@ OAuth2 authentication is supported out of the box for GitHub and Google provider
             allowed_orgs:
               - acme-corp
     ```
-=== "Google"
+=== "control.toml"
+    ```toml
+    [auth]
+    redirect_base_url = "https://control.acme.com"
+
+    [auth.github]
+    client_id = "Iv1.0123456789abcdef"
+    client_secret = "shhh"
+    allowed_orgs = ["acme-corp"]
+    ```
+
+### Google
+
+=== "Helm chart"
     ```yaml title="values.yaml"
     control:
       config:
@@ -120,6 +135,16 @@ OAuth2 authentication is supported out of the box for GitHub and Google provider
             allowed_domains:
               - acme.com
     ```
+=== "control.toml"
+    ```toml
+    [auth]
+    redirect_base_url = "https://control.acme.com"
+
+    [auth.google]
+    client_id = "0123456789-abc.apps.googleusercontent.com"
+    client_secret = "shhh"
+    allowed_domains = ["acme.com"]
+    ```
 
 The client secret can be alternatively set as an environment variable:
 
@@ -151,25 +176,48 @@ The `Secret` resource should be in the same namespace as the chart release:
 
 The secret can then be referenced in `values.yaml`:
 
-=== "GitHub"
+#### GitHub
+
+=== "Helm chart"
     ```yaml title="values.yaml"
-    github:
-      client_id: Iv1.0123456789abcdef
-      allowed_orgs:
-        - acme-corp
-      secret:
-        name: pgdog-oauth-secrets
-        clientSecretKey: github-client-secret
+    control:
+      config:
+        auth:
+          github:
+            client_id: Iv1.0123456789abcdef
+            allowed_orgs:
+              - acme-corp
+            secret:
+              name: pgdog-oauth-secrets
+              clientSecretKey: github-client-secret
     ```
-=== "Google"
+=== "control.toml"
+    ```toml
+    [auth.github]
+    client_id = "Iv1.0123456789abcdef"
+    allowed_orgs = ["acme-corp"]
+    ```
+
+#### Google
+
+=== "Helm chart"
     ```yaml title="values.yaml"
-    google:
-      client_id: 0123456789-abc.apps.googleusercontent.com
-      allowed_domains:
-        - acme.com
-      secret:
-        name: pgdog-oauth-secrets
-        clientSecretKey: google-client-secret
+    control:
+      config:
+        auth:
+          google:
+            client_id: 0123456789-abc.apps.googleusercontent.com
+            allowed_domains:
+              - acme.com
+            secret:
+              name: pgdog-oauth-secrets
+              clientSecretKey: google-client-secret
+    ```
+=== "control.toml"
+    ```toml
+    [auth.google]
+    client_id = "0123456789-abc.apps.googleusercontent.com"
+    allowed_domains = ["acme.com"]
     ```
 
 The same method can be used to store the `client_id` (using `clientIdKey` as key).
@@ -180,17 +228,38 @@ The same method can be used to store the `client_id` (using `clientIdKey` as key
 
 Both accept a list, so you can allow more than one:
 
-=== "GitHub"
+#### GitHub
+
+=== "Helm chart"
     ```yaml title="values.yaml"
-    github:
-      allowed_orgs:
-        - acme-corp
-        - acme-labs
+    control:
+      config:
+        auth:
+          github:
+            allowed_orgs:
+              - acme-corp
+              - acme-labs
     ```
-=== "Google"
+=== "control.toml"
+    ```toml
+    [auth.github]
+    allowed_orgs = ["acme-corp", "acme-labs"]
+    ```
+
+#### Google
+
+=== "Helm chart"
     ```yaml title="values.yaml"
-    google:
-      allowed_domains:
-        - acme.com
-        - acme.io
+    control:
+      config:
+        auth:
+          google:
+            allowed_domains:
+              - acme.com
+              - acme.io
+    ```
+=== "control.toml"
+    ```toml
+    [auth.google]
+    allowed_domains = ["acme.com", "acme.io"]
     ```