Instead of returning only error codes (e.g. NB_ERR_VALIDATION)
to the northbound clients, do better than that and also return
a human-readable error message. This should make FRR more
automation-friendly since operators won't need to dig into system
logs to find out what went wrong in the case of an error.
Signed-off-by: Renato Westphal <renato@opensourcerouting.org>
The new northbound context structure contains information about
the client performing a configuration transaction. This information
will be made available to all configuration callbacks through the
args->context parameter.
The usefulness of this structure comes from the fact that it can be
used as a communication channel (both input and output) between the
northbound callbacks and the northbound clients. This can be done
through its "client_data" field which contains client-specific data.
This should cover some very specific scenarios where a northbound
callback should perform an action only if the configuration change
is coming from a given client. An example would be sending a PCEP
response to a PCE when an SR-TE policy is created or modified
through the PCEP northbound client (for that to happen, the
northbound callbacks need to have access to the PCEP request ID,
which needs to be available).
Signed-off-by: Renato Westphal <renato@opensourcerouting.org>
Synchronous GRPC services are called from arbitrary threads. This makes
access to anything outside the GRPC module unsafe. We need to convert
the plugin to use the async model that allows us to control our own
threads.
Signed-off-by: Quentin Young <qlyoung@cumulusnetworks.com>
start grpc thread with frr_pthread library
callbacks to integrate with rcu infrastructure.
If a thread is created using native pthread callbacks
and if zlog is used then it leads to crash.
Signed-off-by: Chirag Shah <chirag@cumulusnetworks.com>
The intention here is to keep the code more organized. These wrappers
should be used by the northbound clients only, and never directly
by any YANG backend code.
Signed-off-by: Renato Westphal <renato@opensourcerouting.org>
When using the GRPC northbound plugin, initialization occurs at the
frr_late_init hook. This is called before fork() when daemonizing (using
-d). Because the GRPC library internally creates threads, this means our
threads go away in the child process, so GRPC doesn't work when used
with -d. Rectify this situation by deferring plugin init to after fork
by scheduling a task on the threadmaster, since those are executed by
the child.
Signed-off-by: Quentin Young <qlyoung@cumulusnetworks.com>
Some issues with our internal vector type being typedef'd as `vector`,
which conflicts with the C++ standard vector class...
Signed-off-by: Quentin Young <qlyoung@cumulusnetworks.com>
Adding a lock to protect the global running configuration doesn't
help much since the FRR daemons are not prepared to process
configuration changes in a pthread that is not the main one (a
whole lot of new protections would be necessary to prevent race
conditions).
This means the lock added by commit 83981138 only adds more
complexity for no benefit. Remove it now to simplify the code.
All northbound clients, including the gRPC one, should either run
in the main pthread or use synchronization primitives to process
configuration transactions in the main pthread.
This reverts commit 83981138fe.
