byoc: update network related docs#23353
Conversation
ti-chi-bot
Bot
added
contribution
|
Note Reviews pausedIt looks like this branch is under active development. To avoid overwhelming you with review comments due to an influx of new commits, CodeRabbit has automatically paused this review. You can configure this behavior by changing the Use the following commands to manage reviews:
Use the checkboxes below for quick actions:
📝 WalkthroughWalkthroughAdds BYOC AWS VPC peering CIDR documentation, revises the Premium AWS PrivateLink setup and connection workflow, and corrects BYOC navigation links. ChangesBYOC VPC peering access CIDRs
Premium AWS PrivateLink workflow
BYOC documentation navigation
Estimated code review effort: 2 (Simple) | ~10 minutes Possibly related PRs
Suggested labels: 🚥 Pre-merge checks | ✅ 4 | ❌ 1❌ Failed checks (1 warning)
✅ Passed checks (4 passed)
✨ Finishing Touches🧪 Generate unit tests (beta)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 3
ℹ️ Review info
⚙️ Run configuration
Configuration used: Path: .coderabbit.yaml
Review profile: ASSERTIVE
Plan: Pro Plus
Run ID: 05ce3f9f-7be8-461a-9df1-5d739cc58267
📒 Files selected for processing (2)
tidb-cloud/byoc/configure-aws-vpc-peering-access-cidr.mdtidb-cloud/premium/connect-to-premium-via-aws-private-endpoint.md
| Before you configure allowed access CIDRs, make sure that the following requirements are met: | ||
|
|
||
| - You have a TiDB Cloud BYOC instance. | ||
| - The AWS VPC peering connection for the instance has been created. | ||
| - You know the source CIDR ranges of the application subnets that need to access the instance through VPC peering. |
There was a problem hiding this comment.
🎯 Functional Correctness | 🟠 Major | ⚡ Quick win
Document the required CIDR deconfliction prerequisite.
The prerequisites omit that every network participating in peering must use non-overlapping CIDRs. The upstream BYOC planning guide requires strict deconfliction for the TiDB Cloud VPC, application VPCs, on-premises networks, and VPNs; without this, users can complete this procedure while the peering topology remains unable to route traffic. As per path instructions, the fix is provided as an exact contiguous replacement.
Committable replacement
Before you configure allowed access CIDRs, make sure that the following requirements are met:
- You have a TiDB Cloud BYOC instance.
- The AWS VPC peering connection for the instance has been created.
- You know the source CIDR ranges of the application subnets that need to access the instance through VPC peering.
+- The CIDR ranges of the networks that will be connected through VPC peering are strictly deconflicted and do not overlap.📝 Committable suggestion
‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.
| Before you configure allowed access CIDRs, make sure that the following requirements are met: | |
| - You have a TiDB Cloud BYOC instance. | |
| - The AWS VPC peering connection for the instance has been created. | |
| - You know the source CIDR ranges of the application subnets that need to access the instance through VPC peering. | |
| Before you configure allowed access CIDRs, make sure that the following requirements are met: | |
| - You have a TiDB Cloud BYOC instance. | |
| - The AWS VPC peering connection for the instance has been created. | |
| - You know the source CIDR ranges of the application subnets that need to access the instance through VPC peering. | |
| - The CIDR ranges of the networks that will be connected through VPC peering are strictly deconflicted and do not overlap. |
Source: Path instructions
| After you have accepted the private endpoint connection, you are redirected back to the connection dialog. | ||
| After the private endpoint connection is created, you are redirected back to the connection dialog. | ||
|
|
||
| 1. Wait for the private endpoint connection status to change from **System Checking** to **Active** (approximately 5 minutes). |
There was a problem hiding this comment.
🎯 Functional Correctness | 🟡 Minor | ⚡ Quick win
🧩 Analysis chain
🏁 Script executed:
#!/bin/bash
set -euo pipefail
file="tidb-cloud/premium/connect-to-premium-via-aws-private-endpoint.md"
echo "== file exists =="
[ -f "$file" ] && echo yes || echo no
echo "== relevant status mentions =="
rg -n "System Checking|Pending|Active|Deleting|Failed|status|status" "$file" -i || true
echo "== context around line 179 =="
nl -ba "$file" | sed -n '155,210p'
echo "== file size and top/bottom outline =="
wc -l "$file"
nl -ba "$file" | sed -n '1,80p'
nl -ba "$file" | sed -n '210,280p'Repository: pingcap/docs
Length of output: 1828
🌐 Web query:
TiDB Cloud private endpoint connection status System Checking Pending Active Deleting Failed UI
💡 Result:
In TiDB Cloud, private endpoint connections display their status on the cluster-level Networking or project-level Network Access pages [1][2]. The possible statuses for a private endpoint are as follows: - Pending: The connection is waiting for processing [3][1][2]. - Active: The private endpoint is ready to use. In this state, you cannot edit the private endpoint [3][1][2]. - Deleting: The private endpoint is in the process of being deleted [3][1][2]. - Failed: The creation of the private endpoint has failed. You can typically click Edit in that row to retry the creation [3][1][2]. - Not Configured: The endpoint service has been created, but the private endpoint has not yet been created [3][1][2]. - Discovered (specific to certain cloud providers like Azure): TiDB Cloud has detected your existing private endpoint associated with the endpoint service [4]. Additionally, the transition from System Checking to Active is a common part of the initialization process for these connections [3][1][2]. Separately, private endpoint services—which represent the underlying service infrastructure—have their own statuses, such as Creating, Active, and Deleting [3][1][2].
Citations:
- 1: https://github.com/pingcap/docs/blob/master/tidb-cloud/set-up-private-endpoint-connections.md
- 2: https://docs.pingcap.com/tidbcloud/set-up-private-endpoint-connections/
- 3: https://docs.pingcap.com/tidbcloud/connect-to-premium-via-aws-private-endpoint/?plan=premium
- 4: https://docs.pingcap.com/tidbcloud/set-up-private-endpoint-connections-on-azure/
🌐 Web query:
site:docs.pingcap.com/tidbcloud "System Checking" private endpoint connection
💡 Result:
The System Checking status for a private endpoint connection typically indicates that the platform (such as TiDB Cloud) is in the process of validating or establishing the connection, and it is a normal part of the setup lifecycle [1][2][3]. When setting up private endpoint connections—commonly used with services like TiDB Cloud across major cloud providers (AWS, Azure, Google Cloud, Alibaba Cloud)—the status transition from System Checking to Active usually occurs within approximately 5 minutes [1][2][4][5][6]. Key points regarding this status: - It is a temporary state while the service confirms the configuration [1][5][3]. - No immediate action is usually required other than waiting for the process to complete [1][2][4]. - Once the status changes to Active, the endpoint is ready to use, and connection strings become available in the service's console [1][4][5][6]. - If the status persists in System Checking for an extended period or changes to Failed, you should verify that your cloud provider's networking configurations (such as VPC endpoint settings, security groups, or approval requests) are correctly established [1][7][8]. To verify the underlying status of your private endpoint outside of the application console, you should check your specific cloud provider's management console (e.g., the Networking or Private Endpoint sections in AWS VPC, Azure Portal, etc.) to ensure the connection has been approved and is correctly provisioned [4][7][9][8].
Citations:
- 1: https://docs.pingcap.com/tidbcloud/set-up-private-endpoint-connections/
- 2: https://docs.pingcap.com/tidbcloud/connect-to-premium-via-aws-private-endpoint/
- 3: https://docs.pingcap.com/tidbcloud/set-up-private-endpoint-connections-serverless.md
- 4: https://docs.pingcap.com/tidbcloud/set-up-private-endpoint-connections-on-azure/
- 5: https://docs.pingcap.com/tidbcloud/set-up-private-endpoint-connections-on-google-cloud/
- 6: https://docs.pingcap.com/tidbcloud/connect-to-premium-via-alibaba-cloud-private-endpoint/
- 7: https://docs.pingcap.com/tidbcloud/import-sample-data/
- 8: https://docs.pingcap.com/tidbcloud/set-up-private-endpoint-connections-serverless/
- 9: https://docs.pingcap.com/tidbcloud/set-up-vpc-peering-connections/
🌐 Web query:
site:docs.pingcap.com/tidbcloud "Set up private endpoint connections" "System Checking"
💡 Result:
The System Checking status refers to a transitional state that occurs during the setup of a private endpoint connection, typically when configuring TiDB Cloud clusters [1][2][3][4]. When setting up private endpoint connections (such as AWS PrivateLink, Google Cloud Private Service Connect, or Azure Private Link), the system undergoes a validation and provisioning process [1][2][5]. During this time, the status will display as System Checking [1][2][4]. Key points regarding this process: - Duration: This status generally persists for approximately 5 minutes while the infrastructure validates the connection and makes the endpoint active [1][2][6][3]. - Expected Outcome: Once the process completes successfully, the status should transition to Active, indicating that the connection is ready for use [1][2][5][7]. - Troubleshooting: If the status does not change to Active after a reasonable amount of time, ensure that all preliminary steps—such as configuring security groups, enabling private DNS, or authorizing the endpoint access—have been correctly performed according to the specific platform requirements [1][6][3][4]. If errors occur during the initial configuration (e.g., in Azure), you may need to verify the resource ID or IP address and retry the process [5]. If you are encountering this status, wait for the process to complete or verify that your cloud environment's network settings (like security groups or VPC configurations) allow for the necessary traffic [1][4].
Citations:
- 1: https://docs.pingcap.com/tidbcloud/set-up-private-endpoint-connections/
- 2: https://docs.pingcap.com/tidbcloud/set-up-private-endpoint-connections-on-google-cloud/
- 3: https://docs.pingcap.com/tidbcloud/set-up-private-endpoint-connections-serverless/
- 4: https://docs.pingcap.com/tidbcloud/set-up-private-endpoint-connections-serverless.md
- 5: https://docs.pingcap.com/tidbcloud/set-up-private-endpoint-connections-on-azure/
- 6: https://docs.pingcap.com/tidbcloud/connect-to-premium-via-aws-private-endpoint/
- 7: https://docs.pingcap.com/tidbcloud/connect-to-premium-via-alibaba-cloud-private-endpoint/
🌐 Web query:
"Set up private endpoint connections" "System Checking" "Private endpoint status"
💡 Result:
To set up and manage private endpoint connections in Azure, follow this structured process focusing on configuration, approval, and verification [1][2][3]. Setting Up Private Endpoint Connections 1. Create the Private Endpoint: Navigate to "Private endpoints" in the Azure portal and select "Create" [2]. During configuration, you must select the target resource type (e.g., Microsoft.Web/sites, Azure Storage) and specify the virtual network and subnet [2][4]. Ensure "Network policy for private endpoints" is enabled on the target subnet if required [2]. 2. Approval Methods: - Automatic: If you have appropriate Azure RBAC permissions on the target resource, the connection is approved automatically [1]. - Manual: If you lack sufficient permissions, the request is sent to the target resource owner in a "Pending" state [1][3]. The owner must manually approve it before traffic can flow [1][5]. Checking and Managing Private Endpoint Status To check the status of a connection, navigate to the target resource's "Networking" or "Private endpoint connections" blade in the Azure portal [3][6][7]. - Approved: The connection is established and active [8][5]. - Pending: The connection requires manual approval from the resource owner [1][5]. - Rejected/Removed: The connection is not active and must be remediated or recreated [1][5]. Troubleshooting Connectivity If a connection is "Approved" but connectivity fails, verify the following [9][5]: - DNS Resolution: Ensure the fully qualified domain name (FQDN) resolves to the private IP address assigned to the private endpoint, not a public IP [4][8][7]. This typically involves using Azure Private DNS Zones or correctly configuring your custom DNS servers [4][10][7]. - Network Security Groups (NSGs): Check that outbound rules in your VNet allow traffic to the private endpoint [9]. - Connection Testing: Use tools such as nslookup, ping, or the "Connection troubleshoot" feature in Azure Network Watcher to trace the connection path [9][8]. - Symmetric Routing: For complex topologies involving NVAs or Azure Firewall, ensure return traffic follows the same path as the outbound request [7]. For further diagnosis, use the "Metrics" tab on the private endpoint resource to see if data is flowing [9]. If the state remains "Pending" or "Updating" for an extended period, verify RBAC permissions for the approver [5].
Citations:
- 1: https://learn.microsoft.com/en-us/azure/private-link/manage-private-endpoint
- 2: https://learn.microsoft.com/en-us/azure/private-link/create-private-endpoint-portal
- 3: https://learn.microsoft.com/en-us/azure/api-management/private-endpoint
- 4: https://learn.microsoft.com/en-us/azure/storage/common/storage-private-endpoints
- 5: https://howtofixme.com/microsoft/posts/how-to-fix-azure-private-link.html
- 6: https://learn.microsoft.com/en-us/azure/data-explorer/security-network-private-endpoint-troubleshoot
- 7: https://github.com/MicrosoftDocs/sql-docs/blob/live/azure-sql/database/troubleshoot-common-errors-issues.md
- 8: https://www.getorchestra.io/guides/how-to-validate-private-link-connections-in-azure
- 9: https://learn.microsoft.com/en-us/troubleshoot/azure/private-link/troubleshoot-private-endpoint-connectivity-problems
- 10: https://learn.microsoft.com/en-us/azure/azure-functions/functions-create-vnet
🌐 Web query:
site:github.com/pingcap/docs "Set up private endpoint connections" "System Checking" "Pending"
💡 Result:
The status "System Checking" in the context of setting up private endpoint connections (specifically within TiDB Cloud) indicates that the platform is currently verifying the status or configuration of the network connection request [1][2][3]. When you initiate a private endpoint or VPC peering connection in TiDB Cloud, the connection typically moves into this "System Checking" state while the backend systems validate the request [1][2][3]. Key points regarding this process: - Duration: This verification process usually takes approximately 5 minutes [1][2][3]. - Next Steps: You should wait for the status to change from "System Checking" to "Active" [1][2][3]. Once the status is "Active," the connection is ready for use, and you can proceed to retrieve connection strings or perform operations [1][2][3]. - Other Statuses: If the process encounters issues, you might see a "Failed" status, which may allow you to edit and retry the configuration [1][2]. Additionally, in some cloud environments (like Azure), you may need to manually approve the endpoint connection request in your cloud provider's portal for the process to complete successfully [4]. If your connection remains in "System Checking" for an extended period, it is recommended to refresh your dashboard or consult the specific cloud provider's console (e.g., AWS VPC console or Azure Private Endpoint connections page) to ensure there are no pending approval requests or manual configuration steps required on that side [3][4].
Citations:
- 1: https://github.com/pingcap/docs/blob/master/tidb-cloud/set-up-private-endpoint-connections.md
- 2: https://github.com/pingcap/docs/blob/master/tidb-cloud/set-up-private-endpoint-connections-on-google-cloud.md
- 3: https://github.com/pingcap/docs/blob/master/tidb-cloud/set-up-vpc-peering-connections.md
- 4: https://github.com/pingcap/docs/blob/master/tidb-cloud/import-csv-files.md
Update the status reference to include the startup state.
System Checking is the expected initial private endpoint connection status before it reaches Active, but the status reference near line 193 only lists Pending, Active, Deleting, and Failed. Add this status to the private endpoint status list for consistency.
lilin90
added
BYOC
ti-chi-bot
Bot
removed
the
missing-translation-status
lilin90
changed the title
There was a problem hiding this comment.
Caution
Some comments are outside the diff and can’t be posted inline due to platform limitations.
⚠️ Outside diff range comments (1)
tidb-cloud/premium/connect-to-premium-via-aws-private-endpoint.md (1)
29-29: 🎯 Functional Correctness | 🟡 Minor | ⚡ Quick winClarify the scope of each required role.
“Role of the target instance” incorrectly scopes the organization- and project-level roles.
Committable replacement
-- Only users with the `Organization Owner`, `Project Owner`, or `Instance Owner` role of the target instance can create private endpoint connections. +- Only users with the `Organization Owner` role, the `Project Owner` role of the target project, or the `Instance Owner` role of the target instance can create private endpoint connections.As per path instructions, this is an exact replacement for the contiguous Markdown line.
Source: Path instructions
ℹ️ Review info
⚙️ Run configuration
Configuration used: Path: .coderabbit.yaml
Review profile: ASSERTIVE
Plan: Pro Plus
Run ID: 566131e6-8dbe-4b79-86d8-5078e27e86c1
📒 Files selected for processing (1)
tidb-cloud/premium/connect-to-premium-via-aws-private-endpoint.md
[LGTM Timeline notifier]Timeline:
|
|
/approve |
|
[APPROVALNOTIFIER] This PR is APPROVED This pull-request has been approved by: lilin90 The full list of commands accepted by this bot can be found here. The pull request process is described here DetailsNeeds approval from an approver in each of these files:
Approvers can indicate their approval by writing |
lilin90
added
do-not-merge/hold
2 participants
First-time contributors' checklist
What is changed, added or deleted? (Required)
Which TiDB version(s) do your changes apply to? (Required)
Tips for choosing the affected version(s):
By default, CHOOSE MASTER ONLY so your changes will be applied to the next TiDB major or minor releases. If your PR involves a product feature behavior change or a compatibility change, CHOOSE THE AFFECTED RELEASE BRANCH(ES) AND MASTER.
For details, see tips for choosing the affected versions.
What is the related PR or file link(s)?
AI agent involvement
Do your changes match any of the following descriptions?
Summary by CodeRabbit