Skip to content

feat: add server.remotesAPI and server.behavior.eventScheduler to DoltDB - #20

Merged
coffeegoddd merged 2 commits into
mainfrom
pr-19-remotesapi
Oct 27, 2026
Merged

coffeegoddd merged 2 commits into
mainfrom
pr-19-remotesapi

Conversation

@coffeegoddd

Copy link
Copy Markdown

Adds two optional DoltDB fields; nothing changes for specs that set neither.

  • spec.server.remotesAPI serves Dolt's user-facing remotes API (clone/fetch/push). The port defaults to
    50052, apart from the replication port 50051.
  • spec.server.behavior.eventScheduler (ON/OFF) sets behavior.event_scheduler.

On top of @realnedsanders' commit:

  • The port is exposed only on the standalone and primary Services, because Dolt accepts pushes to standbys through
    this API.
  • CEL rules reject ports that collide with other server ports.
  • The field docs explain auth: Basic credentials, CLONE_ADMIN to read and SUPER to push.

realnedsanders and others added 2 commits October 22, 2026 07:51
Dolt's sql-server can serve its databases over the user-facing remotes API
(the top-level `remotesapi` section of its configuration), so that clients
clone, fetch and push with `dolt clone http://…/db`. The operator rendered
only `cluster.remotesapi`, and only with replication enabled, and it patches
its ConfigMap back on every reconcile, so the user-facing API could not be
turned on for an operator-managed DoltDB.

`spec.server.remotesAPI` is optional. When set, the operator renders
`remotesapi.port` (default 50052, apart from the replication port 50051) and
`remotesapi.read_only`, and adds the port as `http-remotesapi` to the
container and to the primary, reader and internal Services. The one port
carries the gRPC calls and the plain HTTP table-file transfers.

`spec.server.behavior.eventScheduler` is optional, ON or OFF, and renders
`behavior.event_scheduler`. When empty, Dolt's default (ON) applies, as
before.

Nothing changes for a DoltDB that sets neither field.
Follow-up to the user-facing remotes API support:

- Expose the remotes API port only on the standalone and primary
  Services. Dolt does not refuse pushes to a standby through this API,
  so the reader and headless Services no longer advertise it.
- Reject a remotesAPI.port that collides with the listener, cluster
  remotes API, MCP, metrics or profiler port with CEL rules, instead of
  letting the pod crash-loop on bind.
- Document how the API authenticates: Basic credentials of a SQL user,
  CLONE_ADMIN for reads and SUPER for pushes, sent in plaintext.
- Make the container and Service port tests table-driven, unit-test the
  CEL rules against the generated CRD schema, and add integration tests
  for clone over the remotes API, refusal of unauthenticated clones, the
  event scheduler and admission of colliding ports.
@coffeegoddd
coffeegoddd requested a review from reltuk October 27, 2026 15:00

// The user-facing remotes API port must not collide with any other port the server listens on.
// Defaults are spelled out because an omitted parent object is not defaulted.
// +kubebuilder:validation:XValidation:rule="!has(self.remotesAPI) || self.remotesAPI.port != (has(self.listener) && has(self.listener.port) ? self.listener.port : 3306)",message="remotesAPI.port must differ from listener.port"

Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

These rules can get really complex overtime. We can eventually implement admission webhooks to validate these fields in a more maintainable manner.

#1

Copy link
Copy Markdown
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

great idea!

@coffeegoddd
coffeegoddd merged commit 538ea41 into main Oct 27, 2026
12 of 13 checks passed
@coffeegoddd
coffeegoddd deleted the pr-19-remotesapi branch October 27, 2026 16:32
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.

4 participants