2026.10.27 — 2026-10-07
Breaking
Register a whole cluster from one URL and edit its connection under Settings (011c2261)
Registering a cluster now needs one management URL. Studio derives every other node's management URL from a management URL pattern (
scheme://{host}:port/path, by default the first seed with its host replaced by{host}), probes it with the management account, and attaches it only when the broker answering there reports the node's NodeID. A node whose derived URL does not answer, rejects the account or belongs to another broker is listed as found but not manageable, with the reason. Each node records where its management URL came from (seed, derived, manual); rediscovery re-derives derived URLs only, and a manual URL is never touched. A seed host name that resolves to several addresses is expanded into one seed per address; a TLS seed keeps its host name and only learns NodeIDs from the addresses.The registration form asks for one broker management URL ("Add another seed" for more), a management account, an optional Core account and the environment, and keeps the management URL pattern under Advanced. Check connection lists every node with its role, NodeID, version, management URL and where it came from, and what the management account and the Core account each did on it, so a rejected Core account no longer hides an accepted management account or the reverse. When the brokers' configuration can be read, a switch adopts it as the cluster's revision 1, attributed to the operator and saved in the registration's transaction: on when the nodes agree, off with the differences listed when they do not.
Settings has a Connection section in place of the broker credentials form. It edits name, description, seeds, the pattern, the TLS bundle and both accounts; Check connection runs the per-node check with the new values and saves nothing, and Save connection is offered once the check of exactly those values passed. Changing an account asks for the cluster's name. A password left empty keeps the stored one, and turning the separate Core account off makes Core use the management account. A saved change is audited with secrets redacted and rediscovers at once.
A rejected credential is reported as such: cluster health says which account the brokers rejected and on which nodes, instead of calling them unreachable, and links to the Connection settings. A node's page and the add-a-management-URL dialog say where its URL came from, or why it has none.
A stored password is never sent to a host the cluster does not already use: changing the seeds, the management URL pattern, the TLS bundle or an account's username asks for that account's password again, and the pattern must be
http(s)://{host}[:port][/path]. An account written into a URL is refused; put it in the account fields. A node whose derived URL failed is asked again after ten minutes when it did not answer, and only after the pattern or the account changes when it refused.
Added
Register a whole cluster from one URL and edit its connection under Settings (011c2261)
Registering a cluster now needs one management URL. Studio derives every other node's management URL from a management URL pattern (
scheme://{host}:port/path, by default the first seed with its host replaced by{host}), probes it with the management account, and attaches it only when the broker answering there reports the node's NodeID. A node whose derived URL does not answer, rejects the account or belongs to another broker is listed as found but not manageable, with the reason. Each node records where its management URL came from (seed, derived, manual); rediscovery re-derives derived URLs only, and a manual URL is never touched. A seed host name that resolves to several addresses is expanded into one seed per address; a TLS seed keeps its host name and only learns NodeIDs from the addresses.The registration form asks for one broker management URL ("Add another seed" for more), a management account, an optional Core account and the environment, and keeps the management URL pattern under Advanced. Check connection lists every node with its role, NodeID, version, management URL and where it came from, and what the management account and the Core account each did on it, so a rejected Core account no longer hides an accepted management account or the reverse. When the brokers' configuration can be read, a switch adopts it as the cluster's revision 1, attributed to the operator and saved in the registration's transaction: on when the nodes agree, off with the differences listed when they do not.
Settings has a Connection section in place of the broker credentials form. It edits name, description, seeds, the pattern, the TLS bundle and both accounts; Check connection runs the per-node check with the new values and saves nothing, and Save connection is offered once the check of exactly those values passed. Changing an account asks for the cluster's name. A password left empty keeps the stored one, and turning the separate Core account off makes Core use the management account. A saved change is audited with secrets redacted and rediscovers at once.
A rejected credential is reported as such: cluster health says which account the brokers rejected and on which nodes, instead of calling them unreachable, and links to the Connection settings. A node's page and the add-a-management-URL dialog say where its URL came from, or why it has none.
A stored password is never sent to a host the cluster does not already use: changing the seeds, the management URL pattern, the TLS bundle or an account's username asks for that account's password again, and the pattern must be
http(s)://{host}[:port][/path]. An account written into a URL is refused; put it in the account fields. A node whose derived URL failed is asked again after ten minutes when it did not answer, and only after the pattern or the account changes when it refused.