Add binary install type

[rayrod2030]

In additional to supporting installing from source it would be great to be able to define a pre-compiled prometheus binary URL and have the cookbook download and run that. This download should support a file checksum.

[tuahk]

Started working on this. My idea was to make a new recipe binary.rb. I might need to do some changes to our code since there are things needed in both source.rb and binary.rb. For example init options are the same for source and binary so maybe make init.rb recipe that is then included in both? Also user setting and config template are probably needed in binary.rb. Let me know if you had some ideas or preferences on this matter?

[rayrod2030]

Yeah I like busting out the install types into separate recipes. Keep an eye on this PR https://github.com/rayrod2030/chef-prometheus/pull/22 as it might impact your work.

[ewr]

For #22, I took the approach of assuming that the default recipe is the glue between whatever install type you're using, and that common pieces can go in there (and that's where I moved the config generation). Breaking out into another recipe (such as for init) does give you more control over having it run midway through your install recipe, though.

[tuahk]

Yeah, that is also a good option. Then you could move user resource form source.rb to default.rb and move that config generation before install is run?

Even if we decide to use default recipe as glue I think it would be cleaner if init is in a separate recipe and then included in default.

[ewr]

Assuming we're talking about a binary install that is just dropping a prometheus file into place, then yeah, you could move user, directory and config into default before the install.

If you were dealing with system packages, you would need to be a little more flexible to match what the system package expects to set up. Since this is go and statically-compiled, though, that's probably not going to be necessary.

The only thing that is important re: init is making sure you always end up with that service[prometheus] definition so that the config file et al can notify it for restarts.

[tuahk]

Yup that kind of binary installation I had in mind.

My original idea was to bust out directories and user to one recipe and init to one. I also thought about moving config template to it's own recipe. Then include these in source.rb and binary.rb

When the time comes that Prometheus starts offering packages, then we will not need same resources that we do with binary and source, right? So my thinking was that we don't want them in default recipe but instead use multiple recipes in binary and source. But prometheus_job things could be in default since they are going to be used no matter the installation type. Does this make any sense?

[ewr]

It depends on what sort of binaries they ended up offering. Many Go packages end up just being binaries, not system packages.

I tend to suspect you're always going to need the directory and user options (or at least something similar). Even if you have a system package that installs in its own way, if you're offering attributes for configuration you still need to support creating whatever the user specifies.

I'd say start with less recipes and only break out later if needed, but there's certainly no one right answer.

[tuahk]

I trust your reasoning and start moving thing to default.rb. Thank you for helping!

[rayrod2030]

Feature added via https://github.com/rayrod2030/chef-prometheus/pull/24. Just need to update README and we should be good to go.

[rayrod2030]

Added via https://github.com/rayrod2030/chef-prometheus/pull/27