Skip to content

Move sandbox deployment configuration and nodes into deployment and deploymentpg - #328

Merged
SaladDay merged 1 commit into
mainfrom
refactor/deployment-domain
Sep 30, 2026
Merged

SaladDay merged 1 commit into
mainfrom
refactor/deployment-domain

Conversation

@SaladDay

@SaladDay SaladDay commented Sep 30, 2026 •

Copy link
Copy Markdown
Collaborator

Part of #1 (dissolve store). This is PR 2 of the layering plan: sandbox deployment configuration and nodes move into the deployment domain and its PostgreSQL adapter deploymentpg.

What changes

  • deployment owns the sandbox deployment vocabulary, rules and use cases:

    • provider configuration and the sealed credential;
    • the specification and retained generations;
    • setup, update and switch;
    • node enrollment, authentication, generation configuration, capacity, presence, status and host history.

    It is the only package that interprets Sandbox Provider declarations, through the providers.Registry it is given. Registry lookups now return typed errors. Setup carries the provider's mode and declared operations, so cmd/server no longer reads declarations.

  • deploymentpg persists deployment in Load → Decide → Apply transactions.

    • Provider calls run outside those transactions, and the final transaction rechecks the expected generation.
    • Execution-only changes run through a separate lease-bound type, deploymentpg.NewExecution(lease, cipher), which reaches the Worker as execution.Owner.Deployment.
    • Execution reads through the required Dispatcher.Deployment.
  • Encryption: the adapter seals and opens the credential with the unchanged binding, so existing ciphertexts still open.

    • A missing key is 503 credential_storage_unavailable.
    • A decrypt, seal or decode failure is 500.
    • Node paths no longer decrypt the credential.
  • api depends on the Deployment, DeploymentChanges and DeploymentReset interfaces. writeDeploymentError maps the domain errors. The strict fakes are split by area.

  • Still in store for PR 3: allocations, placement and reset. Reset completion returns the committed generation and publishes the empty runtime configuration from it.

  • Deleted: the store deployment and node files, the deployment copies of AdminValidationError, and the ExecutionOperations read forwarders.

  • IMPLEMENTATION.md: records the layering conventions and adds deployment as an owner.

Behavior

  • An undecodable stored configuration stays 409 sandbox_deployment_conflict, as before.
  • A decrypt failure on the credential is now 500 instead of 503.

Checks

  • go build ./... and go vet ./services/core/... (whole module)
  • deployment in full: 21 passed
  • deploymentpg in full: 47 passed, 0 skipped
  • cmd/server tests from the managed*_test.go files: 21 passed
  • store tests that reach the changed helpers, selected with -run: 117 passed
  • make openapi (regenerated) and make check-names

Blind review found no blocker or major issues. Its four minor findings are fixed: node paths decrypted the credential, cmd/server read provider declarations itself, two Service pass-through methods remained, and one decode failure had become 500.


View with [code]smith Autofix with [code]smith
Need help on this PR? Tag @codesmith-bot with what you need. Autofix is disabled.

@SaladDay
SaladDay merged commit 3e7135d into main Sep 30, 2026
1 check passed
@SaladDay
SaladDay deleted the refactor/deployment-domain branch September 30, 2026 19:10
…eploymentpg

The deployment package owns the sandbox deployment vocabulary, its rules
and use cases: provider configuration and the sealed credential, the
specification and retained generations, setup, update and switch, node
enrollment, authentication, generation configuration, capacity,
presence, status and host history. It is the only package that
interprets Sandbox Provider declarations, through the providers.Registry
it is given, whose lookups now return typed errors. deploymentpg
persists it in Load, Decide and Apply transactions, provider calls run
outside them, and the final transaction rechecks the expected
generation. Deployment changes run through ExecutionOperations on the
execution lease, which the Worker receives as execution.Owner.Deployment.

api depends on Deployment, DeploymentChanges and DeploymentReset
interfaces typed with the deployment vocabulary; store keeps
implementing NodeAllocations and DeploymentReset, together with
allocations, placement and reset. Reset completion returns the committed
generation and publishes the empty runtime configuration from it before
the response reads the current deployment.
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.

1 participant