Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

docs: adr for enabling producing to event bus via settings #224

Merged
merged 1 commit into from
Jun 26, 2023
Merged
Show file tree
Hide file tree
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
90 changes: 90 additions & 0 deletions docs/decisions/0012-producing-to-event-bus-via-settings.rst
Original file line number Diff line number Diff line change
@@ -0,0 +1,90 @@
11. Enable producing to event bus via settings
##############################################

Status
******

**Accepted** 2023-06-05

Context
*******

The initial implementation of the event bus allowed only a single event type to be published to a `topic`_/`stream`_, with details like topic/stream name, consumer group name, and consumer name configured via code. We weren't sure what the API would finally look like, and whether the event bus config would live as part of the definition of the event, so we just went with explicit code that we could iterate upon.

The current implementation of openedx-events does not actually push any events to the underlying implementations like `edx-event-bus-kafka`_ and `edx-event-bus-redis`_. The event-producing application is expected to create a signal handler (since openedx-events subclasses Django signals) to catch the event and push it into the event bus. Some examples of the handlers: `handlers example`_.

.. _handlers example: https://github.com/openedx/edx-platform/blob/27b8d2f68d5dfaf84755e7d7f8dccc97ce3be509/cms/djangoapps/contentstore/signals/handlers.py#L162-L210
.. _edx-event-bus-kafka: https://github.com/openedx/event-bus-kafka
.. _edx-event-bus-redis: https://github.com/openedx/event-bus-redis
.. _topic: https://developer.confluent.io/learn-kafka/apache-kafka/topics/#kafka-topics
.. _stream: https://redis.io/docs/data-types/streams/

This ADR aims to propose a solution for configuring the details, like the topic name, consumer group name, etc. via Django settings as well as pushing events to the event bus without requiring the producing application to write additional handlers.


Decision
********

Create a generic signal handler to push events to the event bus. This handler should be attached to or connected to the signals that are enabled in Django settings. The configuration format will be as shown below:

.. code-block:: python

# .. setting_name: EVENT_BUS_PRODUCER_CONFIG
# .. setting_default: {}
# .. setting_description: Dictionary of event_types to lists of dictionaries for topic related configuration.
# Each topic configuration dictionary contains a flag called `enabled` denoting whether the event will be
# published to the topic, topic/stream name called `topic` where the event will be pushed to,
# `event_key_field` which is a period-delimited string path to event data field to use as event key.
# Note: The topic names should not include environment prefix as it will be dynamically added based on
# EVENT_BUS_TOPIC_PREFIX setting.
EVENT_BUS_PRODUCER_CONFIG = {
'org.openedx.content_authoring.xblock.published.v1': [
{'topic': 'content-authoring-xblock-lifecycle', 'event_key_field': 'xblock_info.usage_key', 'enabled': True},
{'topic': 'content-authoring-xblock-published', 'event_key_field': 'xblock_info.usage_key', 'enabled': False},
],
'org.openedx.content_authoring.xblock.deleted.v1': [
{'topic': 'content-authoring-xblock-lifecycle', 'event_key_field': 'xblock_info.usage_key', 'enabled': True},
],
}

This configuration will be read in openedx_events ``apps.OpenedxEventsConfig(AppConfig).ready`` method and a generic signal handler will be connected to the event_types (keys) listed in the configuration after validating its format.

.. code-block:: python

def ready(self):
load_all_signals()
config = read_config()
# validate the config dictionary and raise errors if any
validate_config()
for configured_signal in config:
connect_or_disconnect_handlers(configured_signal)

The generic handler will again read the configuration and get details for event or signal triggered and push it to the event bus.

.. code-block:: python

def general_signal_handler(sender, signal, **kwargs):
config = read_config(signal)
for topic in topics:
push_event_to_implementation(signal, config)

The `push_event_to_implementation` function is the same code currently used in the `hard-coded handlers`_, the only difference is that it will read the details from the configuration.

Finally, replace the `handlers`_ in edx-platform with a default configuration that will configure and enable the same events as the handlers.

.. _handlers: https://github.com/openedx/edx-platform/blob/27b8d2f68d5dfaf84755e7d7f8dccc97ce3be509/cms/djangoapps/contentstore/signals/handlers.py#L162-L210
.. _hard-coded handlers: https://github.com/openedx/edx-platform/blob/27b8d2f68d5dfaf84755e7d7f8dccc97ce3be509/cms/djangoapps/contentstore/signals/handlers.py#L167-L171

Consequences
************

* Applications producing to event_bus can push events without requiring any additional code.
* Users can push multiple related event_types to the same topic, which will allow them to run a single consumer and process the events in the correct order.
* The configuration is a dictionary, which makes it flexible but difficult to enforce schemas and maintain them.
* Producing applications similar to consuming applications will be required to add ``openedx_events`` as an application in their ``INSTALLED_APPS`` settings.

Rejected Alternatives
*********************

* Implementing configurable handlers in the host applications, rather than in the shared library, will require repeating the code in each host application.
* Following the current way of using fixed handlers will restricts users ability to combine events in a single topic based on their preference, as well as stopping users from producing additional defined events to the event bus without code changes.
1 change: 1 addition & 0 deletions docs/decisions/index.rst
Original file line number Diff line number Diff line change
Expand Up @@ -16,3 +16,4 @@ Architectural Decision Records (ADRs)
0009-course-catalog-info-changed-design
0010-multiple-event-types-per-topic
0011-depending-on-multiple-event-bus-implementations
0012-producing-to-event-bus-via-settings