byoc: update onboarding content - #23393
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:
📝 WalkthroughWalkthroughThe BYOC documentation now describes four deployment stages, resource ownership, validation, and customer AWS billing. The AWS preparation guide now requires a subordinate CA signed by an active root CA with at least 20 years of validity. ChangesBYOC deployment documentation
Estimated code review effort: 2 (Simple) | ~10 minutes Suggested reviewers: 🚥 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: 2
ℹ️ Review info
⚙️ Run configuration
Configuration used: Path: .coderabbit.yaml
Review profile: ASSERTIVE
Plan: Pro Plus
Run ID: 8de38a81-895b-4bea-8522-b7e5711404fb
📒 Files selected for processing (2)
tidb-cloud/byoc/byoc-automated-deployment.mdtidb-cloud/byoc/byoc-prepare-environment-aws.md
| ## Deployment overview | ||
|
|
||
| ### Step 1: Image synchronization (approx. 1-2 hours) | ||
| The automated deployment consists of the following stages: |
There was a problem hiding this comment.
📐 Maintainability & Code Quality | 🟡 Minor | ⚡ Quick win
Update the renamed anchor or preserve compatibility.
The new heading creates #deployment-overview, but tidb-cloud/byoc/byoc-prepare-environment-aws.md Line 161 still links to byoc-automated-deployment.md#deployment-process. The link will no longer resolve. Update that link to #deployment-overview, or preserve the old anchor as an explicit alias.
| Therefore, you must prepare a valid subordinate CA in the deployment region. The CA ARN that you provide to TiDB Cloud must be the subordinate CA ARN. To create and activate the subordinate CA, you need an active root CA to sign the subordinate CA certificate. | ||
|
|
||
| 1. **Create a CA.** Follow [Create a private CA in AWS Private CA](https://docs.aws.amazon.com/privateca/latest/userguide/create-CA.html). | ||
| The subordinate CA certificate must be valid for at least **20 years**. Make sure that the root CA used to sign the subordinate CA can support this validity period. |
There was a problem hiding this comment.
🗄️ Data Integrity & Integration | 🟠 Major | 🏗️ Heavy lift
🧩 Analysis chain
🏁 Script executed:
#!/bin/bash
set -euo pipefail
# Locate and inspect the relevant Markdown document and related statements.
FILE="tidb-cloud/byoc/byoc-prepare-environment-aws.md"
if [ -f "$FILE" ]; then
echo "== file exists =="
true
else
echo "missing $FILE"
exit 0
fi
echo "== around lines 85-165 =="
sed -n '85,165p' "$FILE" | nl -ba -v85
echo "== PCA/ARN sharing/search occurrences =="
rg -n -i 'PCA|private certificate authority|subordinate CA|deployment Region|Region|cross|same|shared|ARN|certificate authority' "$FILE"Repository: pingcap/docs
Length of output: 235
🌐 Web query:
AWS Private Certificate Authority CA Regional resource create CA in same Region cannot copy CA across Regions
💡 Result:
AWS Private Certificate Authority (CA) resources are strictly regional [1][2][3]. This means that a CA created in one AWS Region cannot be copied, moved, or replicated to another Region [1][2]. If you require a CA hierarchy or private certificate issuance capabilities across multiple Regions, you must explicitly create and manage separate CAs within each of those Regions [1][4][2]. To achieve a multi-Region setup, you can implement a CA hierarchy by: 1. Creating a root CA in one Region [4][5]. 2. Creating subordinate CAs in the required target Regions [4][5]. 3. Using the root CA in the first Region to sign the certificate signing requests (CSRs) for the subordinate CAs in the other Regions [4][6]. 4. Importing the signed certificates back into their respective Regions to complete the subordinate CA installation [4][6]. This process allows you to maintain a unified PKI structure across different geographic locations while adhering to the regional architecture of the service [4][5][6].
Citations:
- 1: https://docs.aws.amazon.com/privateca/latest/userguide/PcaRegions.html
- 2: https://docs.aws.amazon.com/privateca/latest/userguide/PcaWelcome.html
- 3: https://docs.aws.amazon.com/pdfs/privateca/latest/userguide/privateca-ug.pdf
- 4: https://repost.aws/knowledge-center/private-ca-disaster-recovery
- 5: https://aws.amazon.com/blogs/security/how-to-build-a-ca-hierarchy-across-multiple-aws-accounts-and-regions-for-global-organization/
- 6: https://repost.aws/knowledge-center/acm-pca-ca-install
🏁 Script executed:
#!/bin/bash
set -euo pipefail
FILE="tidb-cloud/byoc/byoc-prepare-environment-aws.md"
if [ -f "$FILE" ]; then
printf '%s\n' "== exact lines 85-165 =="
awk 'NR>=85 && NR<=165 {printf "%5d\t%s\n", NR, $0}' "$FILE"
printf '%s\n' "== PCA/ARN/region search =="
rg -n -i 'PCA|private certificate authority|subordinate CA|deployment region|Region|cross|same|shared|ARN|certificate authority|Certificate Authority|root CA' "$FILE"
else
printf '%s\n' "missing $FILE"
fiRepository: pingcap/docs
Length of output: 12584
Resolve the subordinate CA region-scope contradiction.
Line 93 requires a subordinate CA in the deployment Region, but Line 116 and the summary table row at Line 158 state that the same PCA/ARN can be shared across Regions. AWS Private CA resources are regional, so a single subordinate CA ARN cannot be copied or used across Regions unless TiDB Cloud documents a supported regional replication/chain mechanism.
Define the supported BYOC behavior consistently. If each deployment Region needs its own subordinate CA, remove the cross-region sharing statements and collect one ARN per Region. If customers can use one ARN across Regions, remove “in the deployment region” and document the supported mechanism.
lilin90
added
BYOC
ti-chi-bot
Bot
removed
the
missing-translation-status
|
[APPROVALNOTIFIER] This PR is NOT APPROVED This pull-request has been approved by: The full list of commands accepted by this bot can be found here. DetailsNeeds approval from an approver in each of these files:Approvers can indicate their approval by writing |
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/byoc/byoc-automated-deployment.md (1)
91-91: 🎯 Functional Correctness | 🟠 Major | ⚡ Quick winDescribe billing as beginning when resources become billable.
The current wording implies that AWS billing starts only after the deployment completes. AWS can bill resources during deployment. For example, NAT Gateway charges begin when the gateway is provisioned, and EC2 usage is billed when instances are running. (docs.aws.amazon.com)
- AWS starts charging your account as customer-owned resources become billable during deployment. Charges continue after deployment for resources such as Amazon EKS, EC2, NAT Gateway, load balancers, and storage.As per path instructions, this Markdown issue includes a committable suggestion for the contiguous changed line.
Sources: Path instructions, MCP tools
ℹ️ Review info
⚙️ Run configuration
Configuration used: Path: .coderabbit.yaml
Review profile: ASSERTIVE
Plan: Pro Plus
Run ID: 9a91484c-b5c6-4499-b9be-8243fac8b9d8
📒 Files selected for processing (1)
tidb-cloud/byoc/byoc-automated-deployment.md
There was a problem hiding this comment.
Actionable comments posted: 1
Caution
Some comments are outside the diff and can’t be posted inline due to platform limitations.
⚠️ Outside diff range comments (1)
tidb-cloud/byoc/byoc-automated-deployment.md (1)
78-84: 🎯 Functional Correctness | 🟠 Major | ⚡ Quick winCorrect the billing timing for customer-owned BYOC resources.
“After the automated deployment completes” currently limits the AWS billing note. Steps 2 and 3 deploy VPC, EKS, EC2, NAT Gateway, load balancers, and storage during the process, so billing should not be framed as starting only after completion.
Proposed replacement
- AWS starts charging your account for the customer-owned resources created during deployment, such as Amazon EKS, EC2, NAT Gateway, load balancers, and storage. + AWS charges your account for customer-owned resources as they are provisioned during deployment, such as Amazon EKS, EC2, NAT Gateway, load balancers, and storage.Sources: Path instructions, MCP tools
ℹ️ Review info
⚙️ Run configuration
Configuration used: Path: .coderabbit.yaml
Review profile: ASSERTIVE
Plan: Pro Plus
Run ID: e4e4182a-e324-45c4-96eb-1fb7303656e4
📒 Files selected for processing (1)
tidb-cloud/byoc/byoc-automated-deployment.md
[LGTM Timeline notifier]Timeline:
|
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