Would be queried with kubectl cost like this: kubectl cost namespace -N "kubecost2" --service-name "kubecost2-cost-analyzer"
But now it can be queried more simply, like this: kubectl cost namespace -r "kubecost2"
Or, if the namespace doesn't match, like this: kubectl cost namespace -r "kubecost2" -N "other-namespace"
This is a substantial UX improvement, so users don't have to be aware of KC service name templating convention. The --service-name flag remains with the same behavior, if manual overrides are desired.
How does this PR impact users? (This is the kind of thing that goes in release notes!)
Improve query UX by adding the catch-all --release-name (-r) flag to handle templating of both Kubecost namespace (-N) and service name (--service-name) by default. Overrides remain valid. See the updated --help for an example.
What does this PR change?
Previously, a Kubecost install done like this:
Would be queried with kubectl cost like this:
kubectl cost namespace -N "kubecost2" --service-name "kubecost2-cost-analyzer"But now it can be queried more simply, like this:
kubectl cost namespace -r "kubecost2"Or, if the namespace doesn't match, like this:
kubectl cost namespace -r "kubecost2" -N "other-namespace"This is a substantial UX improvement, so users don't have to be aware of KC service name templating convention. The
--service-nameflag remains with the same behavior, if manual overrides are desired.How does this PR impact users? (This is the kind of thing that goes in release notes!)
Improve query UX by adding the catch-all
--release-name(-r) flag to handle templating of both Kubecost namespace (-N) and service name (--service-name) by default. Overrides remain valid. See the updated--helpfor an example.How was this PR tested?
Notes above, equivalent scenario was run.