Due to a ransomware attack, the wiki was reverted to a July 2022 version. . We apologize for the lack of a more recent valid backup.
...
The Application loads a json config file at start up. This config file will have Kafka config information.
CLUSTERING SUPPORT
When operating in a clustered deployment each application instance will only publish notifications for those devices and links for which it is the master.
1. In a cluster scenario only the primary and backup controller will be responsible for publishing events to Kafka Server.
2. One of the core assumptions is the order of event stream that is received from Network Devices is the same across all the ONOS controllers.
3. The Leader/Primary will publish event stream to a distributed store. There will be a flag indicating whether this event got published to Kafka Server.
After publishing the event to the Kafka Server, it will update the flag accordingly.
The Backup will have read only access of the events posted to distributed store.
4. In case of Leader failure, the Backup will get read/write access to the distributed store. It will try to post events that were not sent to the Kafka server.
5. As a mechanism to detect duplicated events being sent, we could have seq_id numbers for every event that gets posted. This way the external app can detect duplicates For links 'master ship' is determined by the destination device of the link.
DESIGN DECISIONS
- There will be one topic per event type. Each external app will be given a unique consumer groupId.
- Event subscription by external apps is a two step process - They must first register and then subscribe to a specific event call.
As a first step we will only export Device Events and Link Events to consumers and worry about Packet Ins and Packet Out later.
- Once the framework is in place it should be relatively easy to add support for other event types.
- In the scenario where the external app loses connectivity with the Kafka server, and does not come back up within the retention period (the time duration for which Kafka will retain messages) the onus is on the non native app to rebuild its current view of the network state via existing ONOS REST APIs.
...