On Thu, 3 Mar 2016, Paul Jakma wrote:
On Thu, 3 Mar 2016, David Lamparter wrote:
As for this discussion, the approach that seemed most fruitful in my view
was to push transaction functionality outside of Quagga. There's no
advantage to having it inside, since when it's properly modularised it
looks like this:
CLI ----> transaction code ----> settings API
(or other config)
The key thing is the API, want to publish it?
I've had some preliminary discussions and investigations on this.
It seems there are 2 paths:
- Define a structured storage layer and an API both for access (r/w) of
objects in some structured way, and notifications
- Annotate existing objects with the data needed to introspect them
(and maybe find them).
The former might be how you'd do things if starting from scratch. The
downside of that way is that there's a lot of existing code to change.
It'd be a very big and disruptive change, and no doubt the churn would
introduce bugs on the routing side.
The latter would be easier to fit in to the existing code. Code reading
from annotated objects might need little to no modification. The downside
of course is it's less encapsulated, so notifications would depend on the
writer initiating. The latter could also accommodate a more encapsulated
state/storage/settings API.
I've played with some of the latter and the 'annotations' or introspection
objects can be added in a relatively type-safe way, using similar "encode
info into the C symbol space" tricks as in the memory patches you had.
HPEN are about to start working on this. If there's existing work to build
on, collaborate with, and iterate on, that'd be great - if it's available
and the other parties are interested. ?? Otherwise, we will start
exploring the latter approach, implementation wise.
Our aim is to able to support an OPS like architecture, where state
(routing state as well as config state) can be easily externalised and
modified.. It seems we're agreed that would have a lot of benefits. HPEN
are, of course, particularly interested in being able to slot-in an
RFC7047 like protocol to/from an external DB (i.e. the client protocol
side to an OpenVSwitch OVSDB).
regards,
--
Paul Jakma, HPE Networking, Advanced Technology Group
Fortune:
He that breaks a thing to find out what it is has left the path of wisdom.
-- J.R.R. Tolkien
_______________________________________________
Quagga-dev mailing list
[email protected]
https://lists.quagga.net/mailman/listinfo/quagga-dev