aaroniscode
commented
3 months ago Thanks for the feature request @csantanapr . I do like the idea of making eksdemo even easier to use!
Let me noodle on this for a bit on how best to implement. I had thought about this a while ago thinking about making it a setting, that would be saved on disk using and read at runtime using Viper.
While I'm all for making eksdemo easier to use, I do want to implement this with "least surprise" and want to avoid ever installing to a cluster you didn't intend.
I think you could argue this is similar to Helm as it will install in the current Kubeconfig context and if you want to override you use -c cluster just like Helm offers --kube-context.
I would love to avoid to remember to pass the cluster name when I only have one cluster if I run
eksdemo get clusterRunning a command like this when I have only 1 cluster
Error: required flag(s) "cluster" not setor
The UX I would like to see to make it easier to run use the CLI when working with a cluster
+------------+--------+---------+---------+----------+----------+ | Age | Status | Cluster | Version | Platform | Endpoint | +------------+--------+---------+---------+----------+----------+ | 57 minutes | ACTIVE | *blue | 1.29 | eks.7 | Public | +------------+--------+---------+---------+----------+----------+
eksdemo install aws-lb-controller
Additional context: We could potentially assume the cluster in context in local kubeconfig could be the cluster to select if the flag
-cis not passed, maybe the logic to implement would easier assuming the flag is always optional and it will select what ever cluster is in the context in local kubeconfig.