Event Manager has a concept of built-in drivers. Those drivers are hardcoded into the event manager, and when it's started, it expects an image that implements these default event drivers to be provided. Currently, there is only one built-in event driver: vcenter.
This is a proposal to remove the built-in drivers concept completely and treat all the event driver types equally.
Context
There are 3 issues with built-in drivers:
Currently, the built-in driver implementation is a part of main repo, and as such must be a part of every release, and cannot be developed separately.
Because event manager expects the driver to be provided at the startup, it complicates things when dispatch-server is used in single-host, local environment.
It requires special treatment in the event manager, which means more complexity and possible bugs.
The goal of built-in drivers was to make it easier to deploy most commonly-used event drivers, but using event driver types concept seem to be easy enough. Also, there is a possibility of using event drivers in broader ecosystem thanks to cloudevents spec (e.g. using them independently from Dispatch) and separating the driver from the Dispatch core codebase should help in this endeavor.
Possible Implementation
The vcenter driver would be moved into a dedicated repo under dispatchframework organization in github and docker hub. It would act as any other driver, i.e. you first need to create a driver type before you can create a driver. To ensure a smooth transition, when an attempt to create a vcenter event driver is made an vcenter driver type is not created, the error message will include the information about the change and the url to the vcenter driver repo.
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
Feature Request
Detailed Description
Event Manager has a concept of built-in drivers. Those drivers are hardcoded into the event manager, and when it's started, it expects an image that implements these default event drivers to be provided. Currently, there is only one built-in event driver: vcenter. This is a proposal to remove the built-in drivers concept completely and treat all the event driver types equally.
Context
There are 3 issues with built-in drivers:
The goal of built-in drivers was to make it easier to deploy most commonly-used event drivers, but using event driver types concept seem to be easy enough. Also, there is a possibility of using event drivers in broader ecosystem thanks to cloudevents spec (e.g. using them independently from Dispatch) and separating the driver from the Dispatch core codebase should help in this endeavor.
Possible Implementation
The vcenter driver would be moved into a dedicated repo under dispatchframework organization in github and docker hub. It would act as any other driver, i.e. you first need to create a driver type before you can create a driver. To ensure a smooth transition, when an attempt to create a vcenter event driver is made an vcenter driver type is not created, the error message will include the information about the change and the url to the vcenter driver repo.
Complexity