REQUEST: Configure enabled/disabled plugins about dispatch HOT 17 CLOSED

Here's my thinking on it:

• a simple CRUD app is enough to show value non-technical stakeholders at a company
• it enables someone like me to say "hey look, we could be standardizing how we think about incidents and keeping track of it somewhere...here Netflix has already given us a structured way to think about it"
• removing barriers to adoption and focusing on progressive enhancement means internal champions can start culture change around incident management in the small
• it enables a team to adopt Dispatch incrementally. I don't think we really use PagerDuty anymore, and I wouldn't want to have a Dispatch conversation tightly-coupled with budget line items for other services

from dispatch.

from dispatch.

++ 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.

from dispatch.

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.

from dispatch.

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.

from dispatch.

@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.

from dispatch.

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?

from dispatch.

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.).

from dispatch.

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.

from dispatch.

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 :)

from dispatch.

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?

from dispatch.

Here's my current line of thinking. I don't know if I have the Python chops to pull it off.

• First, establish a convention to disable or "opt out" of a plugin in the .env file: PLUGIN_DISABLE_$PLUGIN_NAME=True
• Update this block of code to look at configuration at boot time: https://github.com/Netflix/dispatch/blob/develop/src/dispatch/common/utils/cli.py#L37-L46
• Seems like each Plugin has an 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-L62

With that information available, we could do a few things:

• alter the Plugin classes to return early on the register/install step if they are disabled
• expose that information to the Vue app
• have the Vue app render an alt state for each component that is disabled with a CTA to contact the administrator to install the plugin

I'd be happy to work on some of those bits but I'd need some guidance:

• is that plan viable?
• I'm a Node and Go programmer, so where should I start looking if I'm not familiar with the project layout?

from dispatch.

@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.

from dispatch.

@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.

from dispatch.

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.

from dispatch.

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:

• A chat component similar to Slack
• Document editing similar to Google Docs
• VC meetings similar to Zoom or Google Meet

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.

from dispatch.

Stale issue message

from dispatch.