Backport of Add nomad monitor export command into release/1.10.x #26409
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Backport
This PR is auto-generated from #26178 to be assessed for backporting due to the inclusion of the label backport/1.10.x.
The below text is copied from the body of the original PR.
Description
The nomad monitor export command introduces the ability for nomad to export logs a given agent has written to journald or to the nomad log file. Journald logs can be requested for a specific period of time while we just return the agent's entire nomad log file. Introducing this RPC is a prerequisite for adding journald logs to the nomad support bundle.
Pasting a link to a comment deep in the thread regarding fixes for inconsistencies related to ending the stream.
#26178 (comment)
Testing & Reproduction steps
Links
Contributor Checklist
changelog entry using the
make cl
command.ensure regressions will be caught.
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.
Pulled this from the Contributor checklist for new cli commands, I
struck outa few items that didn't seem to fit this use case but I'm happy to revisit them if I was wrong there.CLI Command Checklist
prior art we should match? Arguments, flags, env vars, etc?
command/
or in an existing file if a subcommandcommand/
packagecommand/commands.go
command/agent/<command>_endpoint.go
command/agent/http.go
nomad/<command>_endpoint.go
client/<command>_endpoint.go
(For client endpoints like Filesystem only)nomad/structs/
package Request and Response structs (cstructs, but still)api/
package helper methodsI added a
monitorHelper
function to more cleanly share the existing monitor code in /api/agent.go. I did not add an additional test for the helper or the MonitorExport command. Mostly because I'd have to update the Client Config structs to be able to set theLogFile
value on the api Client. But the only difference between the Monitor & MonitorExport commands inapi/agent.go
is which path is passed to themonitorHelper
and helper is exercised in the existing monitor tests.* [ ] For nested commands make sure all intermediary subcommands exist (forexample,
nomad acl
,nomad acl policy
, andnomad acl policy apply
mustall be valid commands)
* [ ] If the command has astatus
subcommand consider adding a search contextin
nomad/search_endpoint.go
and updatecommand/status.go
* [ ] Implement-json
(returns raw API response)* [ ] Implement-t
(format API response using gotemplate)* [ ] Implement-verbose
(expands truncated UUIDs, adds other detail)* [ ] Implement and test newapi/
package Request and Response structsDocs
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.
Overview of commits