overview

Pre-Alpha. This page describes behavior that may change.

Configuration in Ze is one tree, validated by one set of YANG schemas, edited from any of the five operator surfaces (CLI, web UI, Looking Glass, MCP, REST API), committed atomically, and rolled back as a unit. There is no separate "running" file and "candidate" file living in the daemon's head. There is the committed config, your private draft on top of it, and the operations you use to move between them.

The mental model

Every field in Ze has a YANG type and a YANG path. The CLI prompts, the web UI forms, the validation messages, and the wire format the MCP server speaks all come from the same schemas, which means a config you can write at the CLI is exactly the config the web UI will let you write, and the validators that run before commit are the same in both places.

When you connect, Ze gives you a per-user draft session sitting on top of the committed tree. Edits go into your draft. Other users see their own drafts and the last committed version, not yours. Your draft survives disconnection, so you can leave a half-finished change and come back to it.

The four operations

The operator workflow is the same one a JunOS or Cisco IOS user already knows.

ze# edit bgp peer upstream            # Drop into the peer subtree
ze[bgp peer upstream]# set timer receive-hold-time 180
ze[bgp peer upstream]# top
ze# diff                              # See your pending changes
ze# commit                            # Apply atomically

diff shows your draft against the committed tree. commit runs the schema validators, then applies your draft as one atomic change. If validation fails, nothing is applied: your draft is still there for you to fix.

rollback 1 undoes the last commit. The archive holds every committed config, so rollback 5 is also legal, and show archive lists what is available. If you suspect a change might lock you out (you are editing the SSH config, you are tightening firewall rules, you are touching peer authentication on a peer you are connected through), use commit confirmed. It applies the change, starts a rollback timer, and reverts unless you type confirm before the timer expires.

discard throws away your draft if you change your mind before committing.

Hot reload, not daemon restart

Commits never restart the daemon. The new tree is hot-applied: the parts of Ze that care about a given subtree are notified, and they reconfigure in place. Adding or removing a peer is online. Changing capabilities on a peer that is up may force the session to reset, and Ze tells you it is going to do that before it does.

If you would rather edit a config file out of band (in your editor of choice, in a Git working tree, in an Ansible template) you can. ze config validate myconfig.conf runs the same validators against the file. ze config import myconfig.conf loads it into your draft session, where you can diff against the committed tree before committing.

What the schemas enforce

The validators run at every commit, every CLI submit, every web UI save, and every ze config validate. They are not advisory.

A few of the rules worth knowing about up front:

• Required fields must be present after inheritance is resolved (ze:required). For a BGP peer that means the remote IP, the remote AS, and the local AS, any of which can be inherited from a group or from the global BGP block.
• Every negotiated address family must have a prefix { maximum }. Ze refuses to start without it. This is RFC 4486 and it exists because nobody actually wants what happens when you forget.
• Unknown keys are rejected with a suggestion for the closest valid one. Typos do not silently disappear.

Inheritance

The BGP subtree uses three levels: bgp { } globals, bgp { group { } } defaults for a group, and bgp { peer { } } overrides for a single peer. Container nodes (capability, family, timer) are deep-merged. Leaf values override. You set what is common at the BGP or group level and let peers override only what is genuinely peer-specific.

See also

• BGP peers for the per-peer settings.
• CLI tour for the operator workflow in five minutes.
• Web UI tour for the same operations through a browser.

Adapted from main/docs/features/configuration.md and main/docs/guide/configuration.md.