search

Particular / ServiceControl.Plugin.Nsb5.Heartbeat

The old Heartbeat package for NServiceBus v5
https://github.com/Particular/NServiceBus.Heartbeat
Other
0 stars 1 forks source link

Make feature class public so it can be disabled in the configuration. #12

Open ramonsmits opened 8 years ago

ramonsmits commented 8 years ago

Shouldn't the feature class be public so that is can be disabled? Currently, the only option is to

https://github.com/Particular/ServiceControl.Plugin.Nsb5.Heartbeat/blob/develop/src/ServiceControl.Plugin.Nsb5.Heartbeat/Heartbeats.cs#L15

johnsimons commented 8 years ago

IMO, the fix for this is to make the plugin not auto register and instead make it a opt-in in code configuration @Particular/servicecontrol-maintainers thoughts ?

mikeminutillo commented 8 years ago

There is a mismatch here with the way this is expected to work and the fact that it is a NuGet package.

The ServiceControl plugins are an extension of ServiceControl which is a product. You are supposed to just be able to just drop the DLLs next to an endpoint, restart it and it will work. There should be no code changes. In most cases you don't even need to update a config file. It should be possible for operations to install it without consulting with developers.

In contrast, it is available as a NuGet package. This requires a developer in Visual Studio (or using a Build Server or whatever) to include it as a part of a build. It will get added to your project and an unnecessary project reference will be added to it. This makes it a library and makes it much easier to include it in statements like "prefer code-first API over XML config". So we could just throw if you haven't configured a ServiceControl queue (for example) because you explicitly added a reference to it.

So, we need to decide what this is.

If it's a library (NuGet package) then we should ditch the XML API and include a code-first API to explicitly turn the feature on and include configuration like the location of the SC queue, heartbeat interval, etc.

If it's a black box plugin, then we should probably remove it from NuGet and provide an alternative means of getting it.

What we should (eventually) do is recognize that there are two concerns here and break them up. I think there should be an NServiceBus.ServiceControl NuGet package that you can install and configure the location of your ServiceControl instance via code. Then allow SC to have a set of plugins that it can send to an endpoint. i.e. In Pulse you could select an endpoint(s) from a list and check the "enable heartbeats" option. This would send the heartbeats plugin to each of the selected endpoints, start it up, and start sending heartbeats back to SC for monitoring in Pulse.

The NServiceBus.ServiceControl plugin that you had to get devs to install is your gateway into the rest of the platform capability and it allows SC to open a two-way dialog with any endpoint. You want Custom Checks? Write them in a DLL, upload them to your SC instance and push them to the endpoints that need to run them. Manage it all in SC (via Pulse).

If we're eventually going to go down this sort of path then we want to discourage people from installing the plugins via NuGet.