Hi Nicolas,
On Fri, 22 May 2015, Nicolas Dichtel wrote:
Here is the last update of this series. There is no major change with
the v2 as no technical issue were spotted. Patches are also available at
https://github.com/6WIND/quagga/commits/vrf
It would be nice to have some guide lines from maintainers about how to get
this series included.
Ok, so this is just kind of "probing" discussion on my part, and I'm not
intending to shut-down any options. I'm not sure myself what the right way
is, so questions on this are merely to try tease out the issues and
generate discussion!
IIRC, the discussion before was on what was ultimately the right 'model'
for Quagga with respect to namespacing and daemons.
- Quagga daemons (libzebra ones anyway) are single-threaded, with
non-pre-emptive internal tasks. So it makes sense, in this multi-core
world, to scale out using separate daemon instances as much as possible.
- On the other hand, our configuration/UI system is a bit limited. In
particular there is a direct coupling between the VTY layer and the
configuration state which leads to inflexibilities that make it hard to
transparently rendezvous the end-user UI (vtysh or telnet) with
different config state in different daemons.
E.g., each daemon would have a separate telnet port. vtysh would have a
hard time knowing how to map different instances into its UI (done at
compile time).
The latter makes multi-daemon less attractive to implement, of course.
The issue for me is whether we should fix the config/control UI issues, if
that's the root cause for wanting to extend the daemons to support
VRF/namespaces internally, rather than go with a multi-daemon approach?
I think you or Lu Feng pointed out that ospfd already had extensive
internal support for different instances, and hence the churn wouldn't be
as much as feared. It would be good to see the changes needed for ospfd to
guage that perhaps?
Also, imagine we have perfect UI support. You can launch multiple daemons
and there's some rendezvous mechanism in place to allow UI clients to
transparently discover and integrate different instances into a cohesive
UI.
Imagine we have that support: What then is the case for single-daemon
VRF/namespace support?
Basically, what is the ideal we should be going toward? How does this fit
into it? :)
If single-daemon/multi-{instance,VRF,namespace} is a useful stepping stone
towards the ideal, then try explain a bit on that too?
regards,
--
Paul Jakma p...@jakma.org @pjakma Key ID: 64A2FF6A
Fortune:
He who makes a beast of himself gets rid of the pain of being a man.
-- Dr. Johnson
_______________________________________________
Quagga-dev mailing list
Quagga-dev@lists.quagga.net
https://lists.quagga.net/mailman/listinfo/quagga-dev
