My plan is to present this at (or directly after, if people want to
split the topic) the next Quagga monthly meeting. I have some half-done
slides that I'd like to finish, and it might also be possible to push
out some code.
Paul, from your text below ("HPEN are about to start working on this."),
do you have a time constraint that wouldn't be met with that timeline?
FWIW, it's built around pretty much the thoughts you outline below, and
then some. The code is working in a 3rd party setup, but I have
medium-scale adjustments queued up (based on more "lessons learned").
Cheers,
-David
P.S.: Yes, I gave no response at all on what we actually did. I
strongly prefer giving a thought-out introduction to the interface over
starting to pluck away at the design from a random angle with half of
the picture missing...
On Fri, Mar 04, 2016 at 02:30:00PM +0000, Paul Jakma wrote:
> 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
> Quagga-dev@lists.quagga.net
> https://lists.quagga.net/mailman/listinfo/quagga-dev
_______________________________________________
Quagga-dev mailing list
Quagga-dev@lists.quagga.net
https://lists.quagga.net/mailman/listinfo/quagga-dev
