Closed TheDahv closed 4 years ago
@TheDahv that's correct. It's not possible to start the app without configuring them first at the moment, as Dispatch relies on them to provide the core functionality. We will consider adding support for it in the future. Thanks for the feedback.
We can definitely do this, the only downside is the dispatch
isn't particularly useful without any plugins installed (essentially a crud app with some tables). From a new user perspective; does that matter? Is it enough to see something run?
Here's my thinking on it:
Thanks for the insight @TheDahv. We are pretty tightly coupled to those services at the moment. But I agree with what you're saying.
Internally, we were also discussing the value in setting up a demo instance of dispatch for folks to play with. But that would also be a large amount of work. Trying to weigh what would be most beneficial to most people.
Unfortunately, Dispatch has a rather high startup cost associated with it today (setting up GSuite, slack etc.).
Understandable for where things are. I'm happy leaving this as a feature request to be prioritized accordingly.
I'm eager to champion this at work.. I'll keep an eye on the space and try to push things forward where I can.
I think there is a lot of value in making it easy to get started and be able to show a proof of concept to stakeholders. Right now I would love to get involved in working with this project and maybe scoping out a Confluence or ServiceNOW plugin, but it would be a hard sell if I can't even get this project working either technically or logistically (e.g. not having GSuite or PagerDuty, etc). I know a handful of other companies would be very interested in an incident orchestration tool like this, but would also be in the same boat.
I second @TheDahv point, these are plugins and can be optional. E.g. only Google integration should be mandatory for real use. But the first step in evaluating this solution should be checking a demo and available features/IR workflow.
I was thinking to comment out all sections that rely on Dispatch plugins today :)
I'm not sure commenting out the plugins will work particularly well, instead what I would suggest is to use mock (or fake) plugins instead.
If you take a look at our tests: https://github.com/Netflix/dispatch/tree/develop/tests/plugins
You can see that you can make any plugin return static or mocked out values, perhaps for demo purposes we could simply have plugins that return static or pseudo-static values?
Here's my current line of thinking. I don't know if I have the Python chops to pull it off.
.env
file: PLUGIN_DISABLE_$PLUGIN_NAME=True
enabled
property we ought to be able to configure at boot time https://github.com/Netflix/dispatch/blob/develop/src/dispatch/plugins/base/v1.py#L60-L62With that information available, we could do a few things:
I'd be happy to work on some of those bits but I'd need some guidance:
@TheDahv If you want to eventually expose the plugins via the UI/API. This would be the process I would follow:
Create a new plugins model (database table) with fields for plugins and their required state/options. This can be done in a bunch of ways, in the past, I've created a simple mapping stored in JSON that ends up being mapped to the front end UI and validated. See here and here.
Modify the install_plugins
function you mentioned to add/enable/disable any installed plugins.
Create a service to talk to your model: See: here
Expose a /plugins
api See: here
Create a new Vue component See: here
Modify or create a new get_plugin
function that would first reference the plugin table (to fetch the correct installed/enabled plugin)
If no plugin is installed/enabled emit an error to the user. (to me, this is the hardest part as our UX is both in slack and the Admin UI).
Remove all plugin settings/references from the env/config.
++ The tight integration of the services we don't actually use internally is a blocker on adoption, or even being able to run a proof of concept.
@zachzeid which services do you use? A lot of work is delegated out to plugins... So simply disabling plugins won't give you a very good proof of concept.
Well it’s not about the plugins, it’s about the ability to even start the core app without the default plugins configured in the first place.
On Thu, Mar 12, 2020 at 17:17 kevgliss notifications@github.com wrote:
@zachzeid https://github.com/zachzeid which services do you use? A lot of work is delegated out to plugins... So simply disabling plugins won't give you a very good proof of concept.
— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/Netflix/dispatch/issues/55#issuecomment-598422171, or unsubscribe https://github.com/notifications/unsubscribe-auth/ADJ6WR4TTWDKRNFOOKL6PYDRHFGNZANCNFSM4K4RM7WQ .
Hello I would like to contribute to this, I will give my 2 cents on this. What do you think if all plugins would be disabled by default, and enable them if required fields are present in env vars such as authentication fields, urls etc...
From what I read in other issues is that core functionality resides within some plugins, wouldn't be a good idea to move that code in the core and provide a default CRUD app?
If this was to be done, you could link and enable plugins via UI, this would make dispatch more accessible.
I think we can make the core CRUD app run more smoothly with a limited set of configurations, and exposing those settings via the UI.
However, I don't believe we can move most plugin functionality into the core application, without greatly increasing the scope of the application.
One of the Dispatch's strengths is relying on tools you already have within your organization to handle incidents, the downside of this is that it requires you to configure Dispatch to use those applications.
Think about all of the functionality that would have to be replicated to provide a zero-configuration Dispatch. We would have to implement:
and more...
At the end of the day, most users have no idea Dispatch exists, yes it as an Admin UI for folks that need it, but for those responding to incidents, all they ever see is the applications they already use (Google Docs, Slack, etc.,). This is by design.
After having thought about this more, I think there is value in having the ability to enable plugins incrementally. I will be working on several PRs decoupling incident creation from creation of resources (and thus plugins).
In the end, I hope to essentially provide a bare dispatch install that works without configuring any plugins. Letting the plugins be additive in value.
Thank you all for the feedback and context.
Stale issue message
Reading through the docs and the code, I'm not able to discern if there's a way to boot the core Dispatch experience without the Slack, Google, Jira, and PagerDuty plugins?
The docs and the way the app behaves appear to imply that Dispatch will not work without them configured.
However, suppose I just want to get started to evaluate without configuring everything, I'd like a way to disable those plugins just to reduce the distance from" 0-to-UI" for evaluation purposes.
Or boot Dispatch by default and enable plugins one at a time via an Admin UI.
If this isn't already supported I can update the issue title to make this more of a feature request.