Refactor talosctl command #10133
Comments
|
Muscle memory need to be retrained but sounds good. But what about an option -n all Could be interesting for certain commands like talosctl dashboard or talosctl run dashboard. Because bash completion is not working with the required format -n node1,node2,no |
|
I believe the change makes sense. There will be some re-training of the muscle memory but it looks more coherent. |
That, plus
Edit, that would overload the |
|
I think we need to offer more options for where commands are run, but it would be impossible to built in all flexibility without making it config driven. One of the things that makes it difficult is if you're using clusters with omni then omni becomes your endpoint and I think it's important to address but wouldn't be changed with this issue. This one is strictly focused on the command structure. |
|
some suggestions:
|
|
In general I hate more typing, but I do understand the need for restructure things
I associate |
|
I generally like the verb/noun approach, it's more intuitive for new users and more in line with other cli like kubectl. I think the proposal looks pretty neat, although I do agree that it would be nice to have a version of |
|
Thanks everyone for the feedback. For everyone looking for |
Feature Request
Update
talosctlto have the following subcommands structured as verbs (apply, edit, gen, get, run), nouns (etcd, k8s, node), and maintenance (completion, config, help, version).This replaces or moves a significant portion of subcommands to categorize them into one of these other groups.
Here is a high level table of how existing commands would be removed, moved, or modified
apply-config, applyapplywithserviceaccountsubcommandapply-configbootstrapetcd bootstrapcluster create/destroy/showkubernetes clustercompletion bash/zshcompletion bash/zshconfig(all subcommands)configwith addedvalidateconformancekubernetes cacontainers, cget containerscopy, cprundashboardrundisksgetdmesgrunediteditwith--patchoptionetcd(all subcommands)etcdwith addedbootstrapeventsgen(all subcommands)gengetgetwith expanded subcommandshealthgethelphelpimage, imagesgetinjectinspectkubeconfiggetlist, lsrunlogsget servicemachineconfigmemory, m, freerunmetanodemounts, mountrunnetstat, ssrunpatchpcap, tcpdumprunprocesses, p, psrunread, catrunrebootrunresetnoderestartrunrollbacknoderotate-cakubernetes caservice, servicesgetshutdownrunstatsget containerssupportruntimegetupgradenodeupgrade-k8skubernetesusage, durunvalidateconfigversionversionkubernetescommandrun shellcommandrun kubectlcommandnodecommand groupDescription
We would like to update the command structure of
talosctlinto a more thoughtful (and hopefully consistent) structure that's easier to discover commands and understand how they should be used.The main goal is not to add a lot more functionality but to clean up how the CLI has evolved over time.
One of the biggest changes is a
runsubcommand which is intended to be used for debugging nodes. This has many of the common debug commands (egls,ss,ps) and will also be able to be used interactively as a "shell". This would take the place ofsshbut still give a familiarsshfeeling of debugging a single node without always needing to specify--nodeand--endpoint.Getting this structure in place will help us clean up a lot of cruft and extend talosctl to be more flexible in the future.
Removed commands
The commands we would remove will be
apply-config,events,inject,machineconfig,inspect, andpatch.apply-configwould be removed in favor of apply because it is a more common command for admins to use. It’s already aliased to apply so it should be the easiest removal.eventsisn’t a command we’re using inside talos. If it has use cases then we could possibly move it under get events.injectcurrently only applies to service accounts and we can move that functionality to an apply flag or via traditional kubectl commands.machineconfigis duplicated with gen and isn’t needed as a separate command. If there are other use cases please let us know.inspectis a command that is primarily used for development and not needed for administration. If we want to keep this command (or something like it) we should move it to a dedicated development debugging tool.patchis duplicated with apply and edit. If we want to have an automatic way to edit a resource with a patch file we can add a--fileoption to edit which might be easier for user to find.Migration process
We will want to keep the existing command structure and new structure for at least 2 releases where possible. There are some command flags that would overlap or be incompatible and we'll need to make sure those commands are safe to run.
We will hide the old structure from the
helpoutput so users can get used to the new structure but old subcommands would still be available.Internally this proposal can be referenced as RFD-13
The text was updated successfully, but these errors were encountered: