-
Notifications
You must be signed in to change notification settings - Fork 94
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
feat: Dry run flag to print preflight specs to std out #1240
Conversation
* Remove duplicate version.go files
Here is an example parsing specs from a helm chart (stdin), a url and a local file, then printing to stdout. [evans] $ helm template examples/sdk/helm-template/mychart-0.1.0.tgz --set preflight=true | ./bin/preflight --dry-run https://raw.githubusercontent.com/replicatedhq/troubleshoot/main/examples/preflight/host/cpu.yaml -
apiVersion: troubleshoot.sh/v1beta2
kind: HostPreflight
metadata:
creationTimestamp: null
name: cpu
spec:
analyzers:
- cpu:
outcomes:
- fail:
message: At least 4 physical CPU cores are required
when: physical < 4
- fail:
message: At least 8 CPU cores are required
when: logical < 8
- warn:
message: At least 16 CPU cores preferred
when: count < 16
- pass:
message: This server has sufficient CPU cores
collectors:
- cpu: {}
status: {}
---
apiVersion: troubleshoot.sh/v1beta2
kind: Preflight
metadata:
creationTimestamp: null
name: sample
spec:
analyzers:
- postgres:
checkName: Must be postgres 10.x or later
collectorName: pg
outcomes:
- fail:
message: Cannot connect to postgres server
when: connected == false
- fail:
message: The postgres server must be at least version 10
when: version < 10.x
- pass:
message: The postgres connection checks out
collectors:
- postgres:
collectorName: pg
uri: postgresql://user:password@hostname:5432/defaultdb?sslmode=require
status: {} |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
like the approach, couple of minor questions.
cmd.AddCommand(OciFetchCmd()) | ||
preflight.AddFlags(cmd.PersistentFlags()) | ||
|
||
// Dry run flag should not persist between across subcommands. Adding here to avoid that | ||
cmd.Flags().Bool("dry-run", false, "print the preflight spec without running preflight checks") |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
isn't this added below in pkg/preflight/flags.go? Not sure I understand the comment.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
isn't this added below in pkg/preflight/flags.go? Not sure I understand the comment.
All flags in pkg/preflight/flags.go
are also available to all subcommands e.g preflight completions
.
[evans] $ preflight completion -h
Generate the autocompletion script for preflight for the specified shell.
See each sub-command's help for details on how to use the generated script.
Usage:
preflight completion [command]
Available Commands:
bash Generate the autocompletion script for bash
fish Generate the autocompletion script for fish
powershell Generate the autocompletion script for powershell
zsh Generate the autocompletion script for zsh
Flags:
-h, --help help for completion
Global Flags:
--collect-without-permissions always run preflight checks even if some require permissions that preflight does not have (default true)
--collector-image string the full name of the collector image to use
--collector-pullpolicy string the pull policy of the collector image
--cpuprofile string File path to write cpu profiling data
--debug enable debug logging
--format string output format, one of human, json, yaml. only used when interactive is set to false (default "human")
--interactive interactive preflights (default true)
--memprofile string File path to write memory profiling data
-o, --output string specify the output file path for the preflight checks
--selector string selector (label query) to filter remote collection nodes on.
--since string force pod logs collectors to return logs newer than a relative duration like 5s, 2m, or 3h.
--since-time string force pod logs collectors to return logs after a specific date (RFC3339)
Use "preflight completion [command] --help" for more information about a command.
Running preflight completions --dry-run
or preflight completions --since 3h
is redundant.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Alternatively, we could change this line to preflight.AddFlags(cmd.Flags())
Personally I prefer each subcommand to explicitly list all the flags it needs to expose like the support-bundle binary
does. Thats for another PR though. I thought refactoring this part would have been scope creep.
pkg/preflight/run.go
Outdated
|
||
warning := validatePreflight(specs) | ||
if warning != nil { | ||
fmt.Println(warning.Warning()) | ||
return nil |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I kinda want this warning in the dry-run also
if warning != nil { | ||
return warning | ||
} | ||
} | ||
|
||
if specs.UploadResultSpecs != nil { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
can we avoid losing the validation of this type?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
can we avoid losing the validation of this type?
TL;DR - We aren't losing the validation. It takes place here where that list of troubleshootv1beta2.Preflight
objects will contain both PreflightSpec
and UploadResultSpecs
preflight objects which were in the original PreflightSpecs
struct
Longer description
Changes in this PR have gotten rid of the PreflightSpecs struct in favour of using TroubleshootKinds
.
Here is a comparison of the structs
type PreflightSpecs struct {
PreflightSpec *troubleshootv1beta2.Preflight
HostPreflightSpec *troubleshootv1beta2.HostPreflight
UploadResultSpecs []*troubleshootv1beta2.Preflight
}
type TroubleshootKinds struct {
// redacted ...
HostPreflightsV1Beta2 []troubleshootv1beta2.HostPreflight
PreflightsV1Beta2 []troubleshootv1beta2.Preflight
}
As you can see both PreflightSpec
and UploadResultSpecs
store *troubleshootv1beta2.Preflight
. I changed the logic avoid transforming TroubleshootKinds
to PreflightSpecs
in favour of just using TroubleshootKinds
in an effort of having a common type that houses troubleshoot spec objects. Now objects there were in PreflightSpecs.PreflightSpec
and PreflightSpecs.UploadResultSpecs
will be in TroubleshootKinds.PreflightsV1Beta2
. The difference between objects that were in PreflightSpec
and UploadResultSpecs
is the presence/absence of Spec.UploadResultsTo
which now handled here
Changes can be found in
- Validation code
- Code to read spec inputs
Description, Motivation and Context
Introduce
preflight --dry-run
flag used to print specs to stdout. I went for--dry-run
flag instead of adding a new subcommand (dump
,print
,view
etc) cause it felt a bit more intuitive. It also makes sense since when we pass in multiple specs,--dry-run
would print out what would be run in spec format.Notes for reviewer
ToYaml()
method that marshalsTroubleshootKinds
to yaml documentsPreflightSpecs
in favour ofTroubleshootKinds
Partially addresses #1024. We still need to add
support-bundle --dry-run
flagChecklist
Does this PR introduce a breaking change?