Hacktoberfest 2026: los issues que los mantenedores marcaron para octubre, abiertos y aptos para principiantes. Explorar issues de Hacktoberfest

[Feature Request] Sync the modules from upstream Cloud Foundation Fabric and keep them current

Abierto
  • ¿Algo no está bien?
#308 0 comentarios 0 reacciones 0 asignados Ver en GitHub

Los mantenedores suelen responder en 1 día

@digitalresistor ya está trabajando en esto.

Desde el 20/10/2026.

  • #311 de @digitalresistor — abierto

Evaluación

Dificultad
5/5
Tiempo estimado
Más de una semana
Aptitud para principiantes
15/100
Tipo de issue
Nueva funcionalidad
Claridad
Bien especificado
Estado de actividad
Estancado
Stack tecnológico
github-actions, google-cloud, shell, terraform
Área
devops, infrastructure

Línea de trabajo

Start with modules/*/versions.tf to understand how each module records its upstream release, then read the proposed tools/sync-from-cff.sh workflow and docs/upstream-sync.md requirements. The issue calls for a reusable three-way sync, a weekly pull request workflow, a broad first upgrade, caller updates, and successful test deployments; pull request #311 is already open against this work.

Escrito por el modelo de indexación a partir del texto del issue.

Descripción

Documentation Enhancement Level of Effort - High Priority - Medium Scope - Module

Feature Description

Bring the modules under modules/ up to date with upstream Cloud Foundation Fabric, and keep them current with a repeatable sync.

  • A tools/sync-from-cff.sh script performs a three-way merge of each module from the Fabric release it was last synced from to a target release, so local Stellar Engine changes survive and conflicts surface instead of being overwritten.
  • A scheduled workflow runs the script every week against the latest Fabric release and opens or updates a single sync pull request.
  • A docs/upstream-sync.md guide documents the cadence, the procedure, and the Stellar Engine changes that each sync must preserve.

Use Case

The modules are 21 major Fabric releases behind, so fixes and features that upstream already ships keep being rediscovered and re-implemented here.

  • Every modules/*/versions.tf file records module_name = ".../modules/<name>:v38.0.0-tf", so the modules last synced from Fabric v38.0.0, released on 2025-02-21. Fabric is now at v59.2.0.
  • Fabric ships roughly one major and two minor releases a month. Stellar Engine has synced in four bulk copies since 2023, the last one in April 2025, and only cherry-picks fixes since then, as in #276. No document describes how to sync.
  • Fabric v59 requires Terraform >= 1.12.2 and the google provider >= 8.6.0, < 9.0.0. Stellar Engine still pins >= 1.10.2 and >= 6.21.0, < 7.0.0, which also blocks fixes that only exist for newer providers.
  • Of the 48 modules that fast/stages-aw/ and blueprints/ use, 34 are byte-identical to Fabric v38.0.0. The other 14 carry local changes, and about half of those are early copies of fixes that Fabric released later, between v38.1.0 and v49.3.0.
  • Upstream fixes that Stellar Engine lacks include a Cloud SQL replica PSC fix, a billing budget threshold_rules permadiff, VPC Service Controls null identity handling, GKE network tag permadiffs, and Pub/Sub IAM replacement fixes.
  • Fabric renamed its resource labels to snake_case and its module labels to kebab-case in v55.4.0, as #309 describes. A sync brings those renames, with their moved blocks, into the shared modules.

Proposed Solution

Sync tooling

  • The script reads each module's base release from its own versions.tf module_name, so organization-se and cloud-run-v2-se track their upstream organization and cloud-run-v2 modules automatically.

  • It fetches only the base and target release trees, then merges file by file:

    Situation Action
    Upstream unchanged Skip
    Local copy equals the base Take upstream
    Both sides changed Three-way merge with git merge-file
    File added upstream Add
    File deleted upstream Delete, or flag a conflict when the local copy changed
    Stellar Engine only file Keep

  • It never adds versions.tofu files, which .gemini/styleguide.md forbids, and it updates module_name to the target release.

  • It writes a report with per-module results, provider and Terraform constraint changes, and the upstream CHANGELOG.md entries between the two releases, with incompatible changes highlighted.

  • Shell tests cover the script with throwaway upstream and fork repositories.

First sync to v59.2.0
  • The first sync goes straight to the current Fabric release. Operators fork this repository before use, so the upgrade ships with an upgrade-note and updated documentation rather than a compatibility layer. An intermediate sync, such as v42.1.0 as the last release for the 6.x provider, can follow as a separate pull request if reviewers prefer smaller steps.
  • The pull request updates every caller in fast/stages-aw/ and blueprints/ for the module interface changes, such as net-vpc vpc_reuse, vpc-sc perimeters, the custom_roles object type and iam-service-account service_account_reuse, and fixes raw resources for the 7.0 and 8.0 provider upgrade guides.
  • It keeps the Stellar Engine changes that upstream lacks:
    • project and service account ID length preconditions;
    • default network removal;
    • firewall logging on by default;
    • the Spanner deletion_protection default;
    • the Assured Workloads CONSUMER_FOLDER handling in folder;
    • the organization-se changes;
    • the Pub/Sub outputs and the net-lb-app-ext port_name handling.
  • It raises the repository baseline in default-versions.tf, .gemini/styleguide.md and the documentation.
  • The pull request stays in draft until a fresh deployment of stages 0 to 3 and an upgrade from the current release both succeed in a test organization.
Ongoing cadence
  • A weekly workflow runs the script against the latest Fabric release, force-pushes a fixed chore/cff-sync branch, and opens or updates one pull request with the report in its body.
  • The workflow opens the pull request as a draft when the merge has conflicts or the release needs a new provider major version.
  • The workflow needs a GitHub App token, because pull requests opened with the default GITHUB_TOKEN do not trigger CI. Maintainers also decide how bot-authored commits satisfy the CLA check.
Scope limits
  • fast/stages-aw/ derives from the FAST stage generation that Fabric replaced in v44.0.0 and removed by v47.0.0, so the stages get ported changes, never synced files.
  • Modules that only exist in Stellar Engine, such as cis-log-metrics and private-service-connect, are out of the sync but move to the new provider baseline.

Compliance & Deployment Context

  • Target Deployment Type(s):
    • US Region Restricted (e.g., Access Policy constraint)
    • FedRAMP Moderate
    • FedRAMP High
    • DoD IL4
    • DoD IL5
    • All / General
  • Relevant NIST 800-53r5 Controls: SI-2 flaw remediation, CM-2 baseline configuration, CM-3 configuration change control

Reusability Check

Stellar Engine prioritizes reusability.

  • I have checked if this functionality can be achieved by extending an existing module or blueprint.
  • I have verified that this does not duplicate existing functionality.

Alternatives Considered

  • Keep cherry-picking upstream fixes by hand. This is the current approach, and it records no base release per change, so each later sync becomes harder.
  • Sync in provider-major steps, first to v42.1.0, then to the last 7.x release, then to v59. Each step is smaller to review, but the total work is larger, and every intermediate step needs its own test deployment.
  • Consume the upstream modules directly from the Fabric repository by ref. Stellar Engine changes several shared modules for its compliance needs, and some environments do not allow fetching third-party sources at deploy time, so vendoring remains the better fit.

Additional Context

  • Upstream renaming pull request: GoogleCloudPlatform/cloud-foundation-fabric#3930
  • Related: #309 adopts the upstream naming convention for the code that Stellar Engine owns.
Lenguaje dominante
HCL
Estrellas
58
Forks
25
Merge medio
1 d 19 h
PR fusionados (30 d)
53

Preparar el entorno

Primeros pasos

  1. Lee el issue completo y luego la guía de contribución del proyecto.
  2. Comenta en el issue que vas a ocuparte — evita que dos personas hagan lo mismo.
  3. Haz un fork del repositorio y trabaja en una rama.
  4. Abre un pull request que haga referencia al número del issue.

Más de google/stellar-engine

Todos los issues de google/stellar-engine

Issues similares

Más issues de DevOps

Recibe los nuevos issues en tu correo

Un resumen breve de issues de GitHub para principiantes.