Netflix / dispatch

All of the ad-hoc things you're doing to manage incidents today, done for you, and much more!
Apache License 2.0
5.09k stars 508 forks source link

REQUEST: Configure enabled/disabled plugins #55

Closed TheDahv closed 4 years ago

TheDahv commented 4 years ago

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.

mvilanova commented 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.

kevgliss commented 4 years ago

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?

TheDahv commented 4 years ago

Here's my thinking on it:

kevgliss commented 4 years ago

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

TheDahv commented 4 years ago

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.

lastlee commented 4 years ago

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.

tgrzinic commented 4 years ago

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

kevgliss commented 4 years ago

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?

TheDahv commented 4 years ago

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

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

kevgliss commented 4 years ago

@TheDahv If you want to eventually expose the plugins via the UI/API. This would be the process I would follow:

zachzeid commented 4 years ago

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

kevgliss commented 4 years ago

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

zachzeid commented 4 years ago

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 .

stefanm8 commented 4 years ago

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.

kevgliss commented 4 years ago

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.

kevgliss commented 4 years ago

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.

github-actions[bot] commented 4 years ago

Stale issue message