Golang Handlers, Checks, Oh My

[mattyjones]

Transfer Ownership

We would like to transfer the ownership of this plugin to the sensu-plugins organization in hopes of better community support and exposure. These are golang projects that may prove useful as starting points for others. They are stable with varying degrees of testing. Most were written a while ago and need some love which after the transfer I will tackle one at a time with the goal of documenting the code and improving test coverage. Deployments would also need to be figured out. Honestly I think just pulling from GH for now is best or gems (using binstubs) with rpm/deb/tgz being the eventual goal.

Repo to transfer: several

I am also interested in continuing to help as a maintainer of this plugin 👍

[mattyjones]

Here is the contributing doc I was orginally using but will update it to be more inline, but is contains a start for the golang specific stuff we want.

https://github.com/yieldbot/sensupluginsfile/blob/master/CONTRIBUTING.md

[majormoses]

the the sensu-plugin equivalent we should rename it to sensu-plugin-go

[majormoses]

we probably will want to rename others as well to comply with our naming conventions.

[mbbroberg]

@mattyjones it's great to see all your Sensu and Go work here. It's awesome work. Before we migrate anything, I think it's important for us to consider:

• That these are a completely different format for plugins. Nothing about these will be clear to use compared to existing plugins in this org
• We'll have plugins that do the same thing in different languages. That may not be a challenge in the short term, but in the long term it should be easy for users to see what plugin is recommended for a given task

With that in mind, let's slowly move forward and focus on the library to start. @portertech mentioned he may want to collaborate on dev there.

[majormoses]

:+1: to starting only with the plugin library for creating other go plugins and mature that one with appropriate documentation, testing, etc before cutting it loose to the community and create support headaches we are not ready to deal with yet.

We'll have plugins that do the same thing in different languages. That may not be a challenge in the short term, but in the long term it should be easy for users to see what plugin is recommended for a given task

I don't see that an issue at all as long as there are SMEs with appropriate coverage for each language. As a very heavy contributor to plugins and my familiarity with ruby I don't see myself using the go plugins any time soon for no reason other than I do not expect a run this which does everything you want experience and expect that every time I use a new plugin I expect I will need to enhance it. I personally do not find go nearly as good to work with as ruby being responsible for systems. I am not saying go is bad, I think its great for lower level problems and where the scale is really important but for 99.99% of sysadmins they are gonna be comfortable with python or ruby. I think the biggest question is namespacing, for all non ruby plugins we should prefix the language name so that it will be clear that sensu-plugins-go-pagerduty is clearly the go implementation the same could be said for pure python plugins (many of the ruby plugins include python scripts).

[mattyjones]

Just got back around to looking at this and Sensu go. I agree with the library. @mbbroberg @portertech @majormoses I think the first steps should be to draw up a required functionality doc, not "direct port from ruby" The we/I could start slowly implementing it with full test coverage. At that point when we feel it is stable, we look at the existing go plugins and either scrap them or port them to use the stable library.

Thoughts?

[majormoses]

Makes sense to me, not that I am saying it should be a direct port of the ruby one but I think the to more feature parity it has the better. Taking a look through the plugin library I think these would be the minimum requirements to move over from the plugin:

• check cli:
  • standard output format
• metric cli
  • standard output format (default to graphite?)
  • graphite output format
  • statsd output format
  • influxdb output format
  • json output format
• handler:
  • truncate output (for server safety)
• mutator:
  • to_json coverter
• misc/util:
  • standard interface for defining cli args
  • standard exit codes (and functions for each of them)
  • base exception handling
  • standard interface for accessing config (env vars, config file(s)/dir(s))

[mattyjones]

Fair enough, pending further comments I am going to break this out and put it in its own repo for the time being so I/anyone can work on it. What are the thoughts of moving it to sensu-plugins in its current state with the notion that it is a work in progress and here is a defined roadmap for it.

I think that makes more sense than two or three people tooling on it in a vacuum as others who have the skillset won't even know it exists, thoughts?

If I recall it already conforms somewhat to the libraries used for sensu, cli/cobra/viper/logrus.

Concerning naming conventions, I stress camelCase, which is what I have in place. I do this fro several reasons including a somewhat standard among Go and dashes and underscores are somewhat frowned upon.

For reference, here is the repo

[majormoses]

What are the thoughts of moving it to sensu-plugins in its current state with the notion that it is a work in progress and here is a defined roadmap for it.

I am all for moving it over but I think we rename the repo (not the internal co code paths) to sensu-plugin-go(lang)? as this is what we have done with python and I would like us to be consistent. We should indicate that it is under heavy development and is subject to frequent breaking changes until we get to a certain point.

I don't know what the "gold standard" for go linting is but we should probably get one setup if not already I found this list: https://github.com/golangci/awesome-go-linters

[mattyjones]

I have some time later on tonight and will simply create a new repo and copy the code over and then start to figure out the process. The first thing on the list will be general cleanup and then tests for what already exists.

Documentation about the project and the codebase should also be an initial priority, taking into account your suggestions, I will work on the assumption of pre-releases and an alpha state till tests are written and it runs without issue on Sensu2, then I think we can switch to beta as I have been running this for almost 3 years now in Sensu1. I am fairly confident with it.