Tink CLI current state and the future is called consistency

[gianarb]

Hello

The CLI is important because it is the entry point many people will use to onboard Tinkerbell. If the CLI is not great, they will even stop using Tinkerbell. Or at least that's how I approach an ecosystem where there is a new cool project to use every day.

Consistency

I vote tink CLI with a 3 out of 10 currently. There is very low consistency in what you can do with a resource (template, event, hardware...). Some of them have get, others have list others have all as a subcommand. This isn't good already, but I can even go further. We use --file to pass a file when pushing new hardware; we use -p to create a template #270. Same thing, different flag. Same action (create) different name push or create.

Even when the behavior is consistent, it is just luck or a memory exercise left to the contributor or the reviewer that has to remember or figure out if flags and commands are in some way consistent with the current state of CLI. This isn't good. Consistency has to be built in the code itself in the form of structure and abstraction.

---

The tink CLI uses Cobra, and it is structured with resources as root level: events, hardware, template, workflow. Each of those resources has its own commands. I think it is an overall good structure. Still, I expect to quickly move between those resources having a consistent structure for common operation (per resource specialization is fine, but it should be an advanced requirement).

Common operations are:

• get -> Retrieve a list or a single resource printing important information with the ability to do filtering based on what the resource allows me to filter on. It will be nice to be able to specify what to show as well (if you want only the ID Consistent user experience across tink-cli list command -q #403 , for example)
• describe -> Shows a single resource with all its details
• create -> Create a new resource
• delete -> Delete a resource
• update -> Update a resource

Every command that outputs data should use the same rendering components with the ability to:

• Specify what we want to see
• And the output format: JSON, CSV, ps, or table

The right way to enforce consistency is at the code level, which means that create, update, delete, get, describe have to be reusable commands across resources.

---

Example: Hardware

Current situation

Available Commands:
  delete      delete hardware by id
  get
Display one or many resources
  id          get hardware by id
  ip          get hardware by any associated ip
  list        list all known hardware
  mac         get hardware by any associated mac
  push        push new hardware to tink
  watch       register to watch an id for any changes

What I would like to get:

• delete
• get (with filtering made in the right way we can deprecate mac, list, id, IP)
• create (in favor of push that can be deprecated)
• update

---

Any thought?

[gauravgahlot]

This is a much-needed one. The new structure reminds me of Docker CLI which is a great experience in itself.
Let's get the changes rolling. 🚀

[gianarb]

@gauravgahlot it is also how kubectl works. Nothing new, just a good and validated pattern.

[gianarb]

I don't think there is much more to say here. #406 is merged and I hope it will set the stage for something good.