feat: add Compute Engine and storage SDK contracts

[vedit]

Summary

Add a persistent Compute Engine REST control plane so official SDK clients can create networks, run VM and disk lifecycles, restore images and snapshots, and configure a global external HTTP Application Load Balancer locally. Also add GCS XML multipart uploads and project-scoped Monitoring time-series access, with Java and Ruby SDK contracts across JVM and native runtimes.

Related to #100: the network/subnet/firewall/address implementation overlaps that request. The issue remains unassigned, and its existing comment expresses another contributor's interest; no competing Compute networking PR was open when checked. This PR does not automatically close the issue or claim gcloud/Terraform coverage.

The contribution is assembled from topic commits for Ruby compatibility, Compute foundations, instances/disks, images/snapshots, load balancing, GCS multipart, and Monitoring isolation. Follow-up protocol fixes and shared SDK tests are included here so reviewers have the complete tested implementation.

Type of change

• Bug fix (fix:)
• New feature (feat:)
• Breaking change (feat!: or fix!:)
• Docs / chore

GCP Compatibility

• Native /compute/v1/projects/... paths and separate scoped Compute operations, including polling/wait/delete, request-ID deduplication, optimistic fingerprints, pagination, reference checks, and restart recovery. Resource configuration is recorded at request acceptance; operation status advances from persisted timestamps during reads/polling.
• Synthetic placement catalogs; VPCs, subnets, firewalls and IPv4 addresses; instance power/configuration changes; zonal disks, retention and Hyperdisk performance fields; global images/snapshots and restoration.
• Zonal GCE_VM_IP_PORT NEGs, global health checks, backend services, URL maps, HTTP target proxies and forwarding rules, including shared-resource cleanup validation.
• Native GCS XML multipart initiate/parts/list/complete/abort, retries and independent final-byte checks. Fix empty content-type downloads. Existing ordinary, signed, resumable, range and downscoped transfers are exercised.
• Explicit project-scoped Monitoring storage fixes cross-project gRPC time-series leakage. Deterministic network-counter fixtures cover filtering, windows, pagination and aggregation.
• Official Java SDK: Compute 1.106.0, Storage 2.72.0, Monitoring 3.97.0 (BOM 26.87.0). Official Ruby SDK: Compute 3.9.1, Storage 1.62.0, Monitoring 1.10.1 on Ruby 3.4.5 with locked dependencies. XML multipart uses Java's MultipartUploadClient and Ruby-signed HTTP requests. No gcloud verification is claimed.

Validation

SDK failure correction (2026-09-11)

Source 060bb64881e8811b069a9c3cf6d217fe6c7c255f, including fix 9b4d6c8 and an upstream merge to resolve the GCS write-lock conflict.

The Java BOM upgrade in this PR exposed two existing compatibility gaps in the failed Java SDK job:

• GcsGrpcTest: gRPC bucket responses used the project ID where Storage v2 requires a project number on output. The mapper now uses the existing stored project number. Regression coverage checks create/get/list/update and compares official Java REST/gRPC bucket metadata.
• GcsServiceAccountAuthenticationTest: successful SDK calls did not populate the original credential object's access-token cache. The test now captures outgoing Authorization headers at request execution and verifies nonempty Bearer credentials for bucket create/read, while preserving normal SDK credential handling and cleanup.

Both tests now run in the fork's native contract workflow as well as the complete upstream compatibility suite. The upstream merge preserves bucket-before-object locking for both ordinary and XML multipart writes.

Current validation:

• 289/289 full Java SDK tests passed locally with TLS, Cloud Run execution, PostgreSQL 16/17/18 and GKE enabled; no failures or skips.
• 289/289 focused GCS/Eventarc/GKE JVM tests passed.
• 1,046/1,046 hosted JVM tests passed. Workflow and JUnit evidence.
• 32/32 native Java/Ruby SDK and restart checks passed, including both previously failing Java tests; no failures or skips. Native image sha256:2e986ea09647e51e4236fbc5929c877a60e26002c93e65c31bbbb23b37e6aefd; binary SHA-256 75959e6475128794447657be503191f67df386a666ca65fdc7794f94cf7417d5 (Linux arm64).
• Local containers, network and all fixture volumes were removed.

The local JVM TLS harness explicitly allowed Docker Host headers behind its loopback proxy (QUARKUS_HTTP_HOST_VALIDATION_REQUIRE_LOCALHOST=false); this is a harness setting, not a source/configuration change. A preliminary SQL run timed out downloading PostgreSQL 17; after warming the images, the complete final SDK run passed. Upstream's new checks currently require maintainer approval; the contributor account cannot approve them.

Earlier review validation (9ad82ec)

Successful JVM/native workflow and downloadable JUnit evidence, source 9ad82ec71238a28345314182e4485b8a83295126:

• All 986 hosted JVM regression tests passed, including the new address and serialized-notification regressions and existing Docker-backed Cloud Run tests.
• Native image built successfully; all 30 Java/Ruby SDK and restart checks passed. No failures or skips.
• Native image: sha256:8ad9f2dcd7149735194ce773e5b8386b33bcfdf1a6bd56f9b051d4578b60dce4 (Linux arm64).
• Native binary SHA-256: fe206716c9b340ec34e74590949dd35dedc9e1f7f4a46143f351ef7b7b673b38.
• The local socket-free JVM run passed 982 tests; the four Docker-backed tests run in hosted CI. Focused Compute/GCS/Eventarc validation passed 47 tests.
• Negative controls restore the original implementations under the new tests: the prefix-name collision, mutable forwarding IP and stale multipart event ETag fail as expected. Native in-use address release remains a passing behavior.

Ruby joins the existing compatibility matrix and matching cache-warming matrix, including Gemfile/Gemfile.lock triggers. The dedicated cloud-contracts workflow runs full JVM regression, builds native, runs both SDK suites on an isolated Docker network and verifies unfinished uploads/operations and address allocation after restart. It records source, image and runtime identifiers. Other language/IaC suites were not rerun in this contribution's dedicated workflow.

The successful result is attempt 2. Attempt 1 was canceled after the unchanged upstream TlsProxyServerTest stopped producing output; the same commit passed on retry without changing implementation or test expectations.

Intentional limits

This models resource metadata, not guest execution, guest disk contents, traffic forwarding, health probes or certificates. Catalogs and Hyperdisk validation cover a basic synthetic subset. Cross-project Compute references, Shared VPC, IPv6, regional/multiwriter disks and advanced route rules are unsupported.

GCS pending-upload delimiter grouping is unsupported. Multipart publication and session removal use separate checkpoints, so completion is not crash-atomic. Signed URL cryptographic signatures are not validated; accepting a URL is not proof of signature enforcement. Credential Access Boundary checks cover the existing prefix/role subset, not full IAM.

Checklist

• JVM regression passes: all 1,046 hosted tests on the current head, including Docker-backed coverage
• New or updated integration test added
• Commit messages follow Conventional Commits

[greptile-apps]

Greptile Summary

This PR adds persistent Compute Engine control-plane contracts, GCS XML multipart uploads and storage consistency fixes, project-isolated Monitoring time series, and Java/Ruby SDK compatibility coverage. Changes since the previous review additionally expand GKE node-pool and ClusterManager behavior, harden GCS persistence and bucket deletion, and broaden native SDK validation.

• Implements scoped Compute resources, operations, persistence, deduplication, and load-balancer configuration.
• Adds multipart upload lifecycle support across GCS XML clients and aligns stored metadata with emitted notifications.
• Introduces dedicated GKE node-pool persistence with startup migration and broader REST API coverage.
• Makes non-empty bucket deletion atomic with object mutations and supports legacy NUL-containing object keys.
• Adds Java and Ruby SDK suites, restart contracts, documentation, and compatibility cache warming.

Confidence Score: 5/5

The PR appears safe to merge, with no outstanding previous findings or accepted new defects.

The three resolved behavioral findings remain fixed, and the previously open Ruby cache-warming finding is fully addressed by the matching matrix entry and Gemfile triggers. Recent GCS migration, bucket-deletion, GKE persistence, and SDK-test changes include the necessary synchronization, migration guards, and focused coverage.

Important Files Changed

Filename	Overview
src/main/java/io/floci/gcp/services/compute/ComputeService.java	Coordinates persistent Compute projects, scoped operations, request deduplication, and resource lifecycle behavior.
src/main/java/io/floci/gcp/services/gcs/GcsService.java	Adds multipart publication behavior, atomic bucket deletion, encoded object keys, and restart-safe legacy-key migration.
src/main/java/io/floci/gcp/services/gke/GkeService.java	Adds separately persisted node pools, startup migration, and expanded cluster and node-pool operations.
src/main/java/io/floci/gcp/services/cloudmonitoring/CloudMonitoringService.java	Scopes time-series storage and retrieval by project to prevent cross-project visibility.
.github/workflows/cloud-contracts.yml	Builds the native emulator and runs isolated Java and Ruby SDK and restart contracts.
.github/workflows/warm-compat-caches.yml	Keeps the cache-warming matrix and Ruby dependency triggers aligned with compatibility CI.

Flowchart

%%{init: {'theme': 'neutral'}}%%
flowchart LR
    SDK[Java and Ruby SDK clients] --> Runtime[floci-gcp runtime]
    Runtime --> Compute[Compute Engine control plane]
    Runtime --> GCS[GCS REST, XML, and gRPC]
    Runtime --> Monitoring[Project-scoped Monitoring]
    Runtime --> GKE[GKE ClusterManager]
    Compute --> PersistentState[Configured storage backends]
    GCS --> PersistentState
    Monitoring --> ProjectState[Project-isolated state]
    GKE --> ClusterStore[Cluster store]
    GKE --> NodePoolStore[Node-pool store]

Loading

_{Reviews (3): Last reviewed commit: "chore: merge upstream GCS deletion and G..." | Re-trigger Greptile}

[greptile-apps]

Ruby Cache Warming Is Missing

Adding sdk-test-ruby only to the compatibility matrix breaks the documented requirement that the cache-warming matrix mirror it exactly. Pull-request jobs use a read-only cache, so the Ruby image will always build cold instead of receiving a cache populated from main. Add the Ruby target to warm-compat-caches.yml.

Knowledge Base Used:

• Distribution and client compatibility
• SDK and infrastructure compatibility testing

Note: If this suggestion doesn't match your team's coding style, reply to this and let me know. I'll remember it for next time!

[vedit]

Fixed in 9ad82ec. sdk-test-ruby is now in warm-compat-caches.yml, and changes to its Gemfile or Gemfile.lock trigger warming. Runner architecture and cache scope still match compatibility.yml; PR jobs remain cache readers.

Validated exact matrix equality and both dependency triggers. The pinned Ruby image and SDK/restart suites are also exercised in the linked validation run. Base-branch cache publication occurs through the existing warming workflow after merge; this does not claim the upstream main cache is already warm.

Validation at 9ad82ec: all 986 hosted JVM tests and 30 native Java/Ruby SDK and restart checks passed. Run and JUnit artifacts.

[vedit]

What does "waiting-contributor" mean? Can I help with something?

[hectorvent]

@vedit it was automatically by the automation I do have on my computer, I will need to check the conditions.