Open atc0005 opened 3 years ago
My plan was to work on this next, potentially this week or the next. I've since had someone show interest in developing this plugin (or contributing efforts towards it), so I will see where things go. It may be that a synergy of sorts occurs and the results of both efforts are combined into final result. If/when I start work on this I'll post back and reference the branch I'm working on in case it is helpful.
Hi Adam, i've gone through the references above. But i'm still not clear as to what we want to achieve here. Please further explain. Thanks.
Nagios is a monitoring system that calls out to "plugins" to perform actions. Plugins are either command-line applications or shell scripts that take zero or more arguments and return an error code and optionally a text string and performance data.
Nagios (what I refer to as the "console") takes those results and makes a determination regarding the state of the host or service it is monitoring.
I am simplifying, but each plugin is in charge of performing the action and returning a specific error code indicating OK, WARNING, CRITICAL, UNNOWN or a 5th state, which I forget.
The plugins that I linked to are for checking and IMAP account and a certificate, respectively. The IMAP check is the first I wrote and uses a different approach to returning the success/failure state than the cert check plugin, which uses an approach that I think I want to polish a bit and use for plugins going forward. I think. Once I get into implementing the code for this latest plugin I would probably have a good feel for things.
After thinking on this a bit, unless a further need pops up on an existing project I plan to work on the atc0005/go-nagios
project as my next medium-sized focus item. For the next few days I'll probably spend time on "repo gardening", picking back up on my work to update existing GitHub Actions Workflows to use the Docker containers from the atc0005/go-ci
project.
I was working on those tasks (https://github.com/users/atc0005/projects/1) before I got distracted by the work on this project.
All of that said, once I make some progress with the atc0005/go-nagios
project it should make work on this specific GH issue easier to implement. If you want, I can ping you here or via Twitter once I've made some progress there and we can take another look at this.
Adam, i'm going through the code in this repo, i'm still getting it, but no there yet. One thing though, why are you vendoring dependencies manually? go.mod already does this automatically. As regards the milestone we want to achieve, i'm sure i'll be able to reason about them better when i fully understand this codebase.
Thanks for the above explanations too. And yes ping me. Preferably on twitter so i get it faster.
@danvixent: One thing though, why are you vendoring dependencies manually? go.mod already does this automatically.
You're right in that it tracks dependencies and caches them locally. But what if I want to create a code archive that provides a reproducible build that reflects a point in time? For example, I'm (AFAIK) the only person on our team that uses Go, and as you can tell from the quality of the codebase, a fairly new Go developer. Most projects that I work on provide a README with build instructions. I also cache the Go installers on an internal work file server.
Presumably, if I get hit by a bus (an unfortunate stand-in for worst-case scenario that we use) our team will have everything they need between the source archives I download from GitHub and the installers that I cache to reproduce any binaries that I generate and deploy on our systems.
That's my thinking. I understand it's not for everyone (and I hear that large scale projects with many dozens of dependencies can't afford to do this), but I was leaning towards a strict sense of reproducible builds.
EDIT
A good counter-argument (in favor of what you said) for vendored dependencies:
and further discussions in both directions:
Talking about points in time
we have git, don't we?
But either way I'm also guessing you're doing this for the convenience of your team. It's a good trade-off then.
Seriously though, consider Go modules. It caches the versions directly for you. See: https://blog.golang.org/using-go-modules
Talking about
points in time
we have git, don't we?
We do, and it works well for code under our own control. Vendoring dependencies puts additional code under our control and (the thinking is) helps with reproducible builds.
I'm also guessing you're doing this for the convenience of your team. It's a good trade-off then.
Correct, though at this point I'll probably continue the practice regardless of the environment, at least for now.
Seriously though, consider Go modules. It caches the versions directly for you. See: https://blog.golang.org/using-go-modules
Acknowledged. I'm actually using Go modules and started off my first project using them. At this point I couldn't imagine not using that functionality.
The nice thing is that using Go modules doesn't preclude you from using vendoring, it actually supports that workflow.
go mod tidy
go mod vendor
This results in a local vendor
folder that goes into version control containing the latest dependencies as specified by the project's go.mod
file. Go 1.14 even added automatic use of a vendor
folder if found, so whereas you had to use go build -mod=vendor
to use the vendor
folder prior to Go 1.14, you just run go build
now and it will automatically use the vendor
folder if it is present. This automatic use of a vendor
folder also extends to other uses of the go
tool, such as vet
, test
and so forth.
I'm aware of those features. Anyway, whatever works for you.
@danvixent: I'm aware of those features. Anyway, whatever works for you.
Cool, I couldn't be sure we were on the same page, so I figured it would be good to setup a baseline.
I'm going to mark our Go modules conversation as "off topic" (posts that we both have made) in order to collapse the GH issue a little and keep it focused on the implementation work. I don't mind that we got off-topic (some of the best conversations start that way), just pushing them a little to the background (including this follow-up post).
Summary
As I've made vague reference to at least once, I plan to include a Nagios plugin in this project. Much of the work for the
cmd/hayoh
application should be reflected in this new tool, though the overall design of a Nagios plugin will be expected.As a template, the work I did for the
atc0005/check-cert
project (specifically thecheck_cert
plugin) can be used.References