search

George3d6 / Inquisitor

An easily extensible, minimal footprint monitoring tool. (Still in the testing phase)
BSD 2-Clause "Simplified" License
30 stars 4 forks source link

Release 0.4 proposal #37

Closed Deedasmi closed 6 years ago

Deedasmi commented 6 years ago

I'd like to propose that 0.4 be a 'You're welcome to make your own plugins' semi-stable release. Here is a shortlist of items that need to be addressed first:

Other notes

  1. I still want to work on #6, at least get it proofed out, which would be a breaking change.
  2. I don't think #5 or #7 will be breaking changes.
George3d6 commented 6 years ago

Seems reasonable, feel free to create the realease (or I will do soon soon[tm]).

Don't you think it might be a bit Overkill publishing all plugins and making them separate crates/projects though ?

Would it bring any real adavantage ? It seems like hell Dev wise and changing the relatively few agent plugins is already annoying.

Deedasmi commented 6 years ago

To clarify, I would probably only suggest one 'inquisitor_plugins' repo, not individual repos for all plugins. That would be a pain. Basic structure would probably be:

README.md
Cargo.toml // Authors, workspace
LICENSE.md  // Might want in individual plugin repos? Not sure
agent_plugins/
  alive
  command_runner
  ...
receptor_plugins/
  sync_check
  ...

Having the plugins out in a different repo allows us to keep the commit and release history in this repo clean. You can still use git links in cargo for unpublished crates, which is what I would suggest initially. See note at end of post.

The situation I specifically want to avoid is release tag 1.0 being 120 commits behind master, none of which actually affect the 'core' of the agent/receptor. Or maybe they do. Hard to tell. Change log would be a pain of scrolling through dozens of plugin only commits. It also has the benefit of having a separate issue tracker for plugins.

Initially, using git links for the actual plugins in the Cargo.toml should be fine. However, before 1.0, we should publish them so that individuals can 'lock' their plugin to a certain version. The big use case for publishing individual plugins is if you're running some type of metrics or report on the data. Having agents dispersed over multiple versions can change what data is stored and break the reports.

George3d6 commented 6 years ago

One repo for all the "core" plugin seems much more reasonable to maintain.

I will also be merging the agent_lib, receptor_lib and shared_lib tomorrow, into a big "inquisitor_lib" to be used by plugins.

However, can we use git links in the Cargo.toml for individual plugins if they are all in the same repo ? E.g. something like: github/Inquisitor/agent_plugins/file_checker ? Or would be have to include all plugins in bulk and just activate the ones we need (whilst we go with the shared repo approach and don't publish them on crates) ?

George3d6 commented 6 years ago

Also, if we are going to separate this into 2 or 3 repos, I think it may be worth looking into the github "project" feature thing, personally I've never used it.

Deedasmi commented 6 years ago

Honestly, I can't promise, that is an assumption I made. I'm entirely offline this weekend, but will test it out when I get back if you haven't gotten to it.

Do you mean organizations? They are useful and pretty easy to use.

George3d6 commented 6 years ago

I feel organization may be too large in scale for this project at the moment, to be honest. For now I'd be tempted to keep it together and if we get some traction (e.g. at least 3-4 contributors and 5-10 active users or at least users that are prototyping this in their test infrastructure) we could think about splitting up the code.

... but those are just my feeling for the moment, that is, that I'd prefer to delay the splitting up of the project on github for a while.

Deedasmi commented 6 years ago

Sounds good. I'm closing this in favor of #49, #48, #40, #39, and #15