Difference between revisions of "Old backend"

From VyOS Wiki
Jump to: navigation, search
Line 66: Line 66:
[[Category: Development]]
[[Category: Development]]
[[Category: Don't migrate]]

Latest revision as of 16:58, 4 July 2019

Old backend, also known as Cstore, has a number of design problems.

User perspective

Things that are impossible in the current system that one may want to see:

  • Rollback without reboot.
  • Commit dry-run (check the config correctness but do not apply).
  • "show | display set" (not entirely impossible, but not in a natural way)
  • Remote API (again, not impossible, but needs a lot of additional layers)

Read and write operations disparity

Config read (cli-shell-api and Vyatta::Config) and write APIs are separated. Write API relies on /opt/vyatta/sbin/my_cli_bin calls and specific environment setup, which makes it hard to impossible to make the config modification API programmatic and especially remote access friendly without additional abstraction layers.

Internal representation

Problem: Config is represented as a directory tree with values stored in files.


  1. Increased number of system calls (and thus context switches) affects performance.
  2. Makes it difficult to implement flexible permissions system (would require assigning multiple ACLs to nodes on creation)

Possible solution: Use in-memory multi-way tree.

Running and proposed config organization

Problem: Uniform access to the running and proposed config from session is achieved with union mounting corresponding directories with UnionFS.


  1. Blocks upgrade to newer kernels because kernel implementation of UnionFS is not longer maintained.
  2. Further complicates data organization.

Possible solution: Temporary: use userspace UnionFS. Permanent: use in-memory datastructures.

Commit dependency model (or lack thereof)

Problem: Dependencies between config parts are expressed as hardcoded priorities.


  1. Makes commit strictly sequential and impossible to parallelize.
  2. Makes rollback implementation difficult.

Possible solution: Use dependency-based model.

Commit logic

Problem: Each part of the config is performs commit-time checks and updates the configs independently.


  1. If an errors occurs at any stage, the system does not rollback, it stays in inconsistent state. In case commited changes were mutually dependent, it may render the system unusable until manual intervention or reboot initiated by commit-confirm.

Possible solution: Split commit in three stages: validate, update, and apply.

New backend requirements

  1. Programmer-friendly read and write operations.
  2. Network transparent API.
  3. Separate commit stages (verify, generate configs, apply).
  4. Dependency-based commit model.