rpk tuner handling

[r-vasquez]

When running rpk redpanda tune <tuner> we have 3 states:

1. Applied: Tuner was successfully applied after running rpk tune .
2. Enabled: Tuner is enabled via redpanda.yaml configuration properties.
3. Supported: Tuner is supported in the system in which redpanda is running.

In #5186 we noticed that rpk redpanda tune always exits with code 0, it doesn't matter if the runner was applied, enabled, or supported.

In #5295 we fixed this by making rpk redpanda tune <tuner> exit with code 1 when: Tuner failed OR Tuner is enabled but unsupported.

This raised different questions:

1. Is "tuner enabled but unsupported" a reason to exit with code 1? or rather we should exit with code 1 only when tuner fails.
2. rpk redpanda mode production includes disk_write_cache tuner, which is only supported for GCP and will fail in non-gcp environments. Should we take this tuner off of production mode or allow it to fail (temporary fix in rpk: allow write_disk_cache to fail in rpk tune #5348)

[twmb]

Other things to note:

• fstrim was disabled in prod in Disable fstrim by default in rpk mode production #3068
  • Followup question is: how does a person know to run this?
• transparent_hugepages never enabled by default in prod: 31552cb

[emaxerrno]

When running rpk redpanda tune <tuner> we have 3 states:

This raised different questions:

1. Is "tuner enabled but unsupported" a reason to exit with code 1? or rather we should exit with code 1 only when tuner fails.

What do you recommend. we may need a community poll.

what do other projects do for cli experience. we may need to define a CLI experience like heroku. I bet some of this things don't have right/wrong answers, only a design approach and people expect consistency.

2. rpk redpanda mode production includes disk_write_cache tuner, which is only supported for GCP and will fail in non-gcp environments. Should we take this tuner off of production mode or allow it to fail (temporary fix in rpk: allow write_disk_cache to fail in rpk tune #5348)

this should be skipped altogether if non-GCP env. should not be fatal in any other env.

contextual tuners make a lot of sense.