David - Thanks for agreeing to present at the monthly meeting. Can't wait to see what you have.
thanks! donald On Tue, Mar 8, 2016 at 7:51 AM, David Lamparter <[email protected] > wrote: > 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 > > [email protected] > > https://lists.quagga.net/mailman/listinfo/quagga-dev > > _______________________________________________ > Quagga-dev mailing list > [email protected] > https://lists.quagga.net/mailman/listinfo/quagga-dev >
_______________________________________________ Quagga-dev mailing list [email protected] https://lists.quagga.net/mailman/listinfo/quagga-dev
