Skip to content
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

Merged
merged 22 commits into from
Sep 12, 2023

Conversation

banjoh
Copy link
Member

@banjoh banjoh commented Jun 23, 2023

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

  • Introduce ToYaml() method that marshals TroubleshootKinds to yaml documents
  • Move cmd/util to cmd/internal/util. Its private implementation
  • Remove PreflightSpecs in favour of TroubleshootKinds

Partially addresses #1024. We still need to add support-bundle --dry-run flag

Checklist

  • New and existing tests pass locally with introduced changes.
  • Tests for the changes have been added (for bug fixes / features)
  • The commit message(s) are informative and highlight any breaking changes
  • Any documentation required has been added/updated. For changes to https://troubleshoot.sh/ create a PR here

Does this PR introduce a breaking change?

  • Yes
  • No

@banjoh banjoh added the type::feature New feature or request label Jun 23, 2023
@banjoh banjoh requested a review from a team as a code owner June 23, 2023 11:08
@banjoh banjoh marked this pull request as draft June 23, 2023 11:09
@CLAassistant
Copy link

CLAassistant commented Aug 24, 2023

CLA assistant check
All committers have signed the CLA.

@banjoh banjoh closed this Aug 24, 2023
@banjoh banjoh reopened this Aug 24, 2023
@banjoh banjoh changed the title feat: command to dump troubleshoot specs to std out feat: command to print preflight specs to std out Aug 31, 2023
@banjoh banjoh changed the title feat: command to print preflight specs to std out feat: Dry run flag to print preflight specs to std out Aug 31, 2023
@banjoh
Copy link
Member Author

banjoh commented Aug 31, 2023

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: {}

@banjoh banjoh marked this pull request as ready for review August 31, 2023 18:34
@banjoh banjoh requested a review from a team as a code owner August 31, 2023 19:02
Copy link
Member

@xavpaice xavpaice left a 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")
Copy link
Member

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.

Copy link
Member Author

@banjoh banjoh Sep 5, 2023

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.

Copy link
Member Author

@banjoh banjoh Sep 5, 2023

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.


warning := validatePreflight(specs)
if warning != nil {
fmt.Println(warning.Warning())
return nil
Copy link
Member

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 {
Copy link
Member

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?

Copy link
Member Author

@banjoh banjoh Sep 5, 2023

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

@xavpaice xavpaice linked an issue Sep 12, 2023 that may be closed by this pull request
2 tasks
@banjoh banjoh merged commit b9f4fc4 into replicatedhq:main Sep 12, 2023
22 checks passed
@banjoh banjoh deleted the em/dump-spec branch September 12, 2023 13:42
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
type::feature New feature or request
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Expose rendered spec after merging via an API and the cli
3 participants