Skip to content

Add Ravion (IDP) module definition for modules/quilt - #127

Draft
drernie wants to merge 3 commits into
mainfrom
add-ravion-support-126
Draft

Add Ravion (IDP) module definition for modules/quilt#127
drernie wants to merge 3 commits into
mainfrom
add-ravion-support-126

Conversation

@drernie

@drernie drernie commented Jul 27, 2026

Copy link
Copy Markdown
Member

Summary

  • Adds examples/ravion/ with module.yaml, a Ravion module definition that wraps modules/quilt and modules/cnames unmodified — same provider/module "quilt"/parameters pattern as examples/main.tf.
  • Certificate and DNS are composed via typed $ref inputs (certificate_ref, dns_ref) rather than hand-copied ARNs/zone IDs.
  • Derives Quilt's full hostname contract (catalog + registry + s3-proxy) in main.tf's local.hostnames/hostnames output, so Ravion can validate the referenced certificate's SAN coverage before apply.
  • CloudFormation template is fetched at plan/apply time via template_url — nothing generated or internal is committed to the repo.
  • README.md documents the wrapper pattern and the cross-account composition case (deploying account ≠ domain-owning account).

Closes #126.

Test plan

  • terraform init -backend=false + terraform validate pass in examples/ravion/
  • Reviewed by someone with current Ravion module-schema access, since module.yaml's exact field names/types are inferred from the issue's evaluation notes rather than verified against live Ravion docs
  • Dry-run through an actual Ravion-connected account, per the issue's acceptance criteria

🤖 Generated with Claude Code

drernie and others added 3 commits July 27, 2026 08:44
Adds examples/ravion/ with a module.yaml Ravion module definition
wrapping modules/quilt and modules/cnames unmodified, typed $ref
composition for certificate + DNS, and derived catalog/registry/
s3-proxy hostname coverage so a cert missing a SAN fails before
apply instead of at TLS negotiation. No CloudFormation template is
committed; template_url is fetched at plan/apply time.

Closes #126

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
module.yaml was written against a guessed DSL that doesn't correspond to
any real Ravion schema key: inputs as a map instead of an array, `type:
ref` instead of `type: "$ref:<module-type>"`, a top-level `outputs:` key
(Terraform outputs are exposed automatically as stack.output.*), and
top-level `source`/`template` keys that don't exist in the schema at all.
Rewritten and verified by registering it against a live Ravion org
(module definition create + module version create --config, schema
render), then torn down — no AWS resources were touched.

Also fixes main.tf: modules/quilt's template_file input requires a local
path (it's filemd5()'d and uploaded to S3), so passing template_url
straight through as a URL string would fail at apply. Fetches it via
data "http" + local_file instead.

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Standing up a Quilt deployment through Ravion means three sequential
ravion module create calls (rvn-route53, rvn-acm-certificate, quilt-catalog),
with the caller computing the -registry/-s3-proxy hostnames by hand and
hand-copying two minst_… ids into the third call. This script derives the
hostnames the same way main.tf does and threads the ids through, so a
deployment is one command instead of three coordinated ones.

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

Add official Ravion (IDP) support for deploying modules/quilt

1 participant