Skip to content

Commit 8f0d2d4

Browse files
srikxcipherclaude
andauthored
feat(templates): add v1 blueprint templates (observability, ingress, compute) (#339)
* feat(templates): add templates README Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com> * feat(templates): add observability template Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com> * feat(templates): add ingress template Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com> * feat(templates): add compute template Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com> * feat(templates): add source provenance block to all templates * fix(templates): correct observability input wiring Add output_name: "attributes" to kubernetes_details inputs in all observability resources so they wire to the kubernetes-details typed output rather than the eks typed default output. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com> * fix(templates): correct ingress input wiring - ingress.json: fix kubernetes_details output_name to "attributes" (nginx_gateway_fabric expects @facets/kubernetes-details, not @facets/eks); wire gateway_api_crd_details to existing gateway-crd resource with output_name "default" - cert-manager.json: wire gateway_api_crd_details to existing gateway-crd with output_name "default" - template.yaml: add gateway_api_crd/gateway-crd to requires Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com> * fix(templates): correct compute input wiring - karpenter.json: change eks_details resource_name from kubernetes-cluster to cluster (existing resource) and remove output_name "default" to match working project resource pattern - kubernetes-node-pool.json: change kubernetes_details resource_name from kubernetes-cluster to cluster and remove output_name "default" - template.yaml: add kubernetes_cluster/cluster to requires Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com> * chore(templates): shorten maintainer name to Facets * chore(templates): drop maintainer url field * docs(templates): rewrite README to match auto-fetch UX and validation findings * fmt * fix(templates): drop orphan, rename ingress, ship alert/dashboard defaults, slim README Addresses 4 of the 6 items in PR #339 review (commit 2 will follow with the cert-manager + gateway-api-crd extractions; commit 3 rewrites the architectural note). * compute: drop kubernetes-cluster.json (orphaned — karpenter and kubernetes-node-pool both reference an external kubernetes_cluster/cluster per requires:, so the in-bundle cluster was unused). Rename to 'EKS Compute Add-ons' since the template no longer ships a cluster. * ingress: rename ingress.json -> gateway-ing.json so filename stem matches metadata.name='gateway-ing' per the README convention. Update template.yaml resources: list accordingly. * observability/alert-rules.json: ship 5 baseline Kubernetes Prometheus alert rules (kube_pod_crash_looping, kube_node_not_ready, kubelet_down, high_memory_pressure, high_cpu_saturation) under a kubernetes_baseline alert group. Replaces the empty alert_groups: {} placeholder so the template earns its 'alerting stack' description. * observability/grafana-dashboards.json: ship a minimal Cluster Overview dashboard with 3 stat panels (Total Pods, Total Nodes, Healthy Targets). Replaces the empty dashboards: {} placeholder. Consumers can add more dashboards via the same dashboards: map. * templates/README.md: drop the multi-step 'Applying a template' walkthrough; raptor get bp-templates is fetch-only, apply is a separate command with its own help. Replaced with a single 'After fetching' breadcrumb pointing at raptor apply --help. Verification: jq parses all 9 resource JSONs cleanly. raptor apply --dry-run was attempted but the test CP (9988776655.dev.facets.cloud) was returning EOF on every call at commit time, so end-to-end validation against the live CP is pending re-test once the CP is back up. * feat(observability): replace synthetic dashboard with kube-state-metrics Replaces the placeholder 3-stat-panel dashboard from the previous commit with the real 'kube-state-metrics - pods by namespace' dashboard sourced from grafana.com Play (https://play.grafana.org/goto/cflgpp7d08hs0e). 29 panels covering pods by namespace status, container resource usage, and pod lifecycle events. The dashboard's UID, internal id, and version fields are stripped before embedding so consumers don't get UID conflicts on import. * feat(templates): extract cert-manager and gateway-api-crd as standalone templates Both resources were bundled in observability/ingress with the same metadata.name across templates, causing silent rewires when consumers applied multiple templates in sequence (the second apply would overwrite the first's input wiring). Reviewer flagged for cert-manager; gateway-api-crd had the same orphan pattern as compute's kubernetes-cluster (in-bundle resource not consumed by any sibling). Restructure: - New templates/cert-manager/ (category: security) — TLS foundation. Required inputs: kubernetes_cluster, kubernetes_node_pool. Optional inputs (gateway_api_crd, prometheus) left for consumer to add via override. - New templates/gateway-api-crd/ (category: network) — Gateway API CRDs foundation. metadata.name = 'gateway-api-crd' (matches filename convention). - observability/ drops cert-manager.json. Description trimmed to 'Prometheus + Grafana dashboards + alert rules'. requires: unchanged since prometheus/alert-rules/grafana-dashboards don't ref cert-manager in their inputs. - ingress/ drops cert-manager.json + gateway-api-crd.json. Updates gateway-ing.json's gateway_api_crd_details ref from 'gateway-crd' to 'gateway-api-crd' to match the standalone template's metadata.name. requires: lists cert_manager/cert-manager and gateway_api_crd/gateway-api-crd as externals. Workflow becomes: apply cert-manager and/or gateway-api-crd templates first (either or both, depending on which leaf templates the consumer plans to use), release, then apply observability or ingress. * fix(compute): rename node-pool to 'nodepool' so other templates can require it Other templates (cert-manager, gateway-api-crd, observability, ingress) list 'kubernetes_node_pool/nodepool' as an external requirement — matching the conventional default name from project-type bootstraps. Compute creates that resource for projects whose project-type doesn't include one (e.g. redesign-aws on facets-demo provides cluster + cloud + network + karpenter but no nodepool). Renames: templates/compute/kubernetes-node-pool.json -> templates/compute/nodepool.json metadata.name: 'kubernetes-node-pool' -> 'nodepool' template.yaml resources: list updated After this rename, applying the compute template fully bootstraps the nodepool dependency that the other foundational + leaf templates need. * docs(templates): rewrite architectural note for layered foundation pattern Reviewer flagged the previous README's claim — 'intra-template inputs point at resources the consumer's project is expected to have' — as inconsistent with the actual wiring. After the cert-manager and gateway-api-crd extractions plus the compute nodepool rename, the templates now form a clear two-tier layered architecture: - Foundational: compute, cert-manager, gateway-api-crd - Leaf: observability, ingress The new README has: - Architecture section explicitly listing which template provides what and which template consumes what. - Apply order section with the exact tested workflow (project bootstrap -> compute -> cert-manager + gateway-api-crd -> observability in two stages -> ingress). All steps were end-to-end verified against a fresh raptor-templates-test project on facets-demo. - Drops references to the old git-clone --refresh flow; raptor now fetches over HTTPS via the GitHub Contents API + raw URLs (per raptor PR #135). - Updates conventional input names: cert-manager (was missing) and gateway-api-crd (replaces 'gateway-crd', which only existed because the test project new-modules-9988776655 happened to have that name). - Mentions GITHUB_TOKEN/GH_TOKEN as the rate-limit lift. Honest about validator-blindness: intra-template chains exist (observability's alert-rules + grafana depend on its prometheus); the two-stage apply pattern documented in 'Apply order' is the workaround, not the previous handwave. * fix(ingress): switch to AWS-specific flavor + correct cluster output_name Senior re-review caught two related issues: * gateway-ing.json declared 'flavor: nginx_gateway_fabric' (cloud-neutral), but no 'modules/ingress/nginx_gateway_fabric/' exists in this repo — consumers following the README's 'verify against modules/<intent>/<flavor>/<version>/facets.yaml' advice can't find the schema. The cloud-suffixed nginx_gateway_fabric_aws/1.0 IS in the repo and applies correctly. * The same input also had 'output_name: "attributes"' (which serves @facets/kubernetes-details), but ingress/nginx_gateway_fabric_aws's kubernetes_details input is typed @facets/eks — served by the cluster's 'default' output. Type mismatch. Fixes: - gateway-ing.json: flavor 'nginx_gateway_fabric' -> 'nginx_gateway_fabric_aws' - gateway-ing.json: kubernetes_details.output_name 'attributes' -> 'default' - template.yaml: displayName + description now make AWS-only scope explicit; mention GCP/Azure variants will follow as separate templates. E2E verification deferred — facets-demo CP is currently down (MongoDB outage). Will re-test once it recovers. * fix(templates): README accuracy + CPU saturation aggregation + minor docs Senior re-review caught several smaller issues. Addressing all in one commit: * templates/README.md Architecture: split tables into Provides/Consumes + Cloud columns. Compute and ingress are now AWS-only and labeled as such; cert-manager, gateway-api-crd, observability are cloud-agnostic and labeled. Adds a footnote about future GCP/Azure/OVH variants. * templates/README.md Apply order: documents that compute requires a two-stage apply (karpenter.json first, then nodepool.json) when the consumer's project type doesn't already include karpenter. Adds a new 'Adapting to a different bootstrap' subsection telling consumers to rewrite resource_name refs in the downloaded JSONs if their project uses non-conventional names. * templates/README.md Conventions: corrects the @facets/kubernetes-details consumers list — the AWS ingress flavor (nginx_gateway_fabric_aws) uses @facets/eks, not @facets/kubernetes-details, so it belongs in the 'output_name: default' bucket. Adds a note that input KEY names aren't uniform across modules (alert_rules/prometheus calls the cluster input 'kubernetes_cluster', not 'kubernetes_details'). * templates/README.md template.yaml schema: adds a one-line note on bumping version on backwards-incompatible changes. * templates/observability/alert-rules.json high_cpu_saturation: the expression (1 - rate(node_cpu_seconds_total{mode="idle"}[5m])) > 0.9 produced a per-CPU-per-instance series and only fired when EVERY core on a node was >90%. Fixed to (1 - avg by (instance) (rate(...))) > 0.9 which fires on a per-instance avg-utilization basis. --------- Co-authored-by: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
1 parent a822710 commit 8f0d2d4

14 files changed

Lines changed: 613 additions & 0 deletions

File tree

templates/README.md

Lines changed: 220 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,220 @@
1+
# Blueprint Templates
2+
3+
This directory holds curated bundles of Facets blueprint resources. Each
4+
subdirectory is one template. Raptor's `get bp-templates` command
5+
fetches templates from this repo over HTTPS at runtime — consumers do
6+
**not** need to clone the repo manually.
7+
8+
## Layout
9+
10+
```
11+
templates/
12+
├── README.md (this file)
13+
└── <template-name>/
14+
├── template.yaml (metadata; required)
15+
└── *.json (resource JSONs; one per file)
16+
```
17+
18+
## Architecture
19+
20+
Templates are split into two tiers:
21+
22+
**Foundational templates** ship a single low-level platform resource
23+
that other templates depend on. Apply these first to any project that
24+
doesn't already have the equivalent resource.
25+
26+
| Template | Provides | Cloud |
27+
|---|---|---|
28+
| `compute` | `karpenter/karpenter` (updates if present) and `kubernetes_node_pool/nodepool` | AWS-only (uses `karpenter/default/1.0` and `kubernetes_node_pool/karpenter/1.0`) |
29+
| `cert-manager` | `cert_manager/cert-manager` for TLS issuance | cloud-agnostic |
30+
| `gateway-api-crd` | `gateway_api_crd/gateway-api-crd` for Gateway API CRDs | cloud-agnostic |
31+
32+
**Leaf templates** ship a complete stack that consumes foundational
33+
resources via their `requires:` declarations.
34+
35+
| Template | Consumes | Cloud |
36+
|---|---|---|
37+
| `observability` | `cluster`, `nodepool` — ships prometheus + alert-rules + grafana-dashboards | cloud-agnostic |
38+
| `ingress` | `cluster`, `nodepool`, `cert-manager`, `gateway-api-crd` — ships the NGINX Gateway Fabric ingress on AWS (`nginx_gateway_fabric_aws/1.0`) | AWS-only |
39+
40+
GCP / Azure / OVH variants of `compute` and `ingress` will land as
41+
separate templates (e.g. `compute-gcp`, `ingress-azure`) following the
42+
same pattern.
43+
44+
Most leaves contain an internal dependency chain too (e.g. observability's
45+
`alert-rules` and `grafana-dashboards` reference its `prometheus`).
46+
Raptor's per-file `apply` validator only sees resources that already
47+
exist in the target project — co-applied siblings in the same
48+
`apply -f <dir>` batch are invisible to it. The two-stage apply pattern
49+
below works around this honestly.
50+
51+
## Apply order
52+
53+
The end-to-end workflow that has been tested against a fresh project
54+
(`redesign-aws` project type, no extra customization). Other project
55+
types may name resources differently — see "Adapting to a different
56+
bootstrap" below.
57+
58+
```bash
59+
# 0. Project bootstrap provides: cluster, cloud, network (+ karpenter)
60+
61+
# 1. Apply compute — creates kubernetes_node_pool/nodepool, updates karpenter.
62+
# If your project's bootstrap doesn't already include karpenter, apply
63+
# karpenter.json first (release), then nodepool.json — kubernetes-node-pool
64+
# references karpenter and the validator can't see co-applied siblings.
65+
raptor get bp-templates compute --save-to ./compute/
66+
raptor apply -f ./compute/ -p PROJECT
67+
68+
# 2. Apply foundational add-ons (each independent of the others)
69+
raptor get bp-templates cert-manager --save-to ./cm/
70+
raptor apply -f ./cm/ -p PROJECT
71+
raptor get bp-templates gateway-api-crd --save-to ./gac/
72+
raptor apply -f ./gac/ -p PROJECT
73+
74+
# 3. Apply observability in two stages (alert-rules + grafana depend on
75+
# prometheus, which is in the same template)
76+
raptor get bp-templates observability --save-to ./obs/
77+
raptor apply -f ./obs/prometheus.json -p PROJECT
78+
raptor apply -f ./obs/alert-rules.json -f ./obs/grafana-dashboards.json -p PROJECT
79+
80+
# 4. Apply ingress (consumes cert-manager and gateway-api-crd)
81+
raptor get bp-templates ingress --save-to ./ing/
82+
raptor apply -f ./ing/ -p PROJECT
83+
```
84+
85+
Resources ship `disabled: true`. After applying, enable them and trigger
86+
a release.
87+
88+
### Adapting to a different bootstrap
89+
90+
These templates assume conventional resource names: `cluster` (for
91+
`kubernetes_cluster`), `nodepool`, `cloud`, `network`, `cert-manager`,
92+
`gateway-api-crd`, `prometheus`. If your project's bootstrap uses
93+
different names, edit the downloaded JSONs' `inputs.<key>.resource_name`
94+
values before applying — `raptor get bp-templates <name>` writes them to
95+
disk first, so the consumer (or AI agent) can rewrite refs in place.
96+
97+
## template.yaml
98+
99+
```yaml
100+
name: <template-name> # required, must match dir name
101+
displayName: <human name> # required
102+
description: <one paragraph> # required
103+
category: <observability|network|compute|security|...> # required
104+
version: "1.0" # required; bump on backwards-incompatible changes
105+
# (resource removed, requires: tightened, etc.)
106+
tags: [list, of, tags] # optional
107+
maintainers: # optional
108+
- name: <name>
109+
resources: # optional; if omitted, *.json sorted alphabetically
110+
- cert-manager.json
111+
- prometheus.json
112+
requires: # optional but encouraged; documents externals
113+
- kubernetes_cluster/cluster
114+
- kubernetes_node_pool/nodepool
115+
source: # optional; provenance for --details / -o yaml
116+
gitUrl: https://github.com/Facets-cloud/facets-modules-redesign.git
117+
gitRef: main
118+
path: templates/<template-name>
119+
```
120+
121+
## Resource JSONs
122+
123+
Each `*.json` is a Facets resource definition with the shape:
124+
125+
```json
126+
{
127+
"kind": "<intent>",
128+
"flavor": "<flavor>",
129+
"version": "<schema-version>",
130+
"metadata": {"name": "<resource-name>"},
131+
"disabled": true,
132+
"spec": { ... },
133+
"inputs": { ... }
134+
}
135+
```
136+
137+
Conventions:
138+
- Ship with `disabled: true` so the consumer reviews before triggering a release.
139+
- `metadata.name` matches the filename stem (`prometheus.json` →
140+
`metadata.name: "prometheus"`). Raptor's loader enforces this.
141+
- `inputs` references use conventional default names (`cluster`,
142+
`cloud`, `network`, `nodepool`, `cert-manager`, `gateway-api-crd`) so
143+
externals line up with what foundational templates provide and with
144+
what `requires:` lists.
145+
- For inputs that consume a Kubernetes cluster, set `output_name`
146+
explicitly. The right value depends on what the consuming module's
147+
`kubernetes_details` (or equivalent) input declares as its `type:`:
148+
- `@facets/kubernetes-details` (cloud-agnostic) → `output_name: "attributes"`
149+
— used by cert-manager, prometheus, grafana-dashboards, gateway-api-crd.
150+
- `@facets/eks` (or `@facets/gke` / `@facets/azure_aks`, cloud-specific) →
151+
`output_name: "default"` (or omitted) — used by karpenter,
152+
kubernetes_node_pool, **and the AWS ingress flavor**
153+
(`nginx_gateway_fabric_aws`). Always check the producing module's
154+
`facets.yaml` to be sure.
155+
- Input KEY names are dictated by the consuming module's `facets.yaml`
156+
and aren't always uniform — e.g. most modules call the Kubernetes
157+
cluster input `kubernetes_details`, but `alert_rules/prometheus`
158+
calls it `kubernetes_cluster`. Mirror what the module declares
159+
rather than guessing.
160+
161+
## Verifying resources
162+
163+
Before authoring a resource JSON, inspect the producing module's
164+
`facets.yaml` in `modules/<intent>/<flavor>/<version>/facets.yaml` — the
165+
`inputs:` block declares each input's `type:` (e.g. `@facets/eks` vs
166+
`@facets/kubernetes-details`), and the `outputs:` block of the producer
167+
declares which output emits which type.
168+
169+
For an extra check against a real control plane, fetch a known-working
170+
resource:
171+
172+
```bash
173+
FACETS_PROFILE=<profile> raptor get resource <kind>/<name> -p <project> -o json
174+
```
175+
176+
…and mirror its `inputs` shape (resource_type / resource_name /
177+
output_name).
178+
179+
## Consuming templates
180+
181+
```bash
182+
# List
183+
raptor get bp-templates
184+
raptor get bp-templates -o wide # adds REQUIRES column
185+
raptor get bp-templates --category observability # filter
186+
187+
# Inspect metadata without saving
188+
raptor get bp-templates observability --details
189+
raptor get bp-templates observability --details -o yaml # full metadata incl. source
190+
191+
# Download to disk (default ./bp-templates/<name>/)
192+
raptor get bp-templates observability
193+
raptor get bp-templates observability --save-to ./obs/
194+
raptor get bp-templates observability --include-metadata # also write template.yaml
195+
196+
# Print to stdout instead of saving (pipe-friendly)
197+
raptor get bp-templates observability -o json
198+
```
199+
200+
Override the upstream fetch with a local checkout (useful when
201+
iterating on templates locally before opening a PR):
202+
203+
```bash
204+
# Flag form
205+
raptor get bp-templates --templates-dir /path/to/facets-modules-redesign/templates
206+
207+
# Env form (composable with scripts)
208+
export FACETS_TEMPLATES_DIR=/path/to/facets-modules-redesign/templates
209+
raptor get bp-templates
210+
```
211+
212+
GitHub's unauthenticated rate limit is 60/hr per IP. Set
213+
`GITHUB_TOKEN` or `GH_TOKEN` to lift it to 5000/hr if needed.
214+
215+
## After fetching
216+
217+
`raptor get bp-templates` is fetch-only — it does not apply. See
218+
`raptor apply --help` for the applying half. Resources ship
219+
`disabled: true`, so review them and enable selectively (or via a
220+
per-environment override) before triggering a release.
Lines changed: 21 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,21 @@
1+
{
2+
"kind": "cert_manager",
3+
"flavor": "standard",
4+
"version": "1.1",
5+
"metadata": {"name": "cert-manager"},
6+
"disabled": true,
7+
"spec": {
8+
"cert_manager": {}
9+
},
10+
"inputs": {
11+
"kubernetes_details": {
12+
"output_name": "attributes",
13+
"resource_type": "kubernetes_cluster",
14+
"resource_name": "cluster"
15+
},
16+
"kubernetes_node_pool_details": {
17+
"resource_type": "kubernetes_node_pool",
18+
"resource_name": "nodepool"
19+
}
20+
}
21+
}
Lines changed: 21 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,21 @@
1+
name: cert-manager
2+
displayName: Cert-Manager
3+
description: >
4+
TLS certificate management via cert-manager. Foundational template
5+
consumed by observability and ingress; apply this first if either of
6+
those needs cert-manager and the consumer's project doesn't already
7+
have one.
8+
category: security
9+
version: "1.0"
10+
tags: [tls, certificates, cert-manager]
11+
maintainers:
12+
- name: Facets
13+
resources:
14+
- cert-manager.json
15+
requires:
16+
- kubernetes_cluster/cluster
17+
- kubernetes_node_pool/nodepool
18+
source:
19+
gitUrl: https://github.com/Facets-cloud/facets-modules-redesign.git
20+
gitRef: main
21+
path: templates/cert-manager

templates/compute/karpenter.json

Lines changed: 25 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,25 @@
1+
{
2+
"kind": "karpenter",
3+
"flavor": "default",
4+
"version": "1.0",
5+
"metadata": {"name": "karpenter"},
6+
"disabled": true,
7+
"spec": {
8+
"karpenter_version": "1.5.0",
9+
"karpenter_replicas": 2
10+
},
11+
"inputs": {
12+
"cloud_account": {
13+
"resource_type": "cloud_account",
14+
"resource_name": "cloud"
15+
},
16+
"eks_details": {
17+
"resource_type": "kubernetes_cluster",
18+
"resource_name": "cluster"
19+
},
20+
"network_details": {
21+
"resource_type": "network",
22+
"resource_name": "network"
23+
}
24+
}
25+
}

templates/compute/nodepool.json

Lines changed: 34 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,34 @@
1+
{
2+
"kind": "kubernetes_node_pool",
3+
"flavor": "karpenter",
4+
"version": "1.0",
5+
"metadata": {"name": "nodepool"},
6+
"disabled": true,
7+
"spec": {
8+
"instance_families": ["t3", "t3a", "m5"],
9+
"instance_sizes": ["medium", "large", "xlarge"],
10+
"capacity_types": ["on-demand", "spot"],
11+
"architecture": ["amd64"],
12+
"cpu_limits": "1000",
13+
"memory_limits": "1000Gi",
14+
"enable_consolidation": true
15+
},
16+
"inputs": {
17+
"cloud_account": {
18+
"resource_type": "cloud_account",
19+
"resource_name": "cloud"
20+
},
21+
"kubernetes_details": {
22+
"resource_type": "kubernetes_cluster",
23+
"resource_name": "cluster"
24+
},
25+
"karpenter_details": {
26+
"resource_type": "karpenter",
27+
"resource_name": "karpenter"
28+
},
29+
"network_details": {
30+
"resource_type": "network",
31+
"resource_name": "network"
32+
}
33+
}
34+
}

templates/compute/template.yaml

Lines changed: 22 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,22 @@
1+
name: compute
2+
displayName: EKS Compute Add-ons
3+
description: >
4+
Karpenter controller + Karpenter-managed node pool on top of an existing
5+
EKS cluster. Adds cost-efficient, just-in-time node provisioning to a
6+
cluster the consumer's project already has.
7+
category: compute
8+
version: "1.0"
9+
tags: [eks, kubernetes, karpenter, autoscaling]
10+
maintainers:
11+
- name: Facets
12+
resources:
13+
- karpenter.json
14+
- nodepool.json
15+
requires:
16+
- cloud_account/cloud
17+
- network/network
18+
- kubernetes_cluster/cluster
19+
source:
20+
gitUrl: https://github.com/Facets-cloud/facets-modules-redesign.git
21+
gitRef: main
22+
path: templates/compute
Lines changed: 22 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,22 @@
1+
{
2+
"kind": "gateway_api_crd",
3+
"flavor": "default",
4+
"version": "1.0",
5+
"metadata": {"name": "gateway-api-crd"},
6+
"disabled": true,
7+
"spec": {
8+
"channel": "experimental",
9+
"version": "v1.4.1"
10+
},
11+
"inputs": {
12+
"kubernetes_details": {
13+
"output_name": "attributes",
14+
"resource_type": "kubernetes_cluster",
15+
"resource_name": "cluster"
16+
},
17+
"kubernetes_node_pool_details": {
18+
"resource_type": "kubernetes_node_pool",
19+
"resource_name": "nodepool"
20+
}
21+
}
22+
}
Lines changed: 21 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,21 @@
1+
name: gateway-api-crd
2+
displayName: Gateway API CRDs
3+
description: >
4+
Installs the Kubernetes Gateway API CustomResourceDefinitions.
5+
Foundational template required by the ingress template; apply this
6+
first if the consumer's project doesn't already have a
7+
gateway_api_crd resource.
8+
category: network
9+
version: "1.0"
10+
tags: [gateway-api, crd, kubernetes]
11+
maintainers:
12+
- name: Facets
13+
resources:
14+
- gateway-api-crd.json
15+
requires:
16+
- kubernetes_cluster/cluster
17+
- kubernetes_node_pool/nodepool
18+
source:
19+
gitUrl: https://github.com/Facets-cloud/facets-modules-redesign.git
20+
gitRef: main
21+
path: templates/gateway-api-crd

0 commit comments

Comments
 (0)