You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
When i use the command kubectl get svc kubernetes -o yaml | kubectl-neat to get the neat output of the kubernetes service, the clusterIP is not removed. In result of that, when i apply the output to a new k8s cluster, it turns out the apply cannot be executed successfully for the reason of different ServiceCIDR.
So, neating clusterip of service, is that reasonable?
The text was updated successfully, but these errors were encountered:
Thanks for taking the time to open an issue and a pull request.
I am unsure about this. If the goal of this plugin is to "export" resources so that they can be imported, then yes this PR is welcome, but if the goal is to just improve legibility without interfering with the data, then this is out of scope. Maybe for cases like this we might need another mode (--export?) that takes a more aggressive approach, but I'd like take anther couple of days do consider this.
If there are any other arguments or opinions to share about this feature, we can discuss it here
Export mode would be a good choice. For me, kubectl -o wide|custom-columns=... is useful enough with the Table format compared to yaml/json format in daily work. But when it comes to import resources to another cluster, i would use kubectl-neat definitely.
When i use the command
kubectl get svc kubernetes -o yaml | kubectl-neat
to get the neat output of thekubernetes
service, theclusterIP
is not removed. In result of that, when i apply the output to a new k8s cluster, it turns out the apply cannot be executed successfully for the reason of different ServiceCIDR.So, neating clusterip of service, is that reasonable?
The text was updated successfully, but these errors were encountered: