rpk stability

[0x5d]

Here are some ideas - things I've wanted to do for some time now, as well results of different discussions with the team - on changes to rpk that could make the code simpler, resulting in less bugs when features are added:

Config

• API cleanup
  • Manager#ReadOrGenerate is exported but is only used internally
  • Manager#WriteNodeUUID seems unnecessary - setting the UUID could be done when writing the config to the FS.
  • config.InitViper is only used internally
• Remove config values & structure checks in rpk
  • I don't think checking the config structure has provided much value. On the opposite, I think it has coupled rpk & redpanda in unnecessary ways (redpanda parses and checks the configuration when it starts anyway). Granted, rpk's checks provide better error messages since they're not directly from the yaml parser.

CLI

• Many commands use the same flags, but the code that sets the flag name, description, etc is duplicated. Similar flags should be abstracted into a function that modifies the command. e.g. func addConfigFlag(cmd *cobra.Command, path *string)

Tuning

• Tuning logic is duplicated in start.go & tune.go.

Integration testing

• There are some tests written with our internal framework for rpk topic consume & rpk topic produce, but more need to be written for the rest of the commands.

---

Also, most of the issues with rpk have stemmed from the fact that it must load the config file, change it, and then write it back so that redpanda can then read it. Hopefully, switching to using flags will help further.

[emaxerrno]

@mmaslankaprv - can you list the recent error categories you have seen w/ the reporting of rpk

[rfinner]

I have found the docker sample for 3 containers to fail on occasion. The problem went away after I specified the brokers in each call on the command line.

[0x5d]

I just sent #852 as a fix for #693. I think by now not many people are using rpk api *, and if they are, we've had rpk topic * for 2 months now, aso they should migrate.