Upgrade to using hashicorp/[email protected] #24856
Conversation
This also requires bumping the dependencies for: * memberlist * serf * raft * raft-boltdb * (and indirectly hashicorp/mdns due to the memberlist or serf update)
| @@ -23,7 +23,7 @@ ifndef BIN | |||
| BIN := $(GOPATH)/bin | |||
| endif | |||
|
|
|||
| GO_TAGS := $(GO_TAGS) | |||
| GO_TAGS := hashicorpmetrics $(GO_TAGS) | |||
There was a problem hiding this comment.
Is the build tag necessary? My understanding is that without the build tag:
- The
nomadpackage and all dependencies would use thearmon.gocompatibility file today... - ...until
hashicorp/go-metricsswaps build tags to not use the compatibility file?
If the functionally is identical I'd love to leave Nomad working with bare go {build,get,install} commands.
This would also ease rolling out this change to projects that import github.com/hashicorp/nomad and expose their own metrics like https://github.com/hashicorp/nomad-pack. It'd be nice if we didn't have to update build tags everywhere as I'm not confident all our builds use the same idioms. Propagating go.mod updates is much more natural than go.mod+tag updates.
There was a problem hiding this comment.
Yes, functionally it is the same for Nomad itself.
For anyone importing Nomad directly its not so simple. The build tags are wholly controlled by whoever invokes go {build,test,install}. So the tags set in Nomad's build system are irrelevant.
Given that and your other comment about external task drivers importing the root Nomad Module I think upgrading the root Nomad module to consume hashicorp/go-metrics directly would be the wrong way to go. Instead, I will update the PR to make the root module also use the compat package like all the other libraries. I would still recommend sticking with the build tag. Eventually Nomad must move over to hashicorp/go-metrics and now is probably as good a time as any. The exception to that may be if Nomad is getting ready to put out a new major release very soon. In that case it may be best to save the change until the beginning of the next release cycle.
| @@ -5,7 +5,6 @@ go 1.23 | |||
| // Pinned dependencies are noted in github.com/hashicorp/nomad/issues/11826. | |||
| replace ( | |||
| github.com/Microsoft/go-winio => github.com/endocrimes/go-winio v0.4.13-0.20190628114223-fb47a8b41948 | |||
| github.com/armon/go-metrics => github.com/armon/go-metrics v0.0.0-20230509193637-d9ca9af9f1f9 | |||
There was a problem hiding this comment.
Our external task driver and device plugins (very unfortunately) depend on nomad directly because we haven't made our plugin dependencies into a submodule.
They're go-plugin subprocesses, so they don't (can't!) share metrics with nomad and probably don't even bother to use go-metrics.
I assume we can leave them alone until we upgrade their github.com/hashicorp/nomad dependency to the version that includes this PR at which point they'll need to upgrade from armon/go-metrics to hashicorp/go-metrics? Technically they'll still be built against armon-go-metrics due to not being built with the hashicorpmetrics tag, but since they don't actually expose metrics it shouldn't matter. When the compat code goes away, they'll be on "pure" hashicorp/go-metrics like everything else.
Just hoping to confirm my reasoning that go-plugin based projects that depend on github.com/hashicorp/nomad will be unaffected due to not actually using go-metrics.
There was a problem hiding this comment.
That is correct. For modules/task drivers compiled independently from Nomad itself, pulling in Nomad will have them use the default behavior which would be to use armon/go-metrics.
There are no HashiCorp owned drivers that I have found. For any community supported ones they can control the behavior with build tags just like if they consumed any of the other HashiCorp libraries that have use compat package (e.g. serf, memberlist, raft etc.)
| @@ -5,7 +5,6 @@ go 1.23 | |||
| // Pinned dependencies are noted in github.com/hashicorp/nomad/issues/11826. | |||
There was a problem hiding this comment.
Just noting that our reason for pinning a specific version of armon/go-metrics appears to have been resolved years ago: hashicorp/go-metrics#146
So dropping this pinning is not only ok, but a great side effect.
The Nomad root module may be imported as a library by others and this allows build tags in those other applications to control the metrics module used.
Description
On the surface this is a fairly mechanical change in deps and imports. Instead of consuming armon/go-metrics, Nomad will now use the latest version of hashicorp/go-metrics. Previous attempts to upgrade resulted in missing metrics and were reverted. This time is different because all libraries within the
hashicorpnamespace have been instrumented to use a specialcompatpackage withinhashicorp/go-metricsto allow for a compile time build tag to control the metrics module used by all libraries.This PR does 3 things:
armon/go-metricstohashicorp/go-metricsGO_TAGSvariable handling within the makefile to use thehashicorpmetricsbuild tag (global library opt-in to metrics emission via thehashicorp/go-metricsmodule)Testing & Reproduction steps
make devmkdir datanomad agent -server -data-dir $(pwd)/datacurl localhost:4646/v1/metricsNow ensure that metrics from all the libraries are still seen. I checked that there was at least one from serf, memberlist, raft and raft-boltdb.
Contributor Checklist
changelog entry using the
make clcommand.and job configuration, please update the Nomad website documentation to reflect this. Refer to
the website README for docs guidelines. Please also consider whether the
change requires notes within the upgrade guide.
Reviewer Checklist
backporting document.
in the majority of situations. The main exceptions are long-lived feature branches or merges where
history should be preserved.
within the public repository.