# Dedicated OpenAPI Import Into Premium Status: Proposed Issue: #577 / #590 ## Staging Evidence Read-only staging snapshots were collected before changing the Premium graph. - Global Dedicated CP: `staging-base-us-west-2` - `StatefulSet tidb-management-service/dedicated-global-service` - Image: `385595570414.dkr.ecr.us-west-2.amazonaws.com/tidbcloud/tidb-management-service:release-v0.86-6cdb3496c09bf23d8a7202fc55801d3d5561da83` - `Deployment devops/config-center` - Image: `385595570414.dkr.ecr.us-west-2.amazonaws.com/dbaas/nightly/config-center:e85848b3cb725fdd25af5d3057f0bdd5b477edc6` - Regional Dedicated CP: `staging-seed-us-west-2` - `Deployment cluster-service/cluster-control-server` - Image: `385595570414.dkr.ecr.us-west-2.amazonaws.com/tidbcloud/cluster-control-server:7c3a03e3a447ebdbe649965a38eeab7fb7307252` - `Deployment regional-server-system/regional-server` - Image: `385595570414.dkr.ecr.us-west-2.amazonaws.com/tidbcloud/dedicated-regional-server:7c3a03e3a447ebdbe649965a38eeab7fb7307252` - `Deployment tcidm/regional-tcidm-service` - Image: `385595570414.dkr.ecr.us-west-2.amazonaws.com/tidbcloud/regional-tcidm-service:16191a5eecc8ba7a3e0c9343e7c6a52f6588716a` - `Deployment ticdc-service/ticdc-service-server` - Image: `385595570414.dkr.ecr.us-west-2.amazonaws.com/tidbcloud/ticdc-service:8096fbc0428af686ea17f661e61ba78a8e964b4b` - Crossplane: `crossplane:v1.18.0` - AWS provider family: `provider-family-aws:v1.21.1` plus `provider-aws-{autoscaling,ec2,eks,iam,route53}:v1.21.1` - Legacy provider evidence: `cluster-service/aws-provider-upstream` uses `gcr.io/pingcap-public/crossplane/forked-provider-aws:v0.47.2` - Dedicated CRDs include selected `cloud.pingcap.com`, `dedicated.regionalserver.tidbcloud.com`, and legacy `*.aws.crossplane.io` groups. No `dedicated-dataflow-svc` workload was observed in the read-only staging snapshot. Staging command and args were also captured for imported services and are part of the runtime contract: - `dedicated-global-service`: `/command/dedicated-global-service/dedicated-global-service serve --config=/etc/dedicated-global-service/config.yaml` - `regional-tcidm-service`: `regional_tcidm_service` - `cluster-control-server`: `/server --region=us-west-2 --auth0-domain=tidb-staging.us.auth0.com --auth0-audience=staging-proxy-service --ns-prefix=staging- --use-self-signed-cert-for-tidb-components=true --provider=aws -L=debug` - `dedicated-ticdc-service`: `/manager http --config=/etc/ticdc-service/config.yaml` ## Decision The Premium Session Tiltfile remains the only runtime target. It imports the Dedicated runtime surface into the Premium persona and records every Dedicated candidate in `premium-image-source-summary.json`. - Materialized by default: `dedicated-global-service`, `config-center`, `regional-server`, `cluster-control-server`, `regional-tcidm-service`, `dedicated-ticdc-service`, `dedicated-infra-api-crds`, `dedicated-aws-provider`. - Gated by default: `dedicated-dataflow-svc`. - Dedicated runtime namespace: `cp9-dedicated`. - Dedicated control namespace reservation: `cp9-dedicated-system`. - Dedicated runtime ServiceAccount bindings target `cp9-dedicated`; the imported runtime must not keep historical `cp9-system` RBAC subjects. - `cluster-control-server` still reads `instancetype-config` from its historical `cluster-service` namespace, so Premium materializes that support namespace and ConfigMap separately while keeping the workload itself in `cp9-dedicated`. - Premium metadb fast-start includes idempotent Dedicated bootstraps that create `dedicated_global_service`, `regional_server`, classic `config_center_staging`, and Account dbuser key tables so imported services can run their own migrations on a fresh start. - Dedicated account traffic (including `GetClusterAuthPubKey`) uses the shared real `account-svc` (PRD #571 account unification). `GetClusterAuthPubKey` signs org keys through real AWS KMS using the session's injected AWS credentials; the KMS keys the account service creates carry no cp9 tags, so they are outside the tag-scoped reaper (accepted cost, tracked for inventory visibility). - Crossplane/provider decision: keep Premium's existing Upbound AWS provider family as the default `*.aws.upbound.io` surface, and materialize the isolated legacy Dedicated `provider-aws` deployment for `*.aws.crossplane.io` resources because `regional-server` creates legacy Crossplane CRs during Dedicated cluster lifecycle. Premium sessions grant the workload role the session-scoped Dedicated Crossplane EC2/EKS/IAM surface so this path is reproducible. This keeps the fresh Premium start path on the current fast-start image contract while making the Dedicated import state visible to proof/reporting. ## Source-backed integration point Issue #670 binds the Dedicated import train to PRD #664's unified source-backed model without enabling full Dedicated source builds yet. Imported Dedicated service candidates are represented in `internal/sourcebacked/contracts.json` and in the Premium image-source summary with the same classification vocabulary used by Premium and Starter: `staging-image`, `source-backed`, `gated`, `manifest`, and `always-local-stub` where applicable. The current Dedicated candidates stay gated for source-build selection until a service-specific writer proves the rollout target, image writer, readiness check, and evidence target. Dedicated k3d/control-plane services use the ADR 0011-style backend after import: host build, Tilt-owned image object, binary sync where supported, and process-level restart. The import must not introduce a Dedicated-specific source mode or a second user-facing `live_update_services` opt-in; `source_build_services` remains the only user selection, and CP9 gates live-update capability from the contract registry. No real Dedicated data-plane service is imported by this issue. If a future Dedicated import adds a real data-plane service outside the k3d/control-plane boundary, the default backend is the ADR 0014/0015 image-level path (session-scoped image build/publish, Deployment image patch, rollout check) unless a future PRD explicitly approves another backend. Dedicated OpenAPI proof routes through the Premium public gateway at `/dedicated/v1beta1`, matching the staging Kong-preprocessed Dedicated OpenAPI base path before `tidb-mgmt-portal` strips the prefix. The Premium `tidb-mgmt-service` config points Dedicated calls at the imported `dedicated-global-service:10000`; the old local-only `localhost:10019` address is not valid once Dedicated runs as a separate imported service. The historical `dedicated-full` app-delivery env remains source material for the Premium Tiltfile import. Agents must not route users to a standalone `cp9.dedicated-full.example.yaml` or `proof dedicated-full` target for this train. Live Premium proof kept digest/API-key auth real but found that the portal RBAC check cannot call Account ACL locally because `account-acl-grpc` is intentionally kept at zero replicas until Account ACL honors local mode without Salesforce/job-queue dependencies. The imported Dedicated route therefore keeps the standalone Dedicated boundary of `rbac.localMode=true` in `tidb-mgmt-portal` while `auth.localMode=false`. The Dedicated catalog seed now runs for Premium local and remote k3d sessions, waits for `premium-metadb` in `cp9-system` and `dedicated-global-service` in `cp9-dedicated`, and seeds the Premium local project `1440002001` alongside the historical Dedicated project `200`.