{"owner":"kubernetes","repo":"kops","hasSkills":true,"totalSkillsCount":7,"totalTokensCount":4725,"categories":["gemini-rule","plugin-manifest","anthropic-skill","root-instruction"],"hasMcp":false,"mcpConfig":null,"found":["discovery/GEMINI.md","tools/metal/dhcp/README.md","channels/packages/operator.coredns.addons.x-k8s.io/0.1.0-kops.1/manifest.yaml","vendor/github.com/google/gnostic-models/extensions/README.md","AGENTS.md","GEMINI.md","tools/metal/storage/README.md"],"skills":{"discovery/GEMINI.md":"# Discovery Service Project\n\n## Overview\nThis project implements a public discovery service designed for decentralized, secure peer discovery. The core innovation is the use of **Custom Certificate Authorities (CAs)** to define isolated \"Universes\". Clients register and discover peers within their own Universe, identified and secured purely by mTLS.\n\nThe service emulates a Kubernetes API, allowing interaction via `kubectl`, including support for **Server-Side Apply**.\n\n## Key Concepts\n\n### 1. The \"Universe\"\n- A **Universe** is an isolated scope for peer discovery.\n- It is cryptographically defined by the **SHA256 hash of the Root CA's Public Key**.\n- Any client possessing a valid certificate signed by a specific CA belongs to that CA's Universe.\n- Different CAs = Different Universes. There is no crossover.\n\n### 2. Authentication & Authorization\n- **Mechanism**: Mutual TLS (mTLS).\n- **Client Identity**: Derived from the **Common Name (CN)** of the leaf certificate.\n- **Universe Context**: Derived from the **Root CA** presented in the TLS handshake.\n- **Requirement**: Clients **MUST** present the full certificate chain (Leaf + Root CA) during the handshake. The server does not maintain a pre-configured trust store for these custom CAs; it uses the presented chain to determine the scope.\n\n### 3. API Resources\n- **DiscoveryEndpoint** (`discovery.kops.k8s.io/v1alpha1`): Represents a peer in the discovery network. Can optionally hold OIDC configuration (Issuer URL, JWKS).\n- **Validation**: A client with CN `client1` can only Create/Update a `DiscoveryEndpoint` named `client1`.\n- **Apply Support**: The server supports `PATCH` requests to facilitate `kubectl apply --server-side`.\n\n### 4. OIDC Discovery\nThe server acts as an OIDC Discovery Provider for the Universe.\n- **Public Endpoints**:\n - `/.well-known/openid-configuration`: Returns the OIDC discovery document.\n - `/openid/v1/jwks`: Returns the JSON Web Key Set (JWKS).\n- **Data Source**: These endpoints serve data uploaded by clients via the `DiscoveryEndpoint` resource.\n\n## Architecture\n\n### Project Structure\n- `cmd/discovery-server/`: Main entry point. Wires up the HTTP server with TLS configuration.\n- `pkg/discovery/`:\n - `auth.go`: logic for inspecting TLS `PeerCertificates` to extract the Universe ID (CA hash) and Client ID.\n - `store.go`: In-memory thread-safe storage (`MemoryStore`) mapping Universe IDs to lists of `DiscoveryEndpoint` objects.\n - `server.go`: HTTP handlers implementing the K8s API emulation for `/apis/discovery.kops.k8s.io/v1alpha1`.\n - `k8s_types.go`: Definitions of `DiscoveryEndpoint`, `DiscoveryEndpointList`, `TypeMeta`, `ObjectMeta` etc.\n\n### Data Model\n- **DiscoveryEndpoint**: The core resource. Contains `Spec.Addresses` and metadata.\n- **Universe**: Contains a map of `DiscoveryEndpoint` objects (keyed by name).\n- **Unified Types**: The API type `DiscoveryEndpoint` is used directly for in-memory storage, ensuring zero conversion overhead.\n\n## Security Model\n- **Trust Delegation**: The server delegates trust to the CA. If you hold the CA key, you control the Universe.\n- **Isolation**: The server ensures that a client presenting a cert chain for `CA_A` cannot read or write data to the Universe defined by `CA_B`.\n- **Ephemeral**: The current implementation uses in-memory storage. Data is lost on restart.\n\n## Building and Running\n\n### Build\n```bash\ngo build ./cmd/discovery-server\n```\n\n### Run\n\nSee docs/walkthrough.md for instructions on testing functionality.\n","tools/metal/dhcp/README.md":"A very simple DHCP server to support our testing of bare metal / VMs.\n\nMAC addresses map to IP addresses, so x:x:x:x:x:7 => x.x.x.7\n\n(Remember that the MAC address is in hex, and IP addresses are normally printed in decimal! So `:10` => `.16`)","channels/packages/operator.coredns.addons.x-k8s.io/0.1.0-kops.1/manifest.yaml":"apiVersion: rbac.authorization.k8s.io/v1\nkind: ClusterRole\nmetadata:\n labels:\n addonmanager.kubernetes.io/mode: EnsureExists\n kubernetes.io/bootstrapping: rbac-defaults\n kubernetes.io/cluster-service: \"true\"\n kubernetes.io/name: CoreDNS\n name: system:coredns\nrules:\n- apiGroups:\n - \"\"\n resources:\n - endpoints\n - services\n - pods\n - namespaces\n verbs:\n - list\n - watch\n- apiGroups:\n - \"\"\n resources:\n - nodes\n verbs:\n - get\n---\napiVersion: rbac.authorization.k8s.io/v1\nkind: ClusterRoleBinding\nmetadata:\n annotations:\n rbac.authorization.kubernetes.io/autoupdate: \"true\"\n labels:\n addonmanager.kubernetes.io/mode: EnsureExists\n kubernetes.io/bootstrapping: rbac-defaults\n kubernetes.io/cluster-service: \"true\"\n kubernetes.io/name: CoreDNS\n name: system:coredns\nroleRef:\n apiGroup: rbac.authorization.k8s.io\n kind: ClusterRole\n name: system:coredns\nsubjects:\n- kind: ServiceAccount\n name: coredns\n namespace: kube-system\n---\napiVersion: apiextensions.k8s.io/v1\nkind: CustomResourceDefinition\nmetadata:\n annotations:\n controller-gen.kubebuilder.io/version: v0.2.5\n creationTimestamp: null\n name: coredns.addons.x-k8s.io\nspec:\n group: addons.x-k8s.io\n names:\n kind: CoreDNS\n listKind: CoreDNSList\n plural: coredns\n singular: coredns\n scope: Namespaced\n versions:\n - name: v1alpha1\n schema:\n openAPIV3Schema:\n description: CoreDNS is the Schema for the coredns API\n properties:\n apiVersion:\n description: 'APIVersion defines the versioned schema of this representation\n of an object. Servers should convert recognized schemas to the latest\n internal value, and may reject unrecognized values. More info: https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#resources'\n type: string\n kind:\n description: 'Kind is a string value representing the REST resource this\n object represents. Servers may infer this from the endpoint the client\n submits requests to. Cannot be updated. In CamelCase. More info: https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#types-kinds'\n type: string\n metadata:\n type: object\n spec:\n description: CoreDNSSpec defines the desired state of CoreDNS\n properties:\n channel:\n description: 'Channel specifies a channel that can be used to resolve\n a specific addon, eg: stable It will be ignored if Version is specified'\n type: string\n corefile:\n type: string\n dnsDomain:\n type: string\n dnsIP:\n type: string\n patches:\n items:\n type: object\n type: array\n version:\n description: Version specifies the exact addon version to be deployed,\n eg 1.2.3 It should not be specified if Channel is specified\n type: string\n type: object\n status:\n description: CoreDNSStatus defines the observed state of CoreDNS\n properties:\n errors:\n items:\n type: string\n type: array\n healthy:\n type: boolean\n required:\n - healthy\n type: object\n type: object\n served: true\n storage: true\n subresources:\n status: {}\n\n---\n\napiVersion: v1\nkind: Namespace\nmetadata:\n name: coredns-system\n---\napiVersion: v1\nkind: ServiceAccount\nmetadata:\n labels:\n k8s-app: coredns-operator\n name: coredns-operator\n namespace: coredns-system\n---\napiVersion: rbac.authorization.k8s.io/v1\nkind: ClusterRole\nmetadata:\n name: coredns-operator\nrules:\n- apiGroups:\n - \"\"\n resourceNames:\n - coredns\n resources:\n - configmaps\n - serviceaccounts\n - services\n verbs:\n - delete\n - patch\n - update\n- apiGroups:\n - \"\"\n resources:\n - configmaps\n - serviceaccounts\n - services\n verbs:\n - create\n- apiGroups:\n - apps\n - extensions\n resources:\n - deployments\n verbs:\n - get\n - list\n - watch\n- apiGroups:\n - apps\n - extensions\n resourceNames:\n - coredns\n resources:\n - deployments\n verbs:\n - delete\n - patch\n - update\n- apiGroups:\n - apps\n - extensions\n resources:\n - deployments\n verbs:\n - create\n- apiGroups:\n - \"\"\n resources:\n - events\n verbs:\n - create\n - patch\n- apiGroups:\n - \"\"\n resources:\n - configmaps\n - serviceaccounts\n - services\n verbs:\n - get\n - list\n - watch\n- apiGroups:\n - addons.x-k8s.io\n resources:\n - coredns\n verbs:\n - get\n - list\n - patch\n - update\n - watch\n- apiGroups:\n - addons.x-k8s.io\n resources:\n - coredns/status\n verbs:\n - get\n - patch\n - update\n- apiGroups:\n - coordination.k8s.io\n resources:\n - leases\n verbs:\n - get\n - list\n - watch\n - create\n - update\n - patch\n - delete\n---\napiVersion: rbac.authorization.k8s.io/v1\nkind: ClusterRoleBinding\nmetadata:\n labels:\n k8s-app: coredns-operator\n name: coredns-system:coredns-operator\nroleRef:\n apiGroup: rbac.authorization.k8s.io\n kind: ClusterRole\n name: coredns-operator\nsubjects:\n- kind: ServiceAccount\n name: coredns-operator\n namespace: coredns-system\n---\napiVersion: apps/v1\nkind: Deployment\nmetadata:\n labels:\n k8s-app: coredns-operator\n name: coredns-operator\n namespace: coredns-system\nspec:\n replicas: 1\n selector:\n matchLabels:\n k8s-app: coredns-operator\n template:\n metadata:\n labels:\n k8s-app: coredns-operator\n spec:\n containers:\n - args:\n - --leader-elect=false\n - --rbac-mode=ignore\n command:\n - /manager\n image: justinsb/coredns-operator:latest\n name: manager\n resources:\n limits:\n cpu: 100m\n memory: 30Mi\n requests:\n cpu: 100m\n memory: 20Mi\n serviceAccountName: coredns-operator\n terminationGracePeriodSeconds: 10\n","vendor/github.com/google/gnostic-models/extensions/README.md":"# Extensions\n\n**Extension Support is experimental.**\n\nThis directory contains support code for building Gnostic extensio handlers and\nassociated examples.\n\nExtension handlers can be used to compile vendor or specification extensions\ninto protocol buffer structures.\n\nLike plugins, extension handlers are built as separate executables. Extension\nbodies are written to extension handlers as serialized\nExtensionHandlerRequests.\n","AGENTS.md":"# kOps Project Overview\n\nkOps is a command-line tool for creating, destroying, upgrading, and maintaining production-grade, highly available Kubernetes clusters. It is written in Go and supports multiple cloud providers, including AWS, GCP, DigitalOcean, Hetzner, OpenStack, and Azure.\n\nThe project is well-structured, with a clear separation of concerns between the different packages. The `cmd` directory contains the main entry points for the `kops` CLI and other related commands. The `pkg` directory contains the core logic for managing clusters, and the `upup` directory contains the code for provisioning cloud infrastructure.\n\nThe project has a comprehensive test suite, including unit tests, integration tests, and end-to-end tests. It also has a robust CI/CD pipeline that runs these tests on every pull request.\n\n## Building and Running\n\n### Prerequisites\n\n* `make`\n\n### Building\n\nTo build the `kops` binary, run the following command:\n\n```bash\nmake kops\n```\n\nThis will create the `kops` binary in the `.build/dist//` directory.\n\nTo build all the binaries, including `kops`, `nodeup`, and `channels`, run the following command:\n\n```bash\nmake all\n```\n\n### Running\n\nTo run the `kops` binary, you can either run it directly from the `dist` directory or install it to your `$GOPATH/bin` directory by running the following command:\n\n```bash\nmake install\n```\n\n### Testing\n\nTo run the unit tests, run the following command:\n\n```bash\nmake test\n```\n\nTo run the verification scripts, run the following command:\n\n```bash\nmake verify\n```\n\nTo run the full suite of CI checks, run the following command:\n\n```bash\nmake ci\n```\n\n## Development Conventions\n\n### Guidelines for Programming Assistance\n\nWhen assisting with programming tasks, you will adhere to the following principles:\n\n* **Follow Requirements**: Carefully follow the user's requirements to the letter.\n* **Plan First**: For any non-trivial change, first describe a detailed, step-by-step plan, including the files you intend to modify and the tests you will add or update.\n* **Test Thoroughly**: Implement comprehensive tests to ensure correctness and prevent regressions.\n* **Comment Intelligently**: Add comments to explain the \"why\" behind complex or non-obvious code, keeping in mind that the reader may not be a Kubernetes expert.\n* **No TODOs**: Leave no `TODO` comments, placeholders, or incomplete implementations.\n* **Prioritize Correctness**: Always prioritize security, scalability, and maintainability in your implementations.\n\n### Avoiding Loops\n\nWhen performing complex tasks, especially those involving code modifications and verification, it's important to avoid getting into loops. A loop can occur when the agent repeatedly tries the same action without success, or when it gets stuck in a cycle of analysis, action, and failure.\n\nTo avoid loops:\n* **Analyze the problem carefully**: Before taking any action, make sure you understand the problem and have a clear plan to solve it.\n* **Break down the problem**: Break down complex problems into smaller, more manageable steps.\n* **Verify each step**: After each step, verify that it was successful before moving on to the next one.\n* **Don't repeat failed actions**: If an action fails, don't just repeat it. Analyze the cause of the failure and try a different approach.\n* **Ask for help**: If you're stuck, don't hesitate to ask for help from the user.\n\n### Code Style\n\nThe project follows the standard Go code style and the official [Kubernetes coding conventions](https://www.k8s.dev/docs/guide/coding-convention/). All code should be formatted with `gofmt` and `goimports`. You can format the code by running the following commands:\n\n```bash\nmake gofmt\nmake goimports\n```\n\n### Linting\n\nThe project uses `golangci-lint` to lint the code. You can run the linter by running the following command:\n\n```bash\nmake verify-golangci-lint\n```\n\n### Dependencies\n\nThe project uses Go modules to manage dependencies. To add a new dependency, add it to the `go.mod` file and then run the following command:\n\n```bash\nmake gomod\n```\n\n### Commits\n\nThe project follows the conventional commit message format.\n\n### Contributions\n\nContributions are welcome! Before submitting a pull request, please open an issue to discuss your proposed changes. All pull requests must be reviewed and approved by a maintainer before they can be merged.\n\n## E2E CI Failure Troubleshooting\n\nFor investigating E2E CI job failures — including locating artifacts, diagnosing root causes, and finding correlations across failing jobs — see [docs/e2e-failure-troubleshooting.md](docs/e2e-failure-troubleshooting.md).\n\n## Updating Third-Party Dependencies\n\nFor updating any pinned third-party dependency — Go modules, addon manifests, node components,\nGitHub Actions, e2e scenario charts, and the regeneration/verification each one requires — see\n[docs/dependency-updates.md](docs/dependency-updates.md).\n","GEMINI.md":"# kOps Project Overview\n\nkOps is a command-line tool for creating, destroying, upgrading, and maintaining production-grade, highly available Kubernetes clusters. It is written in Go and supports multiple cloud providers, including AWS, GCP, DigitalOcean, Hetzner, OpenStack, and Azure.\n\nThe project is well-structured, with a clear separation of concerns between the different packages. The `cmd` directory contains the main entry points for the `kops` CLI and other related commands. The `pkg` directory contains the core logic for managing clusters, and the `upup` directory contains the code for provisioning cloud infrastructure.\n\nThe project has a comprehensive test suite, including unit tests, integration tests, and end-to-end tests. It also has a robust CI/CD pipeline that runs these tests on every pull request.\n\n## Building and Running\n\n### Prerequisites\n\n* `make`\n\n### Building\n\nTo build the `kops` binary, run the following command:\n\n```bash\nmake kops\n```\n\nThis will create the `kops` binary in the `.build/dist//` directory.\n\nTo build all the binaries, including `kops`, `nodeup`, and `channels`, run the following command:\n\n```bash\nmake all\n```\n\n### Running\n\nTo run the `kops` binary, you can either run it directly from the `dist` directory or install it to your `$GOPATH/bin` directory by running the following command:\n\n```bash\nmake install\n```\n\n### Testing\n\nTo run the unit tests, run the following command:\n\n```bash\nmake test\n```\n\nTo run the verification scripts, run the following command:\n\n```bash\nmake verify\n```\n\nTo run the full suite of CI checks, run the following command:\n\n```bash\nmake ci\n```\n\n## Development Conventions\n\n### Guidelines for Programming Assistance\n\nWhen assisting with programming tasks, you will adhere to the following principles:\n\n* **Follow Requirements**: Carefully follow the user's requirements to the letter.\n* **Plan First**: For any non-trivial change, first describe a detailed, step-by-step plan, including the files you intend to modify and the tests you will add or update.\n* **Test Thoroughly**: Implement comprehensive tests to ensure correctness and prevent regressions.\n* **Comment Intelligently**: Add comments to explain the \"why\" behind complex or non-obvious code, keeping in mind that the reader may not be a Kubernetes expert.\n* **No TODOs**: Leave no `TODO` comments, placeholders, or incomplete implementations.\n* **Prioritize Correctness**: Always prioritize security, scalability, and maintainability in your implementations.\n\n### Avoiding Loops\n\nWhen performing complex tasks, especially those involving code modifications and verification, it's important to avoid getting into loops. A loop can occur when the agent repeatedly tries the same action without success, or when it gets stuck in a cycle of analysis, action, and failure.\n\nTo avoid loops:\n* **Analyze the problem carefully**: Before taking any action, make sure you understand the problem and have a clear plan to solve it.\n* **Break down the problem**: Break down complex problems into smaller, more manageable steps.\n* **Verify each step**: After each step, verify that it was successful before moving on to the next one.\n* **Don't repeat failed actions**: If an action fails, don't just repeat it. Analyze the cause of the failure and try a different approach.\n* **Ask for help**: If you're stuck, don't hesitate to ask for help from the user.\n\n### Code Style\n\nThe project follows the standard Go code style and the official [Kubernetes coding conventions](https://www.k8s.dev/docs/guide/coding-convention/). All code should be formatted with `gofmt` and `goimports`. You can format the code by running the following commands:\n\n```bash\nmake gofmt\nmake goimports\n```\n\n### Linting\n\nThe project uses `golangci-lint` to lint the code. You can run the linter by running the following command:\n\n```bash\nmake verify-golangci-lint\n```\n\n### Dependencies\n\nThe project uses Go modules to manage dependencies. To add a new dependency, add it to the `go.mod` file and then run the following command:\n\n```bash\nmake gomod\n```\n\n### Commits\n\nThe project follows the conventional commit message format.\n\n### Contributions\n\nContributions are welcome! Before submitting a pull request, please open an issue to discuss your proposed changes. All pull requests must be reviewed and approved by a maintainer before they can be merged.\n\n## E2E CI Failure Troubleshooting\n\nFor investigating E2E CI job failures — including locating artifacts, diagnosing root causes, and finding correlations across failing jobs — see [docs/e2e-failure-troubleshooting.md](docs/e2e-failure-troubleshooting.md).\n\n## Updating Third-Party Dependencies\n\nFor updating any pinned third-party dependency — Go modules, addon manifests, node components,\nGitHub Actions, e2e scenario charts, and the regeneration/verification each one requires — see\n[docs/dependency-updates.md](docs/dependency-updates.md).\n","tools/metal/storage/README.md":"A very simple s3 mock to support our testing of bare metal / VMs.\n\nJust enough functionality to support our tests.\n\nWARNING: This component is not intended for real-world deployment. DO NOT USE for production.\n"},"files":{"discovery/GEMINI.md":"# Discovery Service Project\n\n## Overview\nThis project implements a public discovery service designed for decentralized, secure peer discovery. The core innovation is the use of **Custom Certificate Authorities (CAs)** to define isolated \"Universes\". Clients register and discover peers within their own Universe, identified and secured purely by mTLS.\n\nThe service emulates a Kubernetes API, allowing interaction via `kubectl`, including support for **Server-Side Apply**.\n\n## Key Concepts\n\n### 1. The \"Universe\"\n- A **Universe** is an isolated scope for peer discovery.\n- It is cryptographically defined by the **SHA256 hash of the Root CA's Public Key**.\n- Any client possessing a valid certificate signed by a specific CA belongs to that CA's Universe.\n- Different CAs = Different Universes. There is no crossover.\n\n### 2. Authentication & Authorization\n- **Mechanism**: Mutual TLS (mTLS).\n- **Client Identity**: Derived from the **Common Name (CN)** of the leaf certificate.\n- **Universe Context**: Derived from the **Root CA** presented in the TLS handshake.\n- **Requirement**: Clients **MUST** present the full certificate chain (Leaf + Root CA) during the handshake. The server does not maintain a pre-configured trust store for these custom CAs; it uses the presented chain to determine the scope.\n\n### 3. API Resources\n- **DiscoveryEndpoint** (`discovery.kops.k8s.io/v1alpha1`): Represents a peer in the discovery network. Can optionally hold OIDC configuration (Issuer URL, JWKS).\n- **Validation**: A client with CN `client1` can only Create/Update a `DiscoveryEndpoint` named `client1`.\n- **Apply Support**: The server supports `PATCH` requests to facilitate `kubectl apply --server-side`.\n\n### 4. OIDC Discovery\nThe server acts as an OIDC Discovery Provider for the Universe.\n- **Public Endpoints**:\n - `/.well-known/openid-configuration`: Returns the OIDC discovery document.\n - `/openid/v1/jwks`: Returns the JSON Web Key Set (JWKS).\n- **Data Source**: These endpoints serve data uploaded by clients via the `DiscoveryEndpoint` resource.\n\n## Architecture\n\n### Project Structure\n- `cmd/discovery-server/`: Main entry point. Wires up the HTTP server with TLS configuration.\n- `pkg/discovery/`:\n - `auth.go`: logic for inspecting TLS `PeerCertificates` to extract the Universe ID (CA hash) and Client ID.\n - `store.go`: In-memory thread-safe storage (`MemoryStore`) mapping Universe IDs to lists of `DiscoveryEndpoint` objects.\n - `server.go`: HTTP handlers implementing the K8s API emulation for `/apis/discovery.kops.k8s.io/v1alpha1`.\n - `k8s_types.go`: Definitions of `DiscoveryEndpoint`, `DiscoveryEndpointList`, `TypeMeta`, `ObjectMeta` etc.\n\n### Data Model\n- **DiscoveryEndpoint**: The core resource. Contains `Spec.Addresses` and metadata.\n- **Universe**: Contains a map of `DiscoveryEndpoint` objects (keyed by name).\n- **Unified Types**: The API type `DiscoveryEndpoint` is used directly for in-memory storage, ensuring zero conversion overhead.\n\n## Security Model\n- **Trust Delegation**: The server delegates trust to the CA. If you hold the CA key, you control the Universe.\n- **Isolation**: The server ensures that a client presenting a cert chain for `CA_A` cannot read or write data to the Universe defined by `CA_B`.\n- **Ephemeral**: The current implementation uses in-memory storage. Data is lost on restart.\n\n## Building and Running\n\n### Build\n```bash\ngo build ./cmd/discovery-server\n```\n\n### Run\n\nSee docs/walkthrough.md for instructions on testing functionality.\n","tools/metal/dhcp/README.md":"A very simple DHCP server to support our testing of bare metal / VMs.\n\nMAC addresses map to IP addresses, so x:x:x:x:x:7 => x.x.x.7\n\n(Remember that the MAC address is in hex, and IP addresses are normally printed in decimal! So `:10` => `.16`)","channels/packages/operator.coredns.addons.x-k8s.io/0.1.0-kops.1/manifest.yaml":"apiVersion: rbac.authorization.k8s.io/v1\nkind: ClusterRole\nmetadata:\n labels:\n addonmanager.kubernetes.io/mode: EnsureExists\n kubernetes.io/bootstrapping: rbac-defaults\n kubernetes.io/cluster-service: \"true\"\n kubernetes.io/name: CoreDNS\n name: system:coredns\nrules:\n- apiGroups:\n - \"\"\n resources:\n - endpoints\n - services\n - pods\n - namespaces\n verbs:\n - list\n - watch\n- apiGroups:\n - \"\"\n resources:\n - nodes\n verbs:\n - get\n---\napiVersion: rbac.authorization.k8s.io/v1\nkind: ClusterRoleBinding\nmetadata:\n annotations:\n rbac.authorization.kubernetes.io/autoupdate: \"true\"\n labels:\n addonmanager.kubernetes.io/mode: EnsureExists\n kubernetes.io/bootstrapping: rbac-defaults\n kubernetes.io/cluster-service: \"true\"\n kubernetes.io/name: CoreDNS\n name: system:coredns\nroleRef:\n apiGroup: rbac.authorization.k8s.io\n kind: ClusterRole\n name: system:coredns\nsubjects:\n- kind: ServiceAccount\n name: coredns\n namespace: kube-system\n---\napiVersion: apiextensions.k8s.io/v1\nkind: CustomResourceDefinition\nmetadata:\n annotations:\n controller-gen.kubebuilder.io/version: v0.2.5\n creationTimestamp: null\n name: coredns.addons.x-k8s.io\nspec:\n group: addons.x-k8s.io\n names:\n kind: CoreDNS\n listKind: CoreDNSList\n plural: coredns\n singular: coredns\n scope: Namespaced\n versions:\n - name: v1alpha1\n schema:\n openAPIV3Schema:\n description: CoreDNS is the Schema for the coredns API\n properties:\n apiVersion:\n description: 'APIVersion defines the versioned schema of this representation\n of an object. Servers should convert recognized schemas to the latest\n internal value, and may reject unrecognized values. More info: https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#resources'\n type: string\n kind:\n description: 'Kind is a string value representing the REST resource this\n object represents. Servers may infer this from the endpoint the client\n submits requests to. Cannot be updated. In CamelCase. More info: https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#types-kinds'\n type: string\n metadata:\n type: object\n spec:\n description: CoreDNSSpec defines the desired state of CoreDNS\n properties:\n channel:\n description: 'Channel specifies a channel that can be used to resolve\n a specific addon, eg: stable It will be ignored if Version is specified'\n type: string\n corefile:\n type: string\n dnsDomain:\n type: string\n dnsIP:\n type: string\n patches:\n items:\n type: object\n type: array\n version:\n description: Version specifies the exact addon version to be deployed,\n eg 1.2.3 It should not be specified if Channel is specified\n type: string\n type: object\n status:\n description: CoreDNSStatus defines the observed state of CoreDNS\n properties:\n errors:\n items:\n type: string\n type: array\n healthy:\n type: boolean\n required:\n - healthy\n type: object\n type: object\n served: true\n storage: true\n subresources:\n status: {}\n\n---\n\napiVersion: v1\nkind: Namespace\nmetadata:\n name: coredns-system\n---\napiVersion: v1\nkind: ServiceAccount\nmetadata:\n labels:\n k8s-app: coredns-operator\n name: coredns-operator\n namespace: coredns-system\n---\napiVersion: rbac.authorization.k8s.io/v1\nkind: ClusterRole\nmetadata:\n name: coredns-operator\nrules:\n- apiGroups:\n - \"\"\n resourceNames:\n - coredns\n resources:\n - configmaps\n - serviceaccounts\n - services\n verbs:\n - delete\n - patch\n - update\n- apiGroups:\n - \"\"\n resources:\n - configmaps\n - serviceaccounts\n - services\n verbs:\n - create\n- apiGroups:\n - apps\n - extensions\n resources:\n - deployments\n verbs:\n - get\n - list\n - watch\n- apiGroups:\n - apps\n - extensions\n resourceNames:\n - coredns\n resources:\n - deployments\n verbs:\n - delete\n - patch\n - update\n- apiGroups:\n - apps\n - extensions\n resources:\n - deployments\n verbs:\n - create\n- apiGroups:\n - \"\"\n resources:\n - events\n verbs:\n - create\n - patch\n- apiGroups:\n - \"\"\n resources:\n - configmaps\n - serviceaccounts\n - services\n verbs:\n - get\n - list\n - watch\n- apiGroups:\n - addons.x-k8s.io\n resources:\n - coredns\n verbs:\n - get\n - list\n - patch\n - update\n - watch\n- apiGroups:\n - addons.x-k8s.io\n resources:\n - coredns/status\n verbs:\n - get\n - patch\n - update\n- apiGroups:\n - coordination.k8s.io\n resources:\n - leases\n verbs:\n - get\n - list\n - watch\n - create\n - update\n - patch\n - delete\n---\napiVersion: rbac.authorization.k8s.io/v1\nkind: ClusterRoleBinding\nmetadata:\n labels:\n k8s-app: coredns-operator\n name: coredns-system:coredns-operator\nroleRef:\n apiGroup: rbac.authorization.k8s.io\n kind: ClusterRole\n name: coredns-operator\nsubjects:\n- kind: ServiceAccount\n name: coredns-operator\n namespace: coredns-system\n---\napiVersion: apps/v1\nkind: Deployment\nmetadata:\n labels:\n k8s-app: coredns-operator\n name: coredns-operator\n namespace: coredns-system\nspec:\n replicas: 1\n selector:\n matchLabels:\n k8s-app: coredns-operator\n template:\n metadata:\n labels:\n k8s-app: coredns-operator\n spec:\n containers:\n - args:\n - --leader-elect=false\n - --rbac-mode=ignore\n command:\n - /manager\n image: justinsb/coredns-operator:latest\n name: manager\n resources:\n limits:\n cpu: 100m\n memory: 30Mi\n requests:\n cpu: 100m\n memory: 20Mi\n serviceAccountName: coredns-operator\n terminationGracePeriodSeconds: 10\n","vendor/github.com/google/gnostic-models/extensions/README.md":"# Extensions\n\n**Extension Support is experimental.**\n\nThis directory contains support code for building Gnostic extensio handlers and\nassociated examples.\n\nExtension handlers can be used to compile vendor or specification extensions\ninto protocol buffer structures.\n\nLike plugins, extension handlers are built as separate executables. Extension\nbodies are written to extension handlers as serialized\nExtensionHandlerRequests.\n","AGENTS.md":"# kOps Project Overview\n\nkOps is a command-line tool for creating, destroying, upgrading, and maintaining production-grade, highly available Kubernetes clusters. It is written in Go and supports multiple cloud providers, including AWS, GCP, DigitalOcean, Hetzner, OpenStack, and Azure.\n\nThe project is well-structured, with a clear separation of concerns between the different packages. The `cmd` directory contains the main entry points for the `kops` CLI and other related commands. The `pkg` directory contains the core logic for managing clusters, and the `upup` directory contains the code for provisioning cloud infrastructure.\n\nThe project has a comprehensive test suite, including unit tests, integration tests, and end-to-end tests. It also has a robust CI/CD pipeline that runs these tests on every pull request.\n\n## Building and Running\n\n### Prerequisites\n\n* `make`\n\n### Building\n\nTo build the `kops` binary, run the following command:\n\n```bash\nmake kops\n```\n\nThis will create the `kops` binary in the `.build/dist//` directory.\n\nTo build all the binaries, including `kops`, `nodeup`, and `channels`, run the following command:\n\n```bash\nmake all\n```\n\n### Running\n\nTo run the `kops` binary, you can either run it directly from the `dist` directory or install it to your `$GOPATH/bin` directory by running the following command:\n\n```bash\nmake install\n```\n\n### Testing\n\nTo run the unit tests, run the following command:\n\n```bash\nmake test\n```\n\nTo run the verification scripts, run the following command:\n\n```bash\nmake verify\n```\n\nTo run the full suite of CI checks, run the following command:\n\n```bash\nmake ci\n```\n\n## Development Conventions\n\n### Guidelines for Programming Assistance\n\nWhen assisting with programming tasks, you will adhere to the following principles:\n\n* **Follow Requirements**: Carefully follow the user's requirements to the letter.\n* **Plan First**: For any non-trivial change, first describe a detailed, step-by-step plan, including the files you intend to modify and the tests you will add or update.\n* **Test Thoroughly**: Implement comprehensive tests to ensure correctness and prevent regressions.\n* **Comment Intelligently**: Add comments to explain the \"why\" behind complex or non-obvious code, keeping in mind that the reader may not be a Kubernetes expert.\n* **No TODOs**: Leave no `TODO` comments, placeholders, or incomplete implementations.\n* **Prioritize Correctness**: Always prioritize security, scalability, and maintainability in your implementations.\n\n### Avoiding Loops\n\nWhen performing complex tasks, especially those involving code modifications and verification, it's important to avoid getting into loops. A loop can occur when the agent repeatedly tries the same action without success, or when it gets stuck in a cycle of analysis, action, and failure.\n\nTo avoid loops:\n* **Analyze the problem carefully**: Before taking any action, make sure you understand the problem and have a clear plan to solve it.\n* **Break down the problem**: Break down complex problems into smaller, more manageable steps.\n* **Verify each step**: After each step, verify that it was successful before moving on to the next one.\n* **Don't repeat failed actions**: If an action fails, don't just repeat it. Analyze the cause of the failure and try a different approach.\n* **Ask for help**: If you're stuck, don't hesitate to ask for help from the user.\n\n### Code Style\n\nThe project follows the standard Go code style and the official [Kubernetes coding conventions](https://www.k8s.dev/docs/guide/coding-convention/). All code should be formatted with `gofmt` and `goimports`. You can format the code by running the following commands:\n\n```bash\nmake gofmt\nmake goimports\n```\n\n### Linting\n\nThe project uses `golangci-lint` to lint the code. You can run the linter by running the following command:\n\n```bash\nmake verify-golangci-lint\n```\n\n### Dependencies\n\nThe project uses Go modules to manage dependencies. To add a new dependency, add it to the `go.mod` file and then run the following command:\n\n```bash\nmake gomod\n```\n\n### Commits\n\nThe project follows the conventional commit message format.\n\n### Contributions\n\nContributions are welcome! Before submitting a pull request, please open an issue to discuss your proposed changes. All pull requests must be reviewed and approved by a maintainer before they can be merged.\n\n## E2E CI Failure Troubleshooting\n\nFor investigating E2E CI job failures — including locating artifacts, diagnosing root causes, and finding correlations across failing jobs — see [docs/e2e-failure-troubleshooting.md](docs/e2e-failure-troubleshooting.md).\n\n## Updating Third-Party Dependencies\n\nFor updating any pinned third-party dependency — Go modules, addon manifests, node components,\nGitHub Actions, e2e scenario charts, and the regeneration/verification each one requires — see\n[docs/dependency-updates.md](docs/dependency-updates.md).\n","GEMINI.md":"# kOps Project Overview\n\nkOps is a command-line tool for creating, destroying, upgrading, and maintaining production-grade, highly available Kubernetes clusters. It is written in Go and supports multiple cloud providers, including AWS, GCP, DigitalOcean, Hetzner, OpenStack, and Azure.\n\nThe project is well-structured, with a clear separation of concerns between the different packages. The `cmd` directory contains the main entry points for the `kops` CLI and other related commands. The `pkg` directory contains the core logic for managing clusters, and the `upup` directory contains the code for provisioning cloud infrastructure.\n\nThe project has a comprehensive test suite, including unit tests, integration tests, and end-to-end tests. It also has a robust CI/CD pipeline that runs these tests on every pull request.\n\n## Building and Running\n\n### Prerequisites\n\n* `make`\n\n### Building\n\nTo build the `kops` binary, run the following command:\n\n```bash\nmake kops\n```\n\nThis will create the `kops` binary in the `.build/dist//` directory.\n\nTo build all the binaries, including `kops`, `nodeup`, and `channels`, run the following command:\n\n```bash\nmake all\n```\n\n### Running\n\nTo run the `kops` binary, you can either run it directly from the `dist` directory or install it to your `$GOPATH/bin` directory by running the following command:\n\n```bash\nmake install\n```\n\n### Testing\n\nTo run the unit tests, run the following command:\n\n```bash\nmake test\n```\n\nTo run the verification scripts, run the following command:\n\n```bash\nmake verify\n```\n\nTo run the full suite of CI checks, run the following command:\n\n```bash\nmake ci\n```\n\n## Development Conventions\n\n### Guidelines for Programming Assistance\n\nWhen assisting with programming tasks, you will adhere to the following principles:\n\n* **Follow Requirements**: Carefully follow the user's requirements to the letter.\n* **Plan First**: For any non-trivial change, first describe a detailed, step-by-step plan, including the files you intend to modify and the tests you will add or update.\n* **Test Thoroughly**: Implement comprehensive tests to ensure correctness and prevent regressions.\n* **Comment Intelligently**: Add comments to explain the \"why\" behind complex or non-obvious code, keeping in mind that the reader may not be a Kubernetes expert.\n* **No TODOs**: Leave no `TODO` comments, placeholders, or incomplete implementations.\n* **Prioritize Correctness**: Always prioritize security, scalability, and maintainability in your implementations.\n\n### Avoiding Loops\n\nWhen performing complex tasks, especially those involving code modifications and verification, it's important to avoid getting into loops. A loop can occur when the agent repeatedly tries the same action without success, or when it gets stuck in a cycle of analysis, action, and failure.\n\nTo avoid loops:\n* **Analyze the problem carefully**: Before taking any action, make sure you understand the problem and have a clear plan to solve it.\n* **Break down the problem**: Break down complex problems into smaller, more manageable steps.\n* **Verify each step**: After each step, verify that it was successful before moving on to the next one.\n* **Don't repeat failed actions**: If an action fails, don't just repeat it. Analyze the cause of the failure and try a different approach.\n* **Ask for help**: If you're stuck, don't hesitate to ask for help from the user.\n\n### Code Style\n\nThe project follows the standard Go code style and the official [Kubernetes coding conventions](https://www.k8s.dev/docs/guide/coding-convention/). All code should be formatted with `gofmt` and `goimports`. You can format the code by running the following commands:\n\n```bash\nmake gofmt\nmake goimports\n```\n\n### Linting\n\nThe project uses `golangci-lint` to lint the code. You can run the linter by running the following command:\n\n```bash\nmake verify-golangci-lint\n```\n\n### Dependencies\n\nThe project uses Go modules to manage dependencies. To add a new dependency, add it to the `go.mod` file and then run the following command:\n\n```bash\nmake gomod\n```\n\n### Commits\n\nThe project follows the conventional commit message format.\n\n### Contributions\n\nContributions are welcome! Before submitting a pull request, please open an issue to discuss your proposed changes. All pull requests must be reviewed and approved by a maintainer before they can be merged.\n\n## E2E CI Failure Troubleshooting\n\nFor investigating E2E CI job failures — including locating artifacts, diagnosing root causes, and finding correlations across failing jobs — see [docs/e2e-failure-troubleshooting.md](docs/e2e-failure-troubleshooting.md).\n\n## Updating Third-Party Dependencies\n\nFor updating any pinned third-party dependency — Go modules, addon manifests, node components,\nGitHub Actions, e2e scenario charts, and the regeneration/verification each one requires — see\n[docs/dependency-updates.md](docs/dependency-updates.md).\n","tools/metal/storage/README.md":"A very simple s3 mock to support our testing of bare metal / VMs.\n\nJust enough functionality to support our tests.\n\nWARNING: This component is not intended for real-world deployment. DO NOT USE for production.\n"},"items":[{"name":"AGENTS.md","path":"AGENTS.md","rawUrl":"https://raw.githubusercontent.com/kubernetes/kops/HEAD/AGENTS.md","title":"AI Agent Protocol & Instructions","category":"root-instruction","format":"markdown","content":"# kOps Project Overview\n\nkOps is a command-line tool for creating, destroying, upgrading, and maintaining production-grade, highly available Kubernetes clusters. It is written in Go and supports multiple cloud providers, including AWS, GCP, DigitalOcean, Hetzner, OpenStack, and Azure.\n\nThe project is well-structured, with a clear separation of concerns between the different packages. The `cmd` directory contains the main entry points for the `kops` CLI and other related commands. The `pkg` directory contains the core logic for managing clusters, and the `upup` directory contains the code for provisioning cloud infrastructure.\n\nThe project has a comprehensive test suite, including unit tests, integration tests, and end-to-end tests. It also has a robust CI/CD pipeline that runs these tests on every pull request.\n\n## Building and Running\n\n### Prerequisites\n\n* `make`\n\n### Building\n\nTo build the `kops` binary, run the following command:\n\n```bash\nmake kops\n```\n\nThis will create the `kops` binary in the `.build/dist//` directory.\n\nTo build all the binaries, including `kops`, `nodeup`, and `channels`, run the following command:\n\n```bash\nmake all\n```\n\n### Running\n\nTo run the `kops` binary, you can either run it directly from the `dist` directory or install it to your `$GOPATH/bin` directory by running the following command:\n\n```bash\nmake install\n```\n\n### Testing\n\nTo run the unit tests, run the following command:\n\n```bash\nmake test\n```\n\nTo run the verification scripts, run the following command:\n\n```bash\nmake verify\n```\n\nTo run the full suite of CI checks, run the following command:\n\n```bash\nmake ci\n```\n\n## Development Conventions\n\n### Guidelines for Programming Assistance\n\nWhen assisting with programming tasks, you will adhere to the following principles:\n\n* **Follow Requirements**: Carefully follow the user's requirements to the letter.\n* **Plan First**: For any non-trivial change, first describe a detailed, step-by-step plan, including the files you intend to modify and the tests you will add or update.\n* **Test Thoroughly**: Implement comprehensive tests to ensure correctness and prevent regressions.\n* **Comment Intelligently**: Add comments to explain the \"why\" behind complex or non-obvious code, keeping in mind that the reader may not be a Kubernetes expert.\n* **No TODOs**: Leave no `TODO` comments, placeholders, or incomplete implementations.\n* **Prioritize Correctness**: Always prioritize security, scalability, and maintainability in your implementations.\n\n### Avoiding Loops\n\nWhen performing complex tasks, especially those involving code modifications and verification, it's important to avoid getting into loops. A loop can occur when the agent repeatedly tries the same action without success, or when it gets stuck in a cycle of analysis, action, and failure.\n\nTo avoid loops:\n* **Analyze the problem carefully**: Before taking any action, make sure you understand the problem and have a clear plan to solve it.\n* **Break down the problem**: Break down complex problems into smaller, more manageable steps.\n* **Verify each step**: After each step, verify that it was successful before moving on to the next one.\n* **Don't repeat failed actions**: If an action fails, don't just repeat it. Analyze the cause of the failure and try a different approach.\n* **Ask for help**: If you're stuck, don't hesitate to ask for help from the user.\n\n### Code Style\n\nThe project follows the standard Go code style and the official [Kubernetes coding conventions](https://www.k8s.dev/docs/guide/coding-convention/). All code should be formatted with `gofmt` and `goimports`. You can format the code by running the following commands:\n\n```bash\nmake gofmt\nmake goimports\n```\n\n### Linting\n\nThe project uses `golangci-lint` to lint the code. You can run the linter by running the following command:\n\n```bash\nmake verify-golangci-lint\n```\n\n### Dependencies\n\nThe project uses Go modules to manage dependencies. To add a new dependency, add it to the `go.mod` file and then run the following command:\n\n```bash\nmake gomod\n```\n\n### Commits\n\nThe project follows the conventional commit message format.\n\n### Contributions\n\nContributions are welcome! Before submitting a pull request, please open an issue to discuss your proposed changes. All pull requests must be reviewed and approved by a maintainer before they can be merged.\n\n## E2E CI Failure Troubleshooting\n\nFor investigating E2E CI job failures — including locating artifacts, diagnosing root causes, and finding correlations across failing jobs — see [docs/e2e-failure-troubleshooting.md](docs/e2e-failure-troubleshooting.md).\n\n## Updating Third-Party Dependencies\n\nFor updating any pinned third-party dependency — Go modules, addon manifests, node components,\nGitHub Actions, e2e scenario charts, and the regeneration/verification each one requires — see\n[docs/dependency-updates.md](docs/dependency-updates.md).\n","isInternal":false,"tokens":1073,"sizeBytes":4923},{"name":"manifest.yaml","path":"channels/packages/operator.coredns.addons.x-k8s.io/0.1.0-kops.1/manifest.yaml","rawUrl":"https://raw.githubusercontent.com/kubernetes/kops/HEAD/channels/packages/operator.coredns.addons.x-k8s.io/0.1.0-kops.1/manifest.yaml","title":"0.1.0-kops.1 Skill","category":"anthropic-skill","format":"yaml","content":"apiVersion: rbac.authorization.k8s.io/v1\nkind: ClusterRole\nmetadata:\n labels:\n addonmanager.kubernetes.io/mode: EnsureExists\n kubernetes.io/bootstrapping: rbac-defaults\n kubernetes.io/cluster-service: \"true\"\n kubernetes.io/name: CoreDNS\n name: system:coredns\nrules:\n- apiGroups:\n - \"\"\n resources:\n - endpoints\n - services\n - pods\n - namespaces\n verbs:\n - list\n - watch\n- apiGroups:\n - \"\"\n resources:\n - nodes\n verbs:\n - get\n---\napiVersion: rbac.authorization.k8s.io/v1\nkind: ClusterRoleBinding\nmetadata:\n annotations:\n rbac.authorization.kubernetes.io/autoupdate: \"true\"\n labels:\n addonmanager.kubernetes.io/mode: EnsureExists\n kubernetes.io/bootstrapping: rbac-defaults\n kubernetes.io/cluster-service: \"true\"\n kubernetes.io/name: CoreDNS\n name: system:coredns\nroleRef:\n apiGroup: rbac.authorization.k8s.io\n kind: ClusterRole\n name: system:coredns\nsubjects:\n- kind: ServiceAccount\n name: coredns\n namespace: kube-system\n---\napiVersion: apiextensions.k8s.io/v1\nkind: CustomResourceDefinition\nmetadata:\n annotations:\n controller-gen.kubebuilder.io/version: v0.2.5\n creationTimestamp: null\n name: coredns.addons.x-k8s.io\nspec:\n group: addons.x-k8s.io\n names:\n kind: CoreDNS\n listKind: CoreDNSList\n plural: coredns\n singular: coredns\n scope: Namespaced\n versions:\n - name: v1alpha1\n schema:\n openAPIV3Schema:\n description: CoreDNS is the Schema for the coredns API\n properties:\n apiVersion:\n description: 'APIVersion defines the versioned schema of this representation\n of an object. Servers should convert recognized schemas to the latest\n internal value, and may reject unrecognized values. More info: https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#resources'\n type: string\n kind:\n description: 'Kind is a string value representing the REST resource this\n object represents. Servers may infer this from the endpoint the client\n submits requests to. Cannot be updated. In CamelCase. More info: https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#types-kinds'\n type: string\n metadata:\n type: object\n spec:\n description: CoreDNSSpec defines the desired state of CoreDNS\n properties:\n channel:\n description: 'Channel specifies a channel that can be used to resolve\n a specific addon, eg: stable It will be ignored if Version is specified'\n type: string\n corefile:\n type: string\n dnsDomain:\n type: string\n dnsIP:\n type: string\n patches:\n items:\n type: object\n type: array\n version:\n description: Version specifies the exact addon version to be deployed,\n eg 1.2.3 It should not be specified if Channel is specified\n type: string\n type: object\n status:\n description: CoreDNSStatus defines the observed state of CoreDNS\n properties:\n errors:\n items:\n type: string\n type: array\n healthy:\n type: boolean\n required:\n - healthy\n type: object\n type: object\n served: true\n storage: true\n subresources:\n status: {}\n\n---\n\napiVersion: v1\nkind: Namespace\nmetadata:\n name: coredns-system\n---\napiVersion: v1\nkind: ServiceAccount\nmetadata:\n labels:\n k8s-app: coredns-operator\n name: coredns-operator\n namespace: coredns-system\n---\napiVersion: rbac.authorization.k8s.io/v1\nkind: ClusterRole\nmetadata:\n name: coredns-operator\nrules:\n- apiGroups:\n - \"\"\n resourceNames:\n - coredns\n resources:\n - configmaps\n - serviceaccounts\n - services\n verbs:\n - delete\n - patch\n - update\n- apiGroups:\n - \"\"\n resources:\n - configmaps\n - serviceaccounts\n - services\n verbs:\n - create\n- apiGroups:\n - apps\n - extensions\n resources:\n - deployments\n verbs:\n - get\n - list\n - watch\n- apiGroups:\n - apps\n - extensions\n resourceNames:\n - coredns\n resources:\n - deployments\n verbs:\n - delete\n - patch\n - update\n- apiGroups:\n - apps\n - extensions\n resources:\n - deployments\n verbs:\n - create\n- apiGroups:\n - \"\"\n resources:\n - events\n verbs:\n - create\n - patch\n- apiGroups:\n - \"\"\n resources:\n - configmaps\n - serviceaccounts\n - services\n verbs:\n - get\n - list\n - watch\n- apiGroups:\n - addons.x-k8s.io\n resources:\n - coredns\n verbs:\n - get\n - list\n - patch\n - update\n - watch\n- apiGroups:\n - addons.x-k8s.io\n resources:\n - coredns/status\n verbs:\n - get\n - patch\n - update\n- apiGroups:\n - coordination.k8s.io\n resources:\n - leases\n verbs:\n - get\n - list\n - watch\n - create\n - update\n - patch\n - delete\n---\napiVersion: rbac.authorization.k8s.io/v1\nkind: ClusterRoleBinding\nmetadata:\n labels:\n k8s-app: coredns-operator\n name: coredns-system:coredns-operator\nroleRef:\n apiGroup: rbac.authorization.k8s.io\n kind: ClusterRole\n name: coredns-operator\nsubjects:\n- kind: ServiceAccount\n name: coredns-operator\n namespace: coredns-system\n---\napiVersion: apps/v1\nkind: Deployment\nmetadata:\n labels:\n k8s-app: coredns-operator\n name: coredns-operator\n namespace: coredns-system\nspec:\n replicas: 1\n selector:\n matchLabels:\n k8s-app: coredns-operator\n template:\n metadata:\n labels:\n k8s-app: coredns-operator\n spec:\n containers:\n - args:\n - --leader-elect=false\n - --rbac-mode=ignore\n command:\n - /manager\n image: justinsb/coredns-operator:latest\n name: manager\n resources:\n limits:\n cpu: 100m\n memory: 30Mi\n requests:\n cpu: 100m\n memory: 20Mi\n serviceAccountName: coredns-operator\n terminationGracePeriodSeconds: 10\n","isInternal":false,"tokens":1596,"sizeBytes":6099},{"name":"GEMINI.md","path":"discovery/GEMINI.md","rawUrl":"https://raw.githubusercontent.com/kubernetes/kops/HEAD/discovery/GEMINI.md","title":"discovery - Gemini Agent & Antigravity Instructions","category":"gemini-rule","format":"markdown","content":"# Discovery Service Project\n\n## Overview\nThis project implements a public discovery service designed for decentralized, secure peer discovery. The core innovation is the use of **Custom Certificate Authorities (CAs)** to define isolated \"Universes\". Clients register and discover peers within their own Universe, identified and secured purely by mTLS.\n\nThe service emulates a Kubernetes API, allowing interaction via `kubectl`, including support for **Server-Side Apply**.\n\n## Key Concepts\n\n### 1. The \"Universe\"\n- A **Universe** is an isolated scope for peer discovery.\n- It is cryptographically defined by the **SHA256 hash of the Root CA's Public Key**.\n- Any client possessing a valid certificate signed by a specific CA belongs to that CA's Universe.\n- Different CAs = Different Universes. There is no crossover.\n\n### 2. Authentication & Authorization\n- **Mechanism**: Mutual TLS (mTLS).\n- **Client Identity**: Derived from the **Common Name (CN)** of the leaf certificate.\n- **Universe Context**: Derived from the **Root CA** presented in the TLS handshake.\n- **Requirement**: Clients **MUST** present the full certificate chain (Leaf + Root CA) during the handshake. The server does not maintain a pre-configured trust store for these custom CAs; it uses the presented chain to determine the scope.\n\n### 3. API Resources\n- **DiscoveryEndpoint** (`discovery.kops.k8s.io/v1alpha1`): Represents a peer in the discovery network. Can optionally hold OIDC configuration (Issuer URL, JWKS).\n- **Validation**: A client with CN `client1` can only Create/Update a `DiscoveryEndpoint` named `client1`.\n- **Apply Support**: The server supports `PATCH` requests to facilitate `kubectl apply --server-side`.\n\n### 4. OIDC Discovery\nThe server acts as an OIDC Discovery Provider for the Universe.\n- **Public Endpoints**:\n - `/.well-known/openid-configuration`: Returns the OIDC discovery document.\n - `/openid/v1/jwks`: Returns the JSON Web Key Set (JWKS).\n- **Data Source**: These endpoints serve data uploaded by clients via the `DiscoveryEndpoint` resource.\n\n## Architecture\n\n### Project Structure\n- `cmd/discovery-server/`: Main entry point. Wires up the HTTP server with TLS configuration.\n- `pkg/discovery/`:\n - `auth.go`: logic for inspecting TLS `PeerCertificates` to extract the Universe ID (CA hash) and Client ID.\n - `store.go`: In-memory thread-safe storage (`MemoryStore`) mapping Universe IDs to lists of `DiscoveryEndpoint` objects.\n - `server.go`: HTTP handlers implementing the K8s API emulation for `/apis/discovery.kops.k8s.io/v1alpha1`.\n - `k8s_types.go`: Definitions of `DiscoveryEndpoint`, `DiscoveryEndpointList`, `TypeMeta`, `ObjectMeta` etc.\n\n### Data Model\n- **DiscoveryEndpoint**: The core resource. Contains `Spec.Addresses` and metadata.\n- **Universe**: Contains a map of `DiscoveryEndpoint` objects (keyed by name).\n- **Unified Types**: The API type `DiscoveryEndpoint` is used directly for in-memory storage, ensuring zero conversion overhead.\n\n## Security Model\n- **Trust Delegation**: The server delegates trust to the CA. If you hold the CA key, you control the Universe.\n- **Isolation**: The server ensures that a client presenting a cert chain for `CA_A` cannot read or write data to the Universe defined by `CA_B`.\n- **Ephemeral**: The current implementation uses in-memory storage. Data is lost on restart.\n\n## Building and Running\n\n### Build\n```bash\ngo build ./cmd/discovery-server\n```\n\n### Run\n\nSee docs/walkthrough.md for instructions on testing functionality.\n","isInternal":false,"tokens":799,"sizeBytes":3499},{"name":"GEMINI.md","path":"GEMINI.md","rawUrl":"https://raw.githubusercontent.com/kubernetes/kops/HEAD/GEMINI.md","title":"Gemini Agent & Antigravity Instructions","category":"gemini-rule","format":"markdown","content":"# kOps Project Overview\n\nkOps is a command-line tool for creating, destroying, upgrading, and maintaining production-grade, highly available Kubernetes clusters. It is written in Go and supports multiple cloud providers, including AWS, GCP, DigitalOcean, Hetzner, OpenStack, and Azure.\n\nThe project is well-structured, with a clear separation of concerns between the different packages. The `cmd` directory contains the main entry points for the `kops` CLI and other related commands. The `pkg` directory contains the core logic for managing clusters, and the `upup` directory contains the code for provisioning cloud infrastructure.\n\nThe project has a comprehensive test suite, including unit tests, integration tests, and end-to-end tests. It also has a robust CI/CD pipeline that runs these tests on every pull request.\n\n## Building and Running\n\n### Prerequisites\n\n* `make`\n\n### Building\n\nTo build the `kops` binary, run the following command:\n\n```bash\nmake kops\n```\n\nThis will create the `kops` binary in the `.build/dist//` directory.\n\nTo build all the binaries, including `kops`, `nodeup`, and `channels`, run the following command:\n\n```bash\nmake all\n```\n\n### Running\n\nTo run the `kops` binary, you can either run it directly from the `dist` directory or install it to your `$GOPATH/bin` directory by running the following command:\n\n```bash\nmake install\n```\n\n### Testing\n\nTo run the unit tests, run the following command:\n\n```bash\nmake test\n```\n\nTo run the verification scripts, run the following command:\n\n```bash\nmake verify\n```\n\nTo run the full suite of CI checks, run the following command:\n\n```bash\nmake ci\n```\n\n## Development Conventions\n\n### Guidelines for Programming Assistance\n\nWhen assisting with programming tasks, you will adhere to the following principles:\n\n* **Follow Requirements**: Carefully follow the user's requirements to the letter.\n* **Plan First**: For any non-trivial change, first describe a detailed, step-by-step plan, including the files you intend to modify and the tests you will add or update.\n* **Test Thoroughly**: Implement comprehensive tests to ensure correctness and prevent regressions.\n* **Comment Intelligently**: Add comments to explain the \"why\" behind complex or non-obvious code, keeping in mind that the reader may not be a Kubernetes expert.\n* **No TODOs**: Leave no `TODO` comments, placeholders, or incomplete implementations.\n* **Prioritize Correctness**: Always prioritize security, scalability, and maintainability in your implementations.\n\n### Avoiding Loops\n\nWhen performing complex tasks, especially those involving code modifications and verification, it's important to avoid getting into loops. A loop can occur when the agent repeatedly tries the same action without success, or when it gets stuck in a cycle of analysis, action, and failure.\n\nTo avoid loops:\n* **Analyze the problem carefully**: Before taking any action, make sure you understand the problem and have a clear plan to solve it.\n* **Break down the problem**: Break down complex problems into smaller, more manageable steps.\n* **Verify each step**: After each step, verify that it was successful before moving on to the next one.\n* **Don't repeat failed actions**: If an action fails, don't just repeat it. Analyze the cause of the failure and try a different approach.\n* **Ask for help**: If you're stuck, don't hesitate to ask for help from the user.\n\n### Code Style\n\nThe project follows the standard Go code style and the official [Kubernetes coding conventions](https://www.k8s.dev/docs/guide/coding-convention/). All code should be formatted with `gofmt` and `goimports`. You can format the code by running the following commands:\n\n```bash\nmake gofmt\nmake goimports\n```\n\n### Linting\n\nThe project uses `golangci-lint` to lint the code. You can run the linter by running the following command:\n\n```bash\nmake verify-golangci-lint\n```\n\n### Dependencies\n\nThe project uses Go modules to manage dependencies. To add a new dependency, add it to the `go.mod` file and then run the following command:\n\n```bash\nmake gomod\n```\n\n### Commits\n\nThe project follows the conventional commit message format.\n\n### Contributions\n\nContributions are welcome! Before submitting a pull request, please open an issue to discuss your proposed changes. All pull requests must be reviewed and approved by a maintainer before they can be merged.\n\n## E2E CI Failure Troubleshooting\n\nFor investigating E2E CI job failures — including locating artifacts, diagnosing root causes, and finding correlations across failing jobs — see [docs/e2e-failure-troubleshooting.md](docs/e2e-failure-troubleshooting.md).\n\n## Updating Third-Party Dependencies\n\nFor updating any pinned third-party dependency — Go modules, addon manifests, node components,\nGitHub Actions, e2e scenario charts, and the regeneration/verification each one requires — see\n[docs/dependency-updates.md](docs/dependency-updates.md).\n","isInternal":false,"tokens":1073,"sizeBytes":4923},{"name":"README.md","path":"tools/metal/dhcp/README.md","rawUrl":"https://raw.githubusercontent.com/kubernetes/kops/HEAD/tools/metal/dhcp/README.md","title":"dhcp Documentation","category":"plugin-manifest","format":"markdown","content":"A very simple DHCP server to support our testing of bare metal / VMs.\n\nMAC addresses map to IP addresses, so x:x:x:x:x:7 => x.x.x.7\n\n(Remember that the MAC address is in hex, and IP addresses are normally printed in decimal! So `:10` => `.16`)","isInternal":false,"tokens":68,"sizeBytes":244},{"name":"README.md","path":"tools/metal/storage/README.md","rawUrl":"https://raw.githubusercontent.com/kubernetes/kops/HEAD/tools/metal/storage/README.md","title":"storage Documentation","category":"plugin-manifest","format":"markdown","content":"A very simple s3 mock to support our testing of bare metal / VMs.\n\nJust enough functionality to support our tests.\n\nWARNING: This component is not intended for real-world deployment. DO NOT USE for production.\n","isInternal":false,"tokens":43,"sizeBytes":210},{"name":"README.md","path":"vendor/github.com/google/gnostic-models/extensions/README.md","rawUrl":"https://raw.githubusercontent.com/kubernetes/kops/HEAD/vendor/github.com/google/gnostic-models/extensions/README.md","title":"extensions Documentation","category":"plugin-manifest","format":"markdown","content":"# Extensions\n\n**Extension Support is experimental.**\n\nThis directory contains support code for building Gnostic extensio handlers and\nassociated examples.\n\nExtension handlers can be used to compile vendor or specification extensions\ninto protocol buffer structures.\n\nLike plugins, extension handlers are built as separate executables. Extension\nbodies are written to extension handlers as serialized\nExtensionHandlerRequests.\n","isInternal":false,"tokens":73,"sizeBytes":426}],"systemPromptSnippet":"\n\n# kOps Project Overview\n\nkOps is a command-line tool for creating, destroying, upgrading, and maintaining production-grade, highly available Kubernetes clusters. It is written in Go and supports multiple cloud providers, including AWS, GCP, DigitalOcean, Hetzner, OpenStack, and Azure.\n\nThe project is well-structured, with a clear separation of concerns between the different packages. The `cmd` directory contains the main entry points for the `kops` CLI and other related commands. The `pkg` directory contains the core logic for managing clusters, and the `upup` directory contains the code for provisioning cloud infrastructure.\n\nThe project has a comprehensive test suite, including unit tests, integration tests, and end-to-end tests. It also has a robust CI/CD pipeline that runs these tests on every pull request.\n\n## Building and Running\n\n### Prerequisites\n\n* `make`\n\n### Building\n\nTo build the `kops` binary, run the following command:\n\n```bash\nmake kops\n```\n\nThis will create the `kops` binary in the `.build/dist//` directory.\n\nTo build all the binaries, including `kops`, `nodeup`, and `channels`, run the following command:\n\n```bash\nmake all\n```\n\n### Running\n\nTo run the `kops` binary, you can either run it directly from the `dist` directory or install it to your `$GOPATH/bin` directory by running the following command:\n\n```bash\nmake install\n```\n\n### Testing\n\nTo run the unit tests, run the following command:\n\n```bash\nmake test\n```\n\nTo run the verification scripts, run the following command:\n\n```bash\nmake verify\n```\n\nTo run the full suite of CI checks, run the following command:\n\n```bash\nmake ci\n```\n\n## Development Conventions\n\n### Guidelines for Programming Assistance\n\nWhen assisting with programming tasks, you will adhere to the following principles:\n\n* **Follow Requirements**: Carefully follow the user's requirements to the letter.\n* **Plan First**: For any non-trivial change, first describe a detailed, step-by-step plan, including the files you intend to modify and the tests you will add or update.\n* **Test Thoroughly**: Implement comprehensive tests to ensure correctness and prevent regressions.\n* **Comment Intelligently**: Add comments to explain the \"why\" behind complex or non-obvious code, keeping in mind that the reader may not be a Kubernetes expert.\n* **No TODOs**: Leave no `TODO` comments, placeholders, or incomplete implementations.\n* **Prioritize Correctness**: Always prioritize security, scalability, and maintainability in your implementations.\n\n### Avoiding Loops\n\nWhen performing complex tasks, especially those involving code modifications and verification, it's important to avoid getting into loops. A loop can occur when the agent repeatedly tries the same action without success, or when it gets stuck in a cycle of analysis, action, and failure.\n\nTo avoid loops:\n* **Analyze the problem carefully**: Before taking any action, make sure you understand the problem and have a clear plan to solve it.\n* **Break down the problem**: Break down complex problems into smaller, more manageable steps.\n* **Verify each step**: After each step, verify that it was successful before moving on to the next one.\n* **Don't repeat failed actions**: If an action fails, don't just repeat it. Analyze the cause of the failure and try a different approach.\n* **Ask for help**: If you're stuck, don't hesitate to ask for help from the user.\n\n### Code Style\n\nThe project follows the standard Go code style and the official [Kubernetes coding conventions](https://www.k8s.dev/docs/guide/coding-convention/). All code should be formatted with `gofmt` and `goimports`. You can format the code by running the following commands:\n\n```bash\nmake gofmt\nmake goimports\n```\n\n### Linting\n\nThe project uses `golangci-lint` to lint the code. You can run the linter by running the following command:\n\n```bash\nmake verify-golangci-lint\n```\n\n### Dependencies\n\nThe project uses Go modules to manage dependencies. To add a new dependency, add it to the `go.mod` file and then run the following command:\n\n```bash\nmake gomod\n```\n\n### Commits\n\nThe project follows the conventional commit message format.\n\n### Contributions\n\nContributions are welcome! Before submitting a pull request, please open an issue to discuss your proposed changes. All pull requests must be reviewed and approved by a maintainer before they can be merged.\n\n## E2E CI Failure Troubleshooting\n\nFor investigating E2E CI job failures — including locating artifacts, diagnosing root causes, and finding correlations across failing jobs — see [docs/e2e-failure-troubleshooting.md](docs/e2e-failure-troubleshooting.md).\n\n## Updating Third-Party Dependencies\n\nFor updating any pinned third-party dependency — Go modules, addon manifests, node components,\nGitHub Actions, e2e scenario charts, and the regeneration/verification each one requires — see\n[docs/dependency-updates.md](docs/dependency-updates.md).\n\n\napiVersion: rbac.authorization.k8s.io/v1\nkind: ClusterRole\nmetadata:\n labels:\n addonmanager.kubernetes.io/mode: EnsureExists\n kubernetes.io/bootstrapping: rbac-defaults\n kubernetes.io/cluster-service: \"true\"\n kubernetes.io/name: CoreDNS\n name: system:coredns\nrules:\n- apiGroups:\n - \"\"\n resources:\n - endpoints\n - services\n - pods\n - namespaces\n verbs:\n - list\n - watch\n- apiGroups:\n - \"\"\n resources:\n - nodes\n verbs:\n - get\n---\napiVersion: rbac.authorization.k8s.io/v1\nkind: ClusterRoleBinding\nmetadata:\n annotations:\n rbac.authorization.kubernetes.io/autoupdate: \"true\"\n labels:\n addonmanager.kubernetes.io/mode: EnsureExists\n kubernetes.io/bootstrapping: rbac-defaults\n kubernetes.io/cluster-service: \"true\"\n kubernetes.io/name: CoreDNS\n name: system:coredns\nroleRef:\n apiGroup: rbac.authorization.k8s.io\n kind: ClusterRole\n name: system:coredns\nsubjects:\n- kind: ServiceAccount\n name: coredns\n namespace: kube-system\n---\napiVersion: apiextensions.k8s.io/v1\nkind: CustomResourceDefinition\nmetadata:\n annotations:\n controller-gen.kubebuilder.io/version: v0.2.5\n creationTimestamp: null\n name: coredns.addons.x-k8s.io\nspec:\n group: addons.x-k8s.io\n names:\n kind: CoreDNS\n listKind: CoreDNSList\n plural: coredns\n singular: coredns\n scope: Namespaced\n versions:\n - name: v1alpha1\n schema:\n openAPIV3Schema:\n description: CoreDNS is the Schema for the coredns API\n properties:\n apiVersion:\n description: 'APIVersion defines the versioned schema of this representation\n of an object. Servers should convert recognized schemas to the latest\n internal value, and may reject unrecognized values. More info: https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#resources'\n type: string\n kind:\n description: 'Kind is a string value representing the REST resource this\n object represents. Servers may infer this from the endpoint the client\n submits requests to. Cannot be updated. In CamelCase. More info: https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#types-kinds'\n type: string\n metadata:\n type: object\n spec:\n description: CoreDNSSpec defines the desired state of CoreDNS\n properties:\n channel:\n description: 'Channel specifies a channel that can be used to resolve\n a specific addon, eg: stable It will be ignored if Version is specified'\n type: string\n corefile:\n type: string\n dnsDomain:\n type: string\n dnsIP:\n type: string\n patches:\n items:\n type: object\n type: array\n version:\n description: Version specifies the exact addon version to be deployed,\n eg 1.2.3 It should not be specified if Channel is specified\n type: string\n type: object\n status:\n description: CoreDNSStatus defines the observed state of CoreDNS\n properties:\n errors:\n items:\n type: string\n type: array\n healthy:\n type: boolean\n required:\n - healthy\n type: object\n type: object\n served: true\n storage: true\n subresources:\n status: {}\n\n---\n\napiVersion: v1\nkind: Namespace\nmetadata:\n name: coredns-system\n---\napiVersion: v1\nkind: ServiceAccount\nmetadata:\n labels:\n k8s-app: coredns-operator\n name: coredns-operator\n namespace: coredns-system\n---\napiVersion: rbac.authorization.k8s.io/v1\nkind: ClusterRole\nmetadata:\n name: coredns-operator\nrules:\n- apiGroups:\n - \"\"\n resourceNames:\n - coredns\n resources:\n - configmaps\n - serviceaccounts\n - services\n verbs:\n - delete\n - patch\n - update\n- apiGroups:\n - \"\"\n resources:\n - configmaps\n - serviceaccounts\n - services\n verbs:\n - create\n- apiGroups:\n - apps\n - extensions\n resources:\n - deployments\n verbs:\n - get\n - list\n - watch\n- apiGroups:\n - apps\n - extensions\n resourceNames:\n - coredns\n resources:\n - deployments\n verbs:\n - delete\n - patch\n - update\n- apiGroups:\n - apps\n - extensions\n resources:\n - deployments\n verbs:\n - create\n- apiGroups:\n - \"\"\n resources:\n - events\n verbs:\n - create\n - patch\n- apiGroups:\n - \"\"\n resources:\n - configmaps\n - serviceaccounts\n - services\n verbs:\n - get\n - list\n - watch\n- apiGroups:\n - addons.x-k8s.io\n resources:\n - coredns\n verbs:\n - get\n - list\n - patch\n - update\n - watch\n- apiGroups:\n - addons.x-k8s.io\n resources:\n - coredns/status\n verbs:\n - get\n - patch\n - update\n- apiGroups:\n - coordination.k8s.io\n resources:\n - leases\n verbs:\n - get\n - list\n - watch\n - create\n - update\n - patch\n - delete\n---\napiVersion: rbac.authorization.k8s.io/v1\nkind: ClusterRoleBinding\nmetadata:\n labels:\n k8s-app: coredns-operator\n name: coredns-system:coredns-operator\nroleRef:\n apiGroup: rbac.authorization.k8s.io\n kind: ClusterRole\n name: coredns-operator\nsubjects:\n- kind: ServiceAccount\n name: coredns-operator\n namespace: coredns-system\n---\napiVersion: apps/v1\nkind: Deployment\nmetadata:\n labels:\n k8s-app: coredns-operator\n name: coredns-operator\n namespace: coredns-system\nspec:\n replicas: 1\n selector:\n matchLabels:\n k8s-app: coredns-operator\n template:\n metadata:\n labels:\n k8s-app: coredns-operator\n spec:\n containers:\n - args:\n - --leader-elect=false\n - --rbac-mode=ignore\n command:\n - /manager\n image: justinsb/coredns-operator:latest\n name: manager\n resources:\n limits:\n cpu: 100m\n memory: 30Mi\n requests:\n cpu: 100m\n memory: 20Mi\n serviceAccountName: coredns-operator\n terminationGracePeriodSeconds: 10\n\n\n# Discovery Service Project\n\n## Overview\nThis project implements a public discovery service designed for decentralized, secure peer discovery. The core innovation is the use of **Custom Certificate Authorities (CAs)** to define isolated \"Universes\". Clients register and discover peers within their own Universe, identified and secured purely by mTLS.\n\nThe service emulates a Kubernetes API, allowing interaction via `kubectl`, including support for **Server-Side Apply**.\n\n## Key Concepts\n\n### 1. The \"Universe\"\n- A **Universe** is an isolated scope for peer discovery.\n- It is cryptographically defined by the **SHA256 hash of the Root CA's Public Key**.\n- Any client possessing a valid certificate signed by a specific CA belongs to that CA's Universe.\n- Different CAs = Different Universes. There is no crossover.\n\n### 2. Authentication & Authorization\n- **Mechanism**: Mutual TLS (mTLS).\n- **Client Identity**: Derived from the **Common Name (CN)** of the leaf certificate.\n- **Universe Context**: Derived from the **Root CA** presented in the TLS handshake.\n- **Requirement**: Clients **MUST** present the full certificate chain (Leaf + Root CA) during the handshake. The server does not maintain a pre-configured trust store for these custom CAs; it uses the presented chain to determine the scope.\n\n### 3. API Resources\n- **DiscoveryEndpoint** (`discovery.kops.k8s.io/v1alpha1`): Represents a peer in the discovery network. Can optionally hold OIDC configuration (Issuer URL, JWKS).\n- **Validation**: A client with CN `client1` can only Create/Update a `DiscoveryEndpoint` named `client1`.\n- **Apply Support**: The server supports `PATCH` requests to facilitate `kubectl apply --server-side`.\n\n### 4. OIDC Discovery\nThe server acts as an OIDC Discovery Provider for the Universe.\n- **Public Endpoints**:\n - `/.well-known/openid-configuration`: Returns the OIDC discovery document.\n - `/openid/v1/jwks`: Returns the JSON Web Key Set (JWKS).\n- **Data Source**: These endpoints serve data uploaded by clients via the `DiscoveryEndpoint` resource.\n\n## Architecture\n\n### Project Structure\n- `cmd/discovery-server/`: Main entry point. Wires up the HTTP server with TLS configuration.\n- `pkg/discovery/`:\n - `auth.go`: logic for inspecting TLS `PeerCertificates` to extract the Universe ID (CA hash) and Client ID.\n - `store.go`: In-memory thread-safe storage (`MemoryStore`) mapping Universe IDs to lists of `DiscoveryEndpoint` objects.\n - `server.go`: HTTP handlers implementing the K8s API emulation for `/apis/discovery.kops.k8s.io/v1alpha1`.\n - `k8s_types.go`: Definitions of `DiscoveryEndpoint`, `DiscoveryEndpointList`, `TypeMeta`, `ObjectMeta` etc.\n\n### Data Model\n- **DiscoveryEndpoint**: The core resource. Contains `Spec.Addresses` and metadata.\n- **Universe**: Contains a map of `DiscoveryEndpoint` objects (keyed by name).\n- **Unified Types**: The API type `DiscoveryEndpoint` is used directly for in-memory storage, ensuring zero conversion overhead.\n\n## Security Model\n- **Trust Delegation**: The server delegates trust to the CA. If you hold the CA key, you control the Universe.\n- **Isolation**: The server ensures that a client presenting a cert chain for `CA_A` cannot read or write data to the Universe defined by `CA_B`.\n- **Ephemeral**: The current implementation uses in-memory storage. Data is lost on restart.\n\n## Building and Running\n\n### Build\n```bash\ngo build ./cmd/discovery-server\n```\n\n### Run\n\nSee docs/walkthrough.md for instructions on testing functionality.\n\n\n# kOps Project Overview\n\nkOps is a command-line tool for creating, destroying, upgrading, and maintaining production-grade, highly available Kubernetes clusters. It is written in Go and supports multiple cloud providers, including AWS, GCP, DigitalOcean, Hetzner, OpenStack, and Azure.\n\nThe project is well-structured, with a clear separation of concerns between the different packages. The `cmd` directory contains the main entry points for the `kops` CLI and other related commands. The `pkg` directory contains the core logic for managing clusters, and the `upup` directory contains the code for provisioning cloud infrastructure.\n\nThe project has a comprehensive test suite, including unit tests, integration tests, and end-to-end tests. It also has a robust CI/CD pipeline that runs these tests on every pull request.\n\n## Building and Running\n\n### Prerequisites\n\n* `make`\n\n### Building\n\nTo build the `kops` binary, run the following command:\n\n```bash\nmake kops\n```\n\nThis will create the `kops` binary in the `.build/dist//` directory.\n\nTo build all the binaries, including `kops`, `nodeup`, and `channels`, run the following command:\n\n```bash\nmake all\n```\n\n### Running\n\nTo run the `kops` binary, you can either run it directly from the `dist` directory or install it to your `$GOPATH/bin` directory by running the following command:\n\n```bash\nmake install\n```\n\n### Testing\n\nTo run the unit tests, run the following command:\n\n```bash\nmake test\n```\n\nTo run the verification scripts, run the following command:\n\n```bash\nmake verify\n```\n\nTo run the full suite of CI checks, run the following command:\n\n```bash\nmake ci\n```\n\n## Development Conventions\n\n### Guidelines for Programming Assistance\n\nWhen assisting with programming tasks, you will adhere to the following principles:\n\n* **Follow Requirements**: Carefully follow the user's requirements to the letter.\n* **Plan First**: For any non-trivial change, first describe a detailed, step-by-step plan, including the files you intend to modify and the tests you will add or update.\n* **Test Thoroughly**: Implement comprehensive tests to ensure correctness and prevent regressions.\n* **Comment Intelligently**: Add comments to explain the \"why\" behind complex or non-obvious code, keeping in mind that the reader may not be a Kubernetes expert.\n* **No TODOs**: Leave no `TODO` comments, placeholders, or incomplete implementations.\n* **Prioritize Correctness**: Always prioritize security, scalability, and maintainability in your implementations.\n\n### Avoiding Loops\n\nWhen performing complex tasks, especially those involving code modifications and verification, it's important to avoid getting into loops. A loop can occur when the agent repeatedly tries the same action without success, or when it gets stuck in a cycle of analysis, action, and failure.\n\nTo avoid loops:\n* **Analyze the problem carefully**: Before taking any action, make sure you understand the problem and have a clear plan to solve it.\n* **Break down the problem**: Break down complex problems into smaller, more manageable steps.\n* **Verify each step**: After each step, verify that it was successful before moving on to the next one.\n* **Don't repeat failed actions**: If an action fails, don't just repeat it. Analyze the cause of the failure and try a different approach.\n* **Ask for help**: If you're stuck, don't hesitate to ask for help from the user.\n\n### Code Style\n\nThe project follows the standard Go code style and the official [Kubernetes coding conventions](https://www.k8s.dev/docs/guide/coding-convention/). All code should be formatted with `gofmt` and `goimports`. You can format the code by running the following commands:\n\n```bash\nmake gofmt\nmake goimports\n```\n\n### Linting\n\nThe project uses `golangci-lint` to lint the code. You can run the linter by running the following command:\n\n```bash\nmake verify-golangci-lint\n```\n\n### Dependencies\n\nThe project uses Go modules to manage dependencies. To add a new dependency, add it to the `go.mod` file and then run the following command:\n\n```bash\nmake gomod\n```\n\n### Commits\n\nThe project follows the conventional commit message format.\n\n### Contributions\n\nContributions are welcome! Before submitting a pull request, please open an issue to discuss your proposed changes. All pull requests must be reviewed and approved by a maintainer before they can be merged.\n\n## E2E CI Failure Troubleshooting\n\nFor investigating E2E CI job failures — including locating artifacts, diagnosing root causes, and finding correlations across failing jobs — see [docs/e2e-failure-troubleshooting.md](docs/e2e-failure-troubleshooting.md).\n\n## Updating Third-Party Dependencies\n\nFor updating any pinned third-party dependency — Go modules, addon manifests, node components,\nGitHub Actions, e2e scenario charts, and the regeneration/verification each one requires — see\n[docs/dependency-updates.md](docs/dependency-updates.md).\n\n\nA very simple DHCP server to support our testing of bare metal / VMs.\n\nMAC addresses map to IP addresses, so x:x:x:x:x:7 => x.x.x.7\n\n(Remember that the MAC address is in hex, and IP addresses are normally printed in decimal! So `:10` => `.16`)\n\n\nA very simple s3 mock to support our testing of bare metal / VMs.\n\nJust enough functionality to support our tests.\n\nWARNING: This component is not intended for real-world deployment. DO NOT USE for production.\n\n\n# Extensions\n\n**Extension Support is experimental.**\n\nThis directory contains support code for building Gnostic extensio handlers and\nassociated examples.\n\nExtension handlers can be used to compile vendor or specification extensions\ninto protocol buffer structures.\n\nLike plugins, extension handlers are built as separate executables. Extension\nbodies are written to extension handlers as serialized\nExtensionHandlerRequests.\n"}