Skip to content

fix: globally unique Object Storage bucket names must be the default #127

Closed

Description

@lweberru

Problem

The Accelerator derives Object Storage bucket names only from a configurable naming prefix and a purpose suffix. STACKIT bucket names share a global namespace. Two installations using the same prefix can therefore collide even when they use different projects or organizations.

A bootstrap Apply can create projects, networks and firewall VMs and then fail with HTTP 409 bucket.name_conflict, while the intended management project contains no bucket. This leaves a partially provisioned deployment whose durable checkpoint must be preserved.

Expected fix and acceptance criteria

  • Make project-qualified bucket naming the default, using the complete immutable owning project UUID and distinct bucket purpose suffixes.
  • Cover management and workload bucket naming; enforce the S3 63-character limit without truncating the UUID.
  • Keep OpenTofu resource addresses stable. Document explicit compatibility settings for existing buckets; never silently reset state, import a foreign bucket, or rename unrelated infrastructure.
  • Test distinct projects with identical prefixes, distinct purposes, maximum lengths, and explicit compatibility behavior.
  • Carry the reviewed native change through Configurator input/catalogue/compiler contracts and its immutable Runner source pin before declaring hosted execution fixed.
  • Document recovery from a partial bootstrap using the original checkpoint and a new reviewed Plan, with a separate Apply approval.

Close only with references to the merged fix, relevant test results, compatibility/recovery documentation, and the Configurator Runner integration. No customer identifiers, state, credentials or raw plans belong in this issue.

Related: #104 concerns ambiguity between Secrets Manager and bucket display names; this issue concerns cross-project global bucket-name collisions and failed provisioning.

Activity

  1. lweberru commented on Oct 21, 2026

    @lweberru
    CollaboratorAuthor

    The correction is implemented in draft PR #128. New management and workload buckets use the complete owning project UUID and distinct purpose suffixes by default; the naming logic truncates only the readable prefix to stay within 63 characters. Explicit legacy mode preserves existing names and requires deliberate migration/replacement review before switching.

    Native tests cover all management/workload purposes, distinct projects, the name-length limit and explicit legacy compatibility. The Configurator Runner is pinned to the corrected native source, and English/German documentation describes existing-installation compatibility and recovery from a retained partial-Apply checkpoint.

    The PR also corrects nullable Observability retention and adds shared live/static capability validation. Existing State and resource addresses are preserved; no customer infrastructure was changed. Assistant qualification and independent review remain pending. This issue stays open until the fixing PR is merged.

  2. lweberru commented on Oct 21, 2026

    @lweberru
    CollaboratorAuthor

    PR #128 is now ready for independent review. All checks pass on commit 75f28a1f544244128606c2b3365aeaca142cbf96, including 312 desktop/mobile browser cases and native validation. Source-bound Assistant qualification also passed: 118 cases across two repetitions and 13 continuous-dialogue steps.

    The PR documents project-qualified naming as the default, explicit legacy compatibility for existing buckets, and recovery using the retained exact checkpoint. Its Fixes #127 reference will close this issue on merge. The changes have not yet been deployed and no customer infrastructure was modified.

  3. lweberru commented on Oct 21, 2026

    @lweberru
    CollaboratorAuthor

    The corrected Configurator and platform Runner are now deployed to Dev in release 39608332090, source 7f8c2ed99f3b5290080d7ae2f847f4832fa4c9af, with native Accelerator pin 9e7fb46c329aca32e878ce1f0ea3b944ea240354.

    Build, native contracts, packaging/staging, database migration, public health/access checks and cold/warm Runner isolation checks all passed. Runtime pool size 1 and the enabled Assistant were independently confirmed. This was the explicit dev-skip-assistant-qualification release mode; it does not claim a fresh successful live-model qualification or weaken qualified releases.

    Project-qualified bucket naming is now available in the deployed planning path. Existing legacy buckets still require explicit compatibility/migration review. A partial Apply must resume through exact checkpoint review, a new preparation and a new reviewed Plan; no customer infrastructure Apply was performed during this delivery. The issue remains closed with the merged implementation and its English/German compatibility documentation.

  4. lweberru commented on Oct 21, 2026

    @lweberru
    CollaboratorAuthor

    Live platform acceptance update (2026-10-21)

    The operator supplied a successful real saved-plan Apply log and confirmed the completed workflow. The retained partial-bootstrap deployment was resumed through checkpoint review, explicit same-state reconciliation, a new credential profile, a new configuration revision/preparation and a newly reviewed saved Plan. Existing firewall VMs were preserved.

    Observed results: Apply complete! Resources: 13 added, 0 changed, 1 destroyed. The replacement was only the tainted terraform_data HA bootstrap step, not a firewall VM. Both backup and primary HA configuration commands completed successfully. All three project-qualified management buckets, Object Storage credentials, the audit archive destination, the Observability Starter instance and associated protected secret entries were created. The subsequent tofu init -migrate-state reported successful migration from the HTTP bootstrap backend to S3.

    Delivered by #128, #129 and #130 through Dev release 39608332090, with runner pool size 1. This was the explicit Dev qualification-exception mode, with the Assistant enabled; it is not production acceptance or a new successful full model qualification. Evidence here is a sanitized summary of operator-provided output, not independent access to customer infrastructure. Customer identifiers, credentials, raw plans and State are deliberately omitted.

    A clean follow-up Plan has not been independently established by the supplied log. Actual HA failover, packet paths and audit-event delivery were deferred. Hard Runner loss, interrupted backend migration, backup/restore and multi-tenant acceptance are not proven by this successful run.

    This adds real provisioning/recovery evidence to the already closed naming fix. All three management bucket creations succeeded without the former name-conflict error.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions