Difference between revisions of "Sweetcomb/VOM"
From fd.io
m (→VOM as a middleware) |
m |
||
| (2 intermediate revisions by the same user not shown) | |||
| Line 1: | Line 1: | ||
| − | + | = VOM as a middleware = | |
These efforts have started with this [https://github.com/YohanPipereau/vomcomb Proof of Concept]. This demonstrates that it is possible to have the unmangled C symbols that sysrepo requires to dynamically load the shared library though developping the library in C++. | These efforts have started with this [https://github.com/YohanPipereau/vomcomb Proof of Concept]. This demonstrates that it is possible to have the unmangled C symbols that sysrepo requires to dynamically load the shared library though developping the library in C++. | ||
| − | Read [ https://tools.ietf.org/html/rfc8342#section-5.1.4 this ] passage from RFC 8342. VOM has the same property as the intended datastore but it is not expressed in YANG. | + | Read [https://tools.ietf.org/html/rfc8342#section-5.1.4 this] passage from RFC 8342. VOM has the same property as the intended datastore but it is not expressed in YANG. |
== Advantages/Inconvenients == | == Advantages/Inconvenients == | ||
| Line 20: | Line 20: | ||
:# Most VOM operations are not thread-safe | :# Most VOM operations are not thread-safe | ||
:# Supporting new features in VOM is less straightforward than in scvpp because of the heavy usage of design patterns and inheritance. | :# Supporting new features in VOM is less straightforward than in scvpp because of the heavy usage of design patterns and inheritance. | ||
| + | |||
| + | == A workflow for interface management for ietf-interfaces non NMDA with VOM == | ||
| + | |||
| + | <u>Problem statement</u>: How can an operator configure a physical interface without knowing the names they can have ? | ||
| + | |||
| + | <u>Answer</u>: | ||
| + | * For '''ietf-interfaces prior to NMDA''' [https://tools.ietf.org/html/rfc7223 RFC 7223], if you receive a <get> interfaces on interfaces-state subtree, you should answer with all existing interfaces on the system not just the one which have been created on interfaces subtree through <edit-config>. | ||
| + | * For '''ietf-interfaces after NMDA''' [https://tools.ietf.org/html/rfc8343 RFC 8343] and '''openconfig-interfaces''', as there is no separate subtree for ''config false'' and ''config true'' <get> interfaces must only answer the previously configured interfaces. | ||
| + | |||
| + | <u>Architecture for VOM</u> | ||
| + | |||
| + | TODO | ||
Latest revision as of 16:16, 25 June 2019
VOM as a middleware
These efforts have started with this Proof of Concept. This demonstrates that it is possible to have the unmangled C symbols that sysrepo requires to dynamically load the shared library though developping the library in C++.
Read this passage from RFC 8342. VOM has the same property as the intended datastore but it is not expressed in YANG.
Advantages/Inconvenients
Advantages of using VOM over scvpp:
- VOM offers a much more backward compatible API than VAPI.
- VOM is used in other projects like opflex-vpp (less bugs/more contributions)
- VOM::OM::replay can recommit configurations in case of failure of VPP
- VOM is part of VPP so changes of definition in "api" files will be updated in VOM too by VPP maintainers.
Inconvenients:
- VOM is very good to configure VPP but not to fetch information from it as it outputs dumps in a string format which needs to be parsed (problem of types, ...)
- VOM stores as: (key, list(objects)). The problem is that deleting a key will delete the entire list of objects so keys SHOULD BE uniquely choosen for each object (interface, route, etc...)
- Most VOM operations are not thread-safe
- Supporting new features in VOM is less straightforward than in scvpp because of the heavy usage of design patterns and inheritance.
A workflow for interface management for ietf-interfaces non NMDA with VOM
Problem statement: How can an operator configure a physical interface without knowing the names they can have ?
Answer:
- For ietf-interfaces prior to NMDA RFC 7223, if you receive a <get> interfaces on interfaces-state subtree, you should answer with all existing interfaces on the system not just the one which have been created on interfaces subtree through <edit-config>.
- For ietf-interfaces after NMDA RFC 8343 and openconfig-interfaces, as there is no separate subtree for config false and config true <get> interfaces must only answer the previously configured interfaces.
Architecture for VOM
TODO
