Date: Fri, 29 Mar 2024 08:08:52 +0000 (UTC) Message-ID: <1332485638.4049.1711699732651@a58c738ca285> Subject: Exported From Confluence MIME-Version: 1.0 Content-Type: multipart/related; boundary="----=_Part_4048_1069594045.1711699732651" ------=_Part_4048_1069594045.1711699732651 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Content-Location: file:///C:/exported.html
The Open Distributed Infrastructure Management (ODIM) framework aggregat= es events from the managed servers, storage and network on behalf of subscr= ibers. The subscribers only receive events they have subscribed to with ODI= MRA. The BMCs themselves only have to forward events to ODIM rather than mu= ltiple subscribers. ODIMRA will try to forward the events up to a configura= ble number of times with a wait period in between. If ODIMRA is unable to d= eliver the event within the number of times configured the event is dropped= . This could happen if ODIMRA and subscribers are spread across remote site= s and there is a sustained network outage.
The current code reads from a custom message queue implemented in go lan= guage. This message queue itself is populated by messages retrieved from th= e event message bus which is Kafka at the moment. The proposal is to use re= dis database to store the events that could not be received by the subscrib= er. We will also need to store the forwarding info including destination in= fo. The event service will then periodically check the DB for pending event= s and attempt to send the same. The interval shall be added as configuratio= n to ODIMRA. Alternatively a successful transmission can also trigger the f= orwarding of events pending in DB.