Event drivers used to be deployed only in an isolated environment, using a sidecar which handled the communication for it. Now that sidecar is gone, we need to figure out an alternative way. Things like associating the proper organization, authentication of the driver, ensuring delivery, etc. Some of them are less important in the context of Dispatch solo. This issue is mainly about handling authentication.
Detailed Description
Event driver's main responsibility is to obtain (or listen for) events from an external source. The event is then pushed to Dispatch server for delivery to subscribers (if any). There are two problems with it:
The driver needs to authenticate itself - server must know that the driver sending the event is recognized and expected to do that.
events from the driver must be associated with a correct organization.
Previously this was covered by a combination of a sidecar & a fact that drivers were always deployed locally (to the same k8s cluster and namespace). For Dispatch solo, we removed the sidecar to remove the dependency on an external message queue, as well as we added a way to specify remote HTTP endpoint to allow drivers to be deployed in remote locations.
Context
Complexity
[ ] Low - Simple enhancement or bug fix, no architectural changes or refactoring
[x] Medium - Change requires some thought, but is relatively isolated
[ ] High - Significant architectural change or large refactor
kars7e
commented
5 years ago
Feature Request
Event drivers used to be deployed only in an isolated environment, using a sidecar which handled the communication for it. Now that sidecar is gone, we need to figure out an alternative way. Things like associating the proper organization, authentication of the driver, ensuring delivery, etc. Some of them are less important in the context of Dispatch solo. This issue is mainly about handling authentication.
Detailed Description
Event driver's main responsibility is to obtain (or listen for) events from an external source. The event is then pushed to Dispatch server for delivery to subscribers (if any). There are two problems with it:
Previously this was covered by a combination of a sidecar & a fact that drivers were always deployed locally (to the same k8s cluster and namespace). For Dispatch solo, we removed the sidecar to remove the dependency on an external message queue, as well as we added a way to specify remote HTTP endpoint to allow drivers to be deployed in remote locations.
Context
Complexity