This was done to simplify the deployment and delivery process. When working with a repo as diverse as the community-plugins it’s very hard to version and deploy it in the methods that we all would like. Splitting the repo into smaller pieces makes this much easier and more manageable in the long run.
The repos are named based up the application, product, or function they are associated with. This means that if you use apache, you need only install the sensu-plugins-apache gem or clone the repo. When it comes to handlers and mutators the same convention was used so that in the future if a check is added the repo name won’t change. Sensu-plugins-pagerduty is a great example, it may only contain handlers at this time but if in the future we want to add a check of an endpoint we don’t need to do anything more than bump the version and update the docs.
Besides having a standard naming convention makes automation and deployment tools very happy and we all use them right?
One of the conditions for dropping the prerelease or alpha tag will be a complete README that will include a list of all binaries and what each one does, sensu-plugins-disk-checks does this now.
One of the overriding issues is that there should be a standard naming scheme for the entire framework. It is very hard to effectively automate something if the pieces are scattered or named differently. As of now the current names are here to stay.
Tests are coming, that is one of the core requirements for stability and production grade. Tests are hard to write for some of these things given the very specific nature of them and most of us have other jobs so we can only contribute so much.
The readme will contain sample configs and commands. Many of the plugins also have a header that contains specific details. If this is lacking ask in IRC or on the mailing list and someone will be able to assist you.
No! It will be frozen in place at a date TBD, most likely sometime Fall 2015 although that is a moving target and dependent upon a lot of things.
If a gem exists then that would be the best way. Instructions for installing it can be found in the README of the repo or here. If no gem exists yet, then you can attempt to build one based upon the gemspec. You can also install straight from source.
All repos have releases, you can just download the latest tarball or zip file, cloning the master branch is not recommended, supported and never will be. Unless it’s a breaking change, the repo will not contain feature branches, everything will be pushed to master. You have been warned.
All gems will be signed and each repo will contain the public key. If you are really concerned you could just inspect the code yourself as well before deployment.
Not at this time, due to the design of Sensu, gems are the best choice. RPM’s and Deb packages have not been ruled out but the manpower to create them is just not there at this time. If you have a very strong interest in this drop us a line and we can chat some more.
We will target the latest the EOL Ruby, currently that is 1.9.3.
1.9.3, 2.0, 2.1, 2.2
Note: Linting is not done against 1.9.3
Details are in .rubocop.yml within the root of each repo and in the developer guidelines