Definitely +1 if we keep it as a bundled plugin. What are we going too do with monitoring periodic works and NodeMonitor APIs?
- We can leave them in the Core - We can move them into the plugin as well The second approach looks to be more generic since we suffer from performance impact of monitoring sometimes. On the other hand, it requires more efforts and decreases the visibility of these extension points. вторник, 12 января 2016 г., 23:33:56 UTC+3 пользователь Baptiste Mathus написал: > > Hi everyone, > > Some context: > ----------------- > In the past few days, I've been working on JENKINS-24278 > <https://issues.jenkins-ci.org/browse/JENKINS-24278> to add inodes usage > monitoring to Jenkins. That initially resulted in the creation of a new > dedicated plugin <https://github.com/batmat/inodes-monitor-plugin>. > > After some discussion with Oleg, I filed a PR against core to add the new > monitor > alongside the DiskSpaceMonitor one (since monitoring inodes usage is just > as important > as monitoring disk space). > > (If you wonder what those *monitors* are, they are what's used to generate > this table > <https://cloud.githubusercontent.com/assets/223853/12249957/8fd3cf8c-b8c3-11e5-9b8b-39e40e87c280.png> > on > the /computer > page). > > Discussion ensued, again :) > ----------------------------------- > In that PR > <https://github.com/jenkinsci/jenkins/pull/1974#issuecomment-170930133>, > along with fixing things here and there, we basically finally came to the > currently common idea that instead of adding things to core, we should > strive and split > them from it. > > That would indeed have many advantages: not cluttering core with a new > class, > disconnect the lifecycle of those classes from core (that is: new > features/fixes would be > usable w/o having to wait a release many months later, or an LTS backport). > > As James said in the PR, for example, ssh-slaves plugin is even more > important than node > monitoring, and *is* a plugin. > > Split Proposal > --------------- > So, the proposal is basically to remove the *hudson.node_monitors* > package from the > core, and make that a new plugin (+adding the inodes usage monitoring as a > future > step, obviously). > > When done, I suppose that in the short term, at least for backwards > compatibility > reasons we would add it as a bundled plugin. > > I'm willing to work on that one, but will obviously welcome any help > and/or feedback on > what to double-check to do it correctly. > > What I already for example have in mind is to use git filter-branch to > preserve history on > those classes in the new plugin (though we would still have it in core if > need be). > > WDYT? > > Thanks > > -- Baptiste > -- You received this message because you are subscribed to the Google Groups "Jenkins Developers" group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-dev+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/7bf8238c-c532-4928-8ecf-a8ae93bbaa26%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
