fix schema validation

Signed-off-by: Alejandro M. Ramallo <alejandro.ramallo@leapsight.com>

Author: aramallo

config/bondy.conf.defaults

@@ -217,6 +217,7 @@ broker_bridge.mailgun.adapter = mailgun2
 broker_bridge.mailgun.enabled = off
 broker_bridge.sendgrid.adapter = sendgrid
 broker_bridge.sendgrid.enabled = off
+broker_bridge.smtp.enabled = off
 cluster.automatic_leave = off
 cluster.channels.control_plane.compression = on
 cluster.channels.control_plane.parallelism = 1
@@ -226,6 +227,7 @@ cluster.channels.default.compression = off
 cluster.channels.default.parallelism = 1
 cluster.channels.wamp_relay.compression = false
 cluster.channels.wamp_relay.parallelism = 2
+cluster.connection_high_watermark = infinity
 cluster.exchange_tick_period = 10s
 cluster.lazy_tick_period = 1s
 cluster.max_message_size = 64MB
@@ -236,15 +238,17 @@ cluster.peer_discovery.initial_delay = 10s
 cluster.peer_discovery.polling_interval = 10s
 cluster.peer_discovery.timeout = 5s
 cluster.peer_port = 18086
+cluster.rpc_max_concurrency = 10000
 cluster.tls.allow_insecure = off
 cluster.tls.client.verify = verify_none
 cluster.tls.client.versions = 1.3
 cluster.tls.enabled = off
+cluster.tls.handshake_timeout = 5s
 cluster.tls.server.verify = verify_none
 cluster.tls.server.versions = 1.3
 db.aae = on
 db.aae.fanout = 3
-db.aae.fence.max_lag = 1s
+db.aae.fence.max_lag = 60s
 db.aae.fence.on_isolation = refuse
 db.aae.interval = 500ms
 db.aae.live_sync = on
@@ -269,16 +273,22 @@ db.pack_seal_mode = async
 db.reclaim = on
 db.reclaim.batch_cells = 500
 db.reclaim.interval = 1m
+db.registry.retention.max_age_ms = 0
+db.registry.retention.max_events = 0
 db.registry.shard_count = 16
 db.wal.batched_fsync_bytes = 1MB
 db.wal.batched_fsync_interval = 50ms
 db.wal.fsync_mode = per_write
 db.wal.max_segment_bytes = 64MB
 load_regulation.aae_reactor.pool.size = 16
 load_regulation.enabled = on
+load_regulation.hello.enabled = on
 load_regulation.job_manager.pool.size = 16
 load_regulation.job_manager.queue.size = 160000
 load_regulation.job_manager.queue.ttl = 1m
+load_regulation.load_monitor.run_queue_high_watermark = 8
+load_regulation.load_monitor.run_queue_low_watermark = 4
+load_regulation.load_monitor.sample_interval = 100ms
 load_regulation.router.flow_pool.capacity = 100000
 load_regulation.router.pool.capacity = 2000000
 load_regulation.router.pool.size = 16
@@ -317,6 +327,8 @@ log.handlers.default.formatter.time_designator = T
 log.handlers.default.formatter.time_offset = 0
 log.handlers.default.level = info
 log.level = info
+mail.status.max_size = 50000
+mail.status.ttl = 1h
 oauth2.client_credentials_grant.duration = 15m
 oauth2.code_grant.duration = 10m
 oauth2.config_file = {{platform_etc_dir}}/oauth2_config.json
@@ -358,6 +370,8 @@ security.rate_limit.handshake.rate = 10
 security.rate_limit.message.capacity = 2000
 security.rate_limit.message.enabled = off
 security.rate_limit.message.rate = 1000
+security.reclamation.enabled = on
+security.reclamation.interval = 6h
 security.ticket.allow_not_found = on
 security.ticket.authmethods = all
 security.ticket.expiry_time = 30d
@@ -384,6 +398,7 @@ wamp.broker.subscriber_blackwhite_listing = true
 wamp.broker.subscription_meta_api = false
 wamp.broker.subscription_revocation = false
 wamp.call_timeout = 30s
+wamp.connection.message_queue_data = off_heap
 wamp.connection_lifetime = session
 wamp.dealer.call_canceling = true
 wamp.dealer.call_reroute = true

doc/guides/configuration/migrating_from_1.0.0-rc.65.md

@@ -13,26 +13,33 @@ configuration.
 
 ## Steps
 
-### 1. Accept that this is not an in-place upgrade
+### 1. Move your data before you wipe anything
 
 On-disk data written by 1.0.0-rc.65 (or any earlier release) is in PlumDB's
-RocksDB format, which this release cannot read. There is no tool that
-converts it: `bondy_export`, this release's data mover, reads and writes only
-the new storage engine, so it has nothing to read on a PlumDB data
-directory.
+RocksDB format, which this release cannot read. `bondy_export` reads and
+writes only the new storage engine, so pointing it at a PlumDB data
+directory gives it nothing to read.
 
-Concretely, this means:
+The migration path runs through a backup **file**, not the data directory.
+Take one on the old node with `bondy.backup.create` while it is still
+running; this release's `bondy.export.import` recognises that file's format
+and translates each record as it reads. Users, groups, grants, sources, API
+Gateway specs and OAuth refresh tokens come across. Realm records do not —
+recreate realms from configuration, and their per-realm data still imports,
+because it is banded by the realm URI.
+
+The full procedure — backing up on the old deployment, confirming it
+finished, copying the file, and importing it — is
+[Upgrading to 1.0.0](https://developer.bondy.io/guides/deployment/upgrading_to_1_0_0).
+Follow that guide for the data; this one covers only the configuration.
+
+Two things hold either way:
 
 - **Wipe the data directory** (`platform_data_dir`) before starting the new
-  release on a node. Starting it against an old data directory does not
-  corrupt anything — the new code simply doesn't recognise the layout — but
-  it also doesn't give you your data back.
-- **Recreate realms, users, groups, grants, sources, tickets, tokens and
-  API Gateway specs** on the new cluster. If you provisioned these
-  originally through a script, Terraform/Ansible run, or a stored set of
-  WAMP `bondy.realm.create` / `bondy.security.*` / `bondy.http_gateway.*`
-  calls, replay it. If you provisioned by hand, there is no shortcut —
-  budget time to redo it.
+  release on a node — but only once the backup above is confirmed finished,
+  since the data directory is the only thing the backup can be taken from.
+  Starting the new release against an old data directory does not corrupt
+  anything; the new code simply doesn't recognise the layout.
 - This is a **new cluster**, not a rolling upgrade. Don't mix a 1.0.0-rc.65
   node and a node running this release in the same Partisan cluster.
 
@@ -175,8 +182,8 @@ the defaults are safe to run with unchanged.
 ## Result
 
 You have a `bondy.conf` (and, if applicable, `advanced.config`) that this
-release accepts, and a plan for recreating your realm and security state on
-a freshly provisioned cluster. To confirm your file is complete before
+release accepts. Your data moves separately, through the backup and import
+described in step 1. To confirm your file is complete before
 deploying it, start a node with it: an unrecognised or mistyped key fails
 boot immediately, naming the key and suggesting the closest valid one. If
 you're building from source, `config/bondy.conf.defaults` (regenerate it
@@ -185,6 +192,9 @@ diff target.
 
 ## See also
 
+- [Upgrading to 1.0.0](https://developer.bondy.io/guides/deployment/upgrading_to_1_0_0)
+  — the data half of the migration: back up on the old deployment, copy the
+  file, import it on the new cluster.
 - [Reclamation configuration reference](reclamation_options.md) — the full
   set of reclamation/retirement options and their telemetry.
 - [Understanding deletion and reclamation](../database/deletion_and_reclamation.md)

schema/bondy.schema

@@ -1645,8 +1645,12 @@ end}.
 %% and every summary change is written through.
 %% @end
 %% -----------------------------------------------------------------------------
+%% `integer` is listed alongside the duration so that `0` is expressible: the
+%% duration parser rejects zero in every spelling (`0`, `0ms`, `0s`), so a
+%% bare duration datatype makes the documented "set 0 to disable" impossible
+%% to write and makes the generated defaults file fail to parse back.
 {mapping, "registry.rib.damping", "bondy_router.registry_rib_damping", [
-  {datatype, {duration, ms}},
+  {datatype, [integer, {duration, ms}]},
   {default, 0}
 ]}.