Existing implementation of discovery client provides APIs to publish and
withdraw services.
There's a requirement to publish service only if a list of conditions are
satisfied. For example, control node may like to publish xmpp service only
if the following conditions are met:
a) Connection to IFMap server is established
b) End of Rib Marker has been received/inferred on IFMap connection
c) Configuration for it's own bgp-router object has been received
Using the existing APIs is somewhat cumbersome since these daemon needs to
check all these conditions before deciding whether to publish or withdraw.
Proposal is to implement the following in the discovery client library:
1. Provide ability to register a "MayPublish" callback (returns a bool) when creating a discovery client. The library code should invoke this callback in order to decide whether to publish or withdraw the service.
The daemon code will check all conditions in the callback and return true
or false. At a minimum, this callback should be invoked periodically e.g.
sending a keep alive to discovery server. The MayPublish callback should
be invoked in the context of a well-known Task e.g bgp::Config or better
still, the task name/id should be a parameter for DiscoveryServiceClient constructor. The callback should also have a pass by reference string
parameter that the daemon fills with the reason for not publishing. This
should be used by the client library for logging purposes. It may also
be useful to pass the reason string to the discovery server so that it
can display that via introspect or UI.
2. Provide a new API ("ReEvaluatePublish") that the daemon can use to make
library invoke the MayPublish API asynchronously. The intent is for daemon
to call re-evaluate API when one of the conditions for publish or withdraw
changes. That should trigger discovery client to invoke MayPublish almost
immediately and decide whether it needs to publish/withdraw the service.
It should be possible for daemon to call re-evaluate API from an arbitrary
Task or the main thread. The client library should implement some kind of
back-off so that mutliple back to back calls to re-evaluate do not result
in multiple updates to the discovery server. One possibility could be to
react to a maximum of 1 (or some small number) of ReEvaluatePublish calls
in a keepalive interval.
Note that similar logic can be implemented by the daemon too, but it would
be much nicer to have this functionality in the client library.
Review in progress for https:/
Submitter: Nipa Kumar (<email address hidden>)