Provide a Terraform AWS reference deployment and reuse it for release smoke tests

Aperta
  • Qualcosa non va?
#224 0 commenti 0 reazioni 1 assegnatario Vedi su GitHub

I maintainer di solito rispondono entro 1 giorno

@ThomasK33 ci sta già lavorando.

Dal 11/9/2026.

Valutazione

Questa issue non è ancora stata valutata.

Descrizione

Goal

Make the AWS smoke-test deployment the reference implementation users can deploy themselves. A user with an AWS account and the documented credentials/inputs should be able to run Terraform and get a working open.storage service without manually assembling IAM, networking, storage, compute, bootstrap configuration, or a load balancer.

The primary deliverable is the usable reference deployment. Release smoke tests must exercise that same implementation, rather than a separate CI-only setup that can pass while the documented user path is broken.

User journey

  1. Start with a clean AWS account, configure the documented AWS credentials and region, and select a pinned open.storage release.
  2. Run the documented Terraform initialization and apply commands with minimal required inputs.
  3. Terraform provisions the required IAM, networking, storage, EC2 instance/service, and load balancer. Bootstrap configuration starts open.storage without manual SSH setup.
  4. Read Terraform outputs for the usable endpoint and follow the included authentication/client example to create a repository, write through the API, and clone/push with ordinary Git.
  5. Keep the deployment for evaluation or remove it using the documented teardown procedure.

Acceptance criteria

  • Ship version-controlled Terraform configuration, concise documentation, and a small runnable example that together implement this user journey in a clean user AWS account. State the unavoidable prerequisites clearly; there must be no undocumented organization-specific infrastructure or maintainer-only setup.
  • Provision all dependencies for one clearly documented default storage topology, including persistence and the required AWS permissions. Make backend limitations explicit; any S3-only option remains experimental until its separate promotion criteria are met.
  • Bootstrap the pinned release and service configuration using cloud-init or an equivalent reproducible mechanism. Define service startup, health checks, restart behavior, and access through the load balancer.
  • Expose Terraform outputs for the service URL and useful connection details. Use the load balancer's DNS endpoint where appropriate; do not assume every load balancer provides a stable IP. Consider an optional wildcard-DNS convenience domain, but keep custom-domain ownership optional and document how TLS works without hidden manual steps.
  • Provide a complete authentication bootstrap. The server needs the organization's public verification key; the organization/test client retains the private signing key used to mint JWTs. Make key generation, delivery, and client use straightforward without exposing private keys through ordinary Terraform outputs, cloud-init logs, or committed files. Document any sensitive Terraform-state implications of the chosen design.
  • Run the automated smoke suite against exactly this reference deployment: create a repo, perform API reads/writes, Git clone/fetch/push, and Git LFS round-trips through the advertised endpoint. Assert authorization failures as well as successful access.
  • Use the same Terraform inputs and documented client path for release-candidate checks. Record the tested release artifact/commit, Terraform/provider versions, deployment inputs excluding secrets, logs, and results so a user or maintainer can reproduce failures.
  • Validate the clean-account path for release readiness. Separate any AWS account-vending/bootstrap machinery from the deployable reference so ordinary users can bring their existing account. Fresh-account runs should catch assumptions about resources left behind by prior tests.
  • Define the recurring CI cadence, ownership, failure notification, and release gate. Proposed starting point: small daily real-S3 coverage, a fuller weekly deployment/recovery run, and full acceptance for each release candidate; finalize according to runtime and budget. Do not maintain a divergent testing-only Terraform implementation.
  • Provide dependable cleanup and document whether teardown retains or deletes repository data. Automated runs must verify cleanup, bound runtime/resource usage, and detect leaked resources.

Relationship to launch readiness

This is the implementation and reference-deployment tracking issue for the real-AWS launch blocker. Its smoke tests supply repeatable evidence to that blocker; a successful apply alone does not satisfy full AWS compatibility validation. The existing S3-only promotion tracker retains ownership of experimental-to-supported criteria.

Start with the requested EC2 deployment. EKS can be a separate reference variant if Kubernetes support is part of the intended launch offering.

This issue records the requested work. It does not provision accounts or resources, start scheduled jobs, or authorize cloud spend.

Lingua principale
Go
Stelle
0
Fork
0
Merge medio
6h 16m
PR unite (30g)
243

Preparare l'ambiente

Come iniziare

  1. Leggi tutta la issue e poi la guida ai contributi del progetto.
  2. Commenta sulla issue per dire che te ne occupi tu — evita che due persone facciano lo stesso lavoro.
  3. Fai un fork del repository e lavora su un branch.
  4. Apri una pull request che faccia riferimento al numero della issue.

Altre issue di coder/openstorage

Tutte le issue di coder/openstorage

Issue simili

Altre issue su Go

Ricevi le nuove issue nella tua casella

Un breve riepilogo di issue GitHub adatte ai principianti.