Closed krisnova closed 7 years ago
It seems confusing to have both kops audit
and kops validate
; they sound like they do similar things.
What would be the difference between the output of kops audit cluster
and kops validate cluster
?
Note that I already find kops validate
to be confusingly named. I had no idea what it did until I ran it, and it just dumped my cluster status. kops describe
would seem to be a better name for that command. I'm not sure if it's too late to rename or not...
@yissachar run kops toolbox dump
:) <- it gives you what is running
kops validate cluster
<- it gives you that k8s is running
@kris-nova @chrislovecnm @justinsb I think the conclusion from the call was that we would either:
kops validate
as-is and potentially have it take over the audit
commands when they are added, e.g. kops validate account
.kops validate
before 1.5 drops (tall order!).Is this correct?
kops validate cluster
will stay as is :)@kris-nova I should have known you would be responsible for cobra.Command
-er
Proposal for a new kops cobra command
Which would essentially allow us to run some sort of validation against some resource. Use cases I can think of
1.
kops audit account
This would essentially audit an account (say an AWS account for instance) and validate that the account appears set up correctly and ready to use with kops. This could be used a pre-emptive check for a new AWS account, and could provide valuable feedback for users trying to set up their account for the first time.
2.
kops audit limits
(This might be a subcomponent of 1)
This would start to use the (debatably helpful)
DescribeAccountAttributes
endpoint and do some algebra behind the scenes to see what kops can and can't create in an account based on limits. This would be useful to users who are creating/destroying clusters in the same account often and a need a way to measure how full their accounts are (measured in terms of kops clusters)EG: You have N instances available, and that would yield X clusters at Z size
3.
kops audit cluster
We could port
toolbox dump
intokops audit cluster
. This would essentially do the exact same thing, but follow a more natural hierarchy.Note that the actual implementation here is up for discussion, and we don't have to create a new command. We might even consider renaming
audit
to something a tad more appropriate.. saykops describe *
for instance..Thoughts:
1. We could have levels of output
Where each level could be formatted accordingly.. and we could display information based on the level of severity
2. We can suggest best practices
In the terms of versioning the state store like https://github.com/kubernetes/kops/issues/1123 we could offer a
warning
, or acritical
report on things like this that will discourage bad practices.3. Output
This feels analogous to a
GET
workflow.. so we should probably support spitting out data in a friendly format. EG:-oyaml