kcc-direct-brownfield-types-implementer

Generates KRM types and CRD scaffolding for migrating existing Config Connector resources to direct controllers.

1.1k|377|Updated Apr 8, 2019
One-click install
npx skills add https://github.com/GoogleCloudPlatform/k8s-config-connector --skill kcc-direct-brownfield-types-implementer
Or copy as Structured Prompt for Agent
Please help me install this Agent Skill.
Skill: kcc-direct-brownfield-types-implementer
Source: https://github.com/GoogleCloudPlatform/k8s-config-connector/tree/main/.gemini/skills/kcc-direct-brownfield-types-implementer
Command: npx skills add https://github.com/GoogleCloudPlatform/k8s-config-connector --skill kcc-direct-brownfield-types-implementer

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve?

Migrating existing Terraform/DCL-based Config Connector resources to the direct controller approach requires creating KRM Go types and generation scripts that stay strictly schema-compatible with existing CRDs, which is error-prone when done manually.

Core Features & Use Cases

  • Generation Script Setup: Creates generate.sh scripts that invoke controllerbuilder with pinned proto SHAs to generate types from GCP API definitions.
  • Type Standards Enforcement: Verifies _types.go files meet requirements for copyright headers, kubebuilder CRD labels, +kcc:proto tags, and observedGeneration field types.
  • Schema Compatibility Validation: Ensures no unintended new fields are introduced by running dev/tasks/diff-crds, and mandates reuse of existing reference types from apis/refs/.
  • Use Case: When migrating an existing GCP resource (e.g., a Spanner instance) from a Terraform-based controller to a direct controller, use this Skill to scaffold the types, register the Kind, and generate the CRD YAML.

Quick Start

Ask the assistant to scaffold the KRM types and generate.sh for migrating an existing Config Connector resource to a direct controller, then verify schema compatibility with diff-crds.

Frequently Asked Questions about kcc-direct-brownfield-types-implementer

High-intent search queries and answers about installing and using this skill.

FAQPage Schema
How do I migrate an existing Config Connector resource to a direct controller?

Start by creating a generate.sh script in apis/<service>/v1alpha1 that runs controllerbuilder generate-types with a pinned proto SHA. Then verify the generated _types.go meets labeling and proto-tag standards, register the Kind, and run dev/tasks/generate-crds.

How do I generate KRM types from GCP proto definitions?

Use the controllerbuilder generate-types command with --service, --api-version, --resource, and --proto-source-path flags pointing to a compiled proto descriptor. The generate-proto.sh script compiles and caches the descriptor by SHA.

Why must new direct types avoid adding fields like externalRef or observedState?

At the initial migration stage, the Go type must remain strictly schema-compatible with the existing CRD from the Terraform/DCL-based resource. Adding new fields breaks compatibility; run dev/tasks/diff-crds to confirm no unintended fields appear.

Can I define custom reference types in my resource's _types.go file?

No, you should always reuse existing reference structures from apis/refs/v1beta1, such as ProjectRef, instead of defining duplicates locally. This keeps references consistent across all Config Connector resources.

What kubebuilder labels are required on generated CRD types?

The type definition must include exactly three labels: cnrm.cloud.google.com/managed-by-kcc=true, cnrm.cloud.google.com/system=true, and cnrm.cloud.google.com/stability-level=alpha. These are applied via kubebuilder metadata annotations.