Ok,
If most people do prefer one-daemon for all VRFs, and want that in now
without thinking about how it might work with multi-daemon in the future,
then sure, I'll stop being awkward.
However, in that case, if in the future anyone wants to add
daemon-per-{VRF,protocol instances}, I /may/ object with:
"NACK, until you make this work in a coherent way with
single-daemon-all-instances, including the end-user visibile UI"
And I may be obstinate on that, including refusing any quick hacks, and
I'll expect _no_ complaints. :)
Either 6WIND do the work now of figuring out how to make this play nice
with multi-daemon and minimising potential conflicts, or the future person
(trying to tackle the *inevitable* scaling issues by)? extending to
multiple daemons _will_ do - or it may not be able to go in.
Note that we've had no view yet of any actual users of this patch, to
judge the potential churn - other than basic adjustment to daemons to send
a default VRF in Zserv, and similar non-functional API changes.
I would like to see code for the actual users, at a minimum, before
agreeing to the existing patch train. Otherwise those are code changes
with no actual benefit.
regards,
Paul
On Fri, 29 May 2015, Donald Sharp wrote:
I think that a single daemon approach is the way to go. Code churn, memory
pressure, more complicated startup/stop scenarios, and lots of work that
can be done to improve daemon performance don't lead me to believe that I
think it is a good idea at this time.
donald
On Fri, May 29, 2015 at 3:55 AM, Paul Jakma <[email protected]> wrote:
One of the key questions for me is whether the two approaches can live
together.
I have scripts semi-hacked together to run Quagga daemons in different
VRFs^Wnamespaces - I use a number as the namespace name, so it's like a VRF
id. The script configures namespaces and launches daemons with a ZServ
path-name with the VRF ID in the path. You can then 'telnet $DAEMON
$(($DAEMON_BASE+$VRF*10))' or somesuch to access the ui. I havn't gotten
setting of inter-networking between the VRFs nicely scripted yet.
At some point that really should become a proper VRF management daemon.
That seems a sensible way forward for the daemon-set-per-VRF approach.
(The mass of telnet UIs is not brilliant, vtysh doesn't do multi-instance.
We should consider fixing that - I'm sure this has come up a few times over
many years now, no one has been willing to grasp the nettle).
Will this co-exist together with the single-set approach?
If people run set-per-VRF, then they're going to have VRF related commands
within the inside-VRF instances as things stand. Bit confusing UI wise. The
zebra in the netns would say it supported VRFs in the netns (I think Linux
namespaces are nestable that way, I thnk - but not sure we should do that
for Quagga's VRF abstraction).
I'm just very unclear on the big picture. How do we fit everything
together in a way that doesn't end up a mess for the user?
regards,
--
Paul Jakma [email protected] @pjakma Key ID: 64A2FF6A
Fortune:
Serfs up!
-- Spartacus
--
Paul Jakma [email protected] @pjakma Key ID: 64A2FF6A
Fortune:
You will not censor me through bug terrorism.
-- James Troup
_______________________________________________
Quagga-dev mailing list
[email protected]
https://lists.quagga.net/mailman/listinfo/quagga-dev
