Hi Paul
Single daemon vs multi daemons: we already had this discussion in the
thread "Multiple VRF support in quagga"; there are different point of
view, but the main thing was that
- each made sense
- none was exclusive
Multi daemon have issue from configuration point of view; and I agree
this may/should /will? be fixed; anyway we do have a solution based on a
single daemon, managing VRF through netns. And I truly believe this
solution really makes sense. The use case was given, and there is
running code available NOW.
There has already been some remarks on the patchset about the code
itself; my believe is that they are addressed now (of course if there is
still some code that needs to be reworked, it will be done)
So let's move forward !
Just in case,
https://github.com/6WIND/quagga/commits/vrf
can be used by Cumulus approach in order to demonstrate that both can be
used.
Regards
Alain
PS: The same thing applies for some OSPF patches once proposed by
Cumulus: they are in favor on one daemon per OSPF instance (and combined
with the VRF patch should allow one OSPF per VRF), I'm more in favor of
one daemon with one instance per internal context: the use case as we
already discussed are simply not the same; I won't fight against their
approach because both make sense and they can co-exists; so if their
code is ready first, let use it, and we'll rebase. Once again the
important thing is to move forward.
On 05/25/2015 07:12 PM, Paul Jakma wrote:
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,
--
Alain RITOUX
_______________________________________________
Quagga-dev mailing list
Quagga-dev@lists.quagga.net
https://lists.quagga.net/mailman/listinfo/quagga-dev
