On Tue, 8 Mar 2016, David Lamparter 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.
Not sure I can make that meeting, but hey, I can read the slides after I
assume?
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?
I think HPEN would like this to be done yesterday. :)
I've toyed with some low-level machinery. Maybe from mid-April at latest,
and by late April/early May sometime I want to try get some kind of actual
object annotation infrastructure done. My plan after that then is to try
actually annote some key data-structures in some daemon. Then try find
some way to add a layer that can map some kind of key-space onto the
annotated objects. Then try make that accessible via some kind of IPC
(JSON or somesuch?). If that works, then we can start annotating more and
more objects, and maybe port things like vtysh over to it.
Stuff like diffs, consistency and what not should largely be handled in
those external clients, I agree.
To facilitate that I suspect it would be useful to separate the routing
code acting on changed state out a bit, so that there's a purely
functional portion that can say "Yeah, that change, with that given state,
checks out to me" and another handler to act on the state. I think that's
a much bigger job though, and not an initial goal - but just to be kept in
mind still.
Another issue is schema. OPS builds on the OpenVSwitch OVSDB libraries,
which use a schema file that gets compiled in to the clients. That's a bit
of a pain if/when stuff changes. So, making things self-describable or
discoverable, or at least have the schema auto-generated on the fly over
IPC as/when consumers need it, would be better. But that's again, a later
flourish potentially and not per se needed initially.
That was my thinking and planning to date anyway...
Some HPEN engineering resources are available, which could be useful esp.
for the "bigger" and easier to distribute jobs.
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").
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...
Ok.
I can't take that into account until I can see it though. ;) And
collaberating on code definitely requires being able to see it. ;) If
you've done everything we need, great. If not, we might need to iterate.
But... got to see it to be able to do that. I will have to plough on with
some implementation myself soonish, one way or another!
regards,
--
Paul Jakma, HPE Networking, Advanced Technology Group
Fortune:
Illinois isn't exactly the land that God forgot -- it's more like the
land He's trying to ignore.
_______________________________________________
Quagga-dev mailing list
[email protected]
https://lists.quagga.net/mailman/listinfo/quagga-dev
