Preflight to search stdin for secrets containing preflight specs

[xavpaice]

Describe the rationale for the suggested feature.

Recently we added a feature to allow stdin to be passed to preflight as a source of specs. This included the ability to filter non-preflight spec documents, so that we can run something like helm template ./chart --values foo.yaml |preflight -.

We recommend that support-bundle specs are installed in cluster as secrets, with a label to identify them.

I would like to have preflight able to search the rendered templates from helm template for secrets that contain preflight specs. The specific example is where a preflight is included in a pre-install hook, with a secret for the spec, but we want to run preflight outside of a helm install so that we can retrieve the results without having a failed installation to clean up.

Describe the feature

Currently stdin looks for docs of kind: Preflight. I would like it to also read kind: Secret with the label troubleshoot.io/kind: preflight, extract the data component, and use that as a spec.

Example:

# Source: troubleshoot/templates/pre-install.yaml
apiVersion: v1
kind: Secret
metadata:
  annotations:
    "helm.sh/hook": pre-install, pre-upgrade
    "helm.sh/hook-weight": "-6"
    "helm.sh/hook-delete-policy": before-hook-creation, hook-succeeded, hook-failed
  labels:
    app.kubernetes.io/managed-by: "Helm"
    app.kubernetes.io/instance: "release-name"
    app.kubernetes.io/version: 0.62.1
    helm.sh/chart: "troubleshoot-0.1.0"
    troubleshoot.io/kind: preflight
  name: "release-name-preflight-config"
data:
  preflight.yaml: CmFwaVZlcnNpb246IHRyb3VibGVzaG9vdC5zaC92MWJldGEyCmtpbmQ6IFByZWZsaWdodAptZXRhZGF0YToKICBuYW1lOiBwcmVmbGlnaHQtc2FtcGxlCnNwZWM6CiAgCiAgYW5hbHl6ZXJzOgogICAgLSBub2RlUmVzb3VyY2VzOgogICAgICAgIGNoZWNrTmFtZTogTm9kZSBDb3VudCBDaGVjawogICAgICAgIG91dGNvbWVzOgogICAgICAgICAgLSBmYWlsOgogICAgICAgICAgICAgIHdoZW46ICdjb3VudCgpIDwgMycKICAgICAgICAgICAgICBtZXNzYWdlOiBUaGUgY2x1c3RlciBuZWVkcyBhIG1pbmltdW0gb2YgMyBub2Rlcy4KICAgICAgICAgIC0gcGFzczoKICAgICAgICAgICAgICBtZXNzYWdlOiBUaGVyZSBhcmUgbm90IGVub3VnaCBub2RlcyB0byBydW4gdGhpcyBhcHBsaWNhdGlvbiAoMyBvciBtb3JlKQogICAgLSBjbHVzdGVyVmVyc2lvbjoKICAgICAgICBvdXRjb21lczoKICAgICAgICAgIC0gZmFpbDoKICAgICAgICAgICAgICB3aGVuOiAiPCAxLjE2LjAiCiAgICAgICAgICAgICAgbWVzc2FnZTogVGhlIGFwcGxpY2F0aW9uIHJlcXVpcmVzIGF0IGxlYXN0IEt1YmVybmV0ZXMgMS4xNi4wLCBhbmQgcmVjb21tZW5kcyAxLjE4LjAuCiAgICAgICAgICAgICAgdXJpOiBodHRwczovL2t1YmVybmV0ZXMuaW8KICAgICAgICAgIC0gd2FybjoKICAgICAgICAgICAgICB3aGVuOiAiPCAxLjE4LjAiCiAgICAgICAgICAgICAgbWVzc2FnZTogWW91ciBjbHVzdGVyIG1lZXRzIHRoZSBtaW5pbXVtIHZlcnNpb24gb2YgS3ViZXJuZXRlcywgYnV0IHdlIHJlY29tbWVuZCB5b3UgdXBkYXRlIHRvIDEuMTguMCBvciBsYXRlci4KICAgICAgICAgICAgICB1cmk6IGh0dHBzOi8va3ViZXJuZXRlcy5pbwogICAgICAgICAgLSBwYXNzOgogICAgICAgICAgICAgIG1lc3NhZ2U6IFlvdXIgY2x1c3RlciBtZWV0cyB0aGUgcmVjb21tZW5kZWQgYW5kIHJlcXVpcmVkIHZlcnNpb25zIG9mIEt1YmVybmV0ZXMuCiAgICA=

Additional context

This is part of a work relating to helm/community#301 where the output of a Helm pre-install hook can go to stdout. Without that change (which would require the feature to be agreed, merged, released and the end user to upgrade Helm), we need to have preflight checks able to run so that it is easy to obtain the output.

The proposed approach allows us to run preflight checks without needing to run helm install, and manually retrieve logs from a failed install. The older version of helm would use preflight, newer versions after the above change is merged could use the same chart without modification, but simply use helm install with the --atomic switch.

NOTE:

• One major difference between the Helm pre-install hook, and running preflight, is that the preflight binary runs on the host that has the client, and the pre-install hook runs a job in a pod in the cluster. This can be overcome by choosing preflights that run as jobs, but without making that choice there is risk of different results between approaches.

[chris-sanders]

Is it possible to store the preflight with stringData so that it shows something useful for a user or does the sting contain information that can't be encoded that way? I feel like it's been said previously there's an encoding problem but I can't remember why so I just wanted to be sure we checked.

[xavpaice]

we should support both, but yes stringData is probably easier to read. The base64 option is historical - supportBundle specs are stored that way by KOTS.

[CpuID]

PR #1153 is ready for review 👍

[CpuID]

Released in v0.64.0